Provide a structured requirements analysis framework that moves from “feels like a good idea” to “confirmed this is worth building.” Applicable to any product’s target user analysis.
Persona (who)
|
Pain (what cost are they bearing)
|
Scenario (when and where does the pain occur)
|
Need (what outcome do they actually require)
|
Solution (what to build -- and what NOT to build)
Every arrow must be explainable with “why.” No skipping steps.
Definition: A concrete person, not an abstract market segment.
| Wrong | Right |
|---|---|
| “Real estate professionals” | “Independent real estate agents with 5-15 years experience and their own client base” |
| “Small business owners” | “Solo online sellers who take orders via social media groups, manually replying to messages daily” |
| “People who need AI tools” | (This is a technology, not a person – reject this framing) |
How to make it concrete: Age, occupation, work style, technical familiarity, what they do every day.
Definition: The specific cost this person is currently bearing – time, money, mental burden.
“Inconvenient” is not enough to make someone pay or change habits. Cost is.
| Not specific enough | Specific (with cost) |
|---|---|
| “Making reports is annoying” | “Each report takes 2-3 hours; sometimes clients are urgent and I work overtime” |
| “Worried about compliance” | “Regulations change yearly; last time I filled in the wrong clause, the client complained, and I spent half a day redoing it” |
| “Inconsistent formatting” | “Company has a standard format but employees each do their own thing; clients receive inconsistent documents, reducing professional image” |
Definition: The specific context in which the pain happens – time, place, surrounding conditions.
Scenarios tell you what conditions the solution must operate under.
Scenario: [name]
Time: [when does this happen]
Location: [where -- office, mobile, field]
Context:
- [What data/resources do they have at hand]
- [What task are they trying to complete]
- [What constraints exist]
Pain trigger: [the exact moment the pain occurs]
| Scenario detail | Design implication |
|---|---|
| User is at a computer | Desktop app is appropriate; mobile version not needed |
| Needs PDF output | PDF rendering is a core feature |
| Reference data is known/static | Can be built-in; user does not need to look it up |
| User is in the field with spotty internet | Offline capability required |
| Task is time-sensitive | Speed and minimal steps are critical |
Definition: What the user actually needs to achieve, extracted from the scenario. This is NOT a feature list.
Need and Feature are different things:
| Scenario | Need | Feature |
|---|---|---|
| Finding the right legal clause is slow | Quickly select the correct clause | Clause database + search |
| Document formatting is hard to control | Output must have consistent formatting | Template engine + PDF rendering |
| Need to include company branding | Output includes company brand | Brand settings (logo + company name) |
| Client is waiting urgently | Complete the entire process quickly | Workflow optimization (fewer steps) |
From need to feature is where “design” happens. Do not skip needs and jump straight to features.
Definition: The feature set designed to address the needs – with explicit boundaries on what is excluded.
| Need | Solution | Will NOT Do |
|---|---|---|
| Quickly select correct clause | Built-in clause database, searchable, one-click insert | Custom clause authoring (regulations are fixed) |
| Consistent formatting | Standardized PDF template, no user format editing | Free-form format editor (freedom = inconsistency) |
| Company branding | Brand settings page (set once, auto-applied) | Per-document brand settings |
| Fast workflow | Minimum fields principle (only ask for required info) | Full property database / CRM direction |
Key judgment: Solution boundaries come from “what NOT to do.” Without clear boundaries, features expand indefinitely.
Before starting any new feature, walk through these five steps:
Complete this analysis, then begin design.
Every assumption must be falsifiable (can be proven wrong).
| Type | Example |
|---|---|
| Falsifiable | “Users spend an average of 2-3 hours producing each report” – disproven if interviews show average under 30 minutes |
| Non-falsifiable | “Users need better tools” – nothing can disprove this, so it is meaningless |
What is the problem?
|
Write it as a falsifiable proposition (specific, measurable, with disproval conditions)
|
What evidence could disprove it?
|
Go look for disproving evidence (not supporting evidence)
|
No disproving evidence found?
--> Tentatively accept the problem as real
|
Write the solution as a falsifiable proposition
|
Test it (red tests)
Humans have confirmation bias: we tend to find evidence supporting our ideas and ignore contradicting evidence.
Wrong question: “Do you find making reports annoying?” (Users will say yes – but annoyed does not equal willing to pay.)
Right approach: Find conditions that would invalidate the assumption.
Error 1: Treating “possible” as “certain” “Users might need this feature” -> No disproval condition -> Meaningless.
Error 2: Leading questions “Do you think automating reports would be helpful?” -> Users always say yes -> Pain not validated.
Error 3: Sample bias Only asking “people already looking for a solution” -> Of course they have the pain -> Does not prove the market is large enough.
Error 4: Confusing feature requests with problems “Users want feature X” is not the same as “X solves a real problem.” First ask: what problem does X solve?