Analyze User Request:

Analyze User Request: Quick Checklist

Next time you receive a user request, run it through this 3-point check:

• Identify the actual need: Users often describe a solution, not a problem. Ask “What are you trying to achieve?”
• Assess scope & frequency: Who raised this? How many others experience the same friction? Prioritize based on real impact.
• Define the minimal viable outcome: The smallest change that addresses the core need before scoping full development.

This helps avoid over-building and ensures you’re solving the right problem.

# Mini Checklist: Validating a User Request

Before turning a request into work, run it through these 3 checks:

- **Problem clarity** – Is the actual pain described, or just a suggested solution? If it’s a solution, ask “what problem are you trying to solve?”
- **User context** – Who experiences this, and how often? A request from one power user may not reflect the broader experience.
- **Success metric** – How will you know if addressing this matters? Define the outcome before you start.

If any check feels vague, pause and clarify with the requester first. Building on assumptions is the fastest way to waste time.

Don’t optimize for the symptom

If a user requests “more efficient data entry,” they’re rarely asking for a faster form. They’re usually frustrated by friction, unclear fields, or redundant steps.

The fix: Before technical work, map the actual friction points. Ask the user to walk through one complete flow. You’ll often find the real ask is validation, defaults, or clarity—not speed.

## Quick Tip: Look Past the Request
When analyzing user requests, focus on the underlying problem, not the suggested solution. Ask: *"What are they trying to accomplish, and why does it matter to their workflow?"* This keeps your analysis rooted in user value rather than feature hunting.

## Mini-How-To: Structure Your Analysis in 3 Questions
1. **What need is expressed?** – Identify the goal or pain point.
2. **What context matters?** – Note user role, task, and environment.
3. **What would success look like?** – Define the outcome, not the output.

Use this framework to consistently surface the real ask, making it easier to prioritize what actually moves the needle.