Get specific about the pain before you build the solution
Every useful app starts with a real problem people are already dealing with, not a feature idea or a cool use of AI.
If you can't clearly explain that problem from the perspective of your ideal customer, everything downstream gets harder: positioning, onboarding, marketing, and eventually the product itself.
By the end, you should have:
- a clear pain point
- who feels it
- when it happens
- what they do today
- what it costs them
- the desired outcome
- a one-sentence problem statement
1. Identify the pain
Before you shape the features or UX direction of your app, you need to understand the pain people are actually dealing with. The clearer the pain is, the easier every later decision becomes: who it's for, what the first version should include, what to ignore, and how to explain why it matters.
If you're using AI to build, this is even more important. AI can help you explore better solutions, but only if you give it a clear problem to work from.
Unless you're solving your own problem, these are still assumptions until you talk to real people. Best guess for now. We'll validate later.
| Type | Example |
|---|---|
| Too vague | I want to build a project management tool for freelancers. |
| Useful | Freelancers lose track of client deliverables when juggling more than three projects and miss deadlines. |
2. Spot when it happens
Pain gets clearer when you know when it shows up.
Timing gives you the start of the workflow. It tells you what triggers the problem, where the friction happens, and where your app might eventually fit.
Frequency matters too. A problem that happens once a year needs to be expensive, risky, or painful enough to justify solving. A problem that happens every day can be smaller and still worth paying for.
This is hard to guess, especially in B2B. Workflows are less standardized now that people use AI in different ways. One person might rely on automations and MCP integrations. Another might still be copy-pasting between five tabs.
The workflow is usually where the real pain shows up.
3. Look at what they do today
Existing behavior is one of the best signs that a problem is real.
If people are already using spreadsheets, Zapier flows, manual processes, copy-pasting, duct-taped apps, or repetitive AI prompts, pay attention. That means they're already spending time and energy trying to solve it.
Sometimes the opportunity isn't creating a brand-new behavior. It's making an existing workflow faster, easier, or less annoying.
The useful question is:
How are they doing it now, and what would get better if your app existed?
That's the signal you're looking for. The app doesn't have to sound complicated to be valuable. It just has to remove real friction from something people are already trying to do.
4. Name the cost
A problem gets more useful when you can name what it costs the customer. We're not just talking money. Cost can mean time, missed revenue, mistakes, stress, customer trust, team confusion, operational risk, or the mental tax of doing the same annoying thing over and over.
This is the difference between:
This is annoying.
And:
This is annoying enough to fix.
In the Paper example, the cost is time. The old workflow eats hours that could go toward higher-value work. The stronger the cost, the easier it is to understand why someone would change their workflow, try a new tool, or eventually pay.
5. Write the problem statement
Once you understand the pain, timing, current workaround, and cost, you can turn it into one clear sentence. You don't need to force the perfect version by yourself. That's what the AI pass is for.
A good problem statement names the customer, the problem, when it happens, and why it matters.
Use this format:
[Customer] struggles with [problem] when [situation], which causes [cost / friction / missed opportunity].
Example:
Freelancers lose track of client deliverables when juggling more than three active projects, which causes missed deadlines, client follow-ups, and avoidable stress.
6. Define the outcome
A good problem statement explains what's broken. A good outcome explains what the customer wants instead.
This is where the product marketing work starts to get useful. You're connecting the pain to the result your product needs to create before you start inventing features.
Example
Pain point: Freelancers lose track of client deliverables when juggling more than three projects.
Job to be done: Stay on top of what is due, late, and at risk across active clients.
Desired outcome: Freelancers know exactly what needs attention without checking five different places.
Feature ideas: Leave this blank for now, or add ideas later.
The goal is not to build a feature list yet. It's to understand what "fixed" actually looks like for the customer. This helps you avoid building random features and focus on the result your app actually needs to create.
Prompt
This prompt is not here to invent the strategy for you. It's here to organize your thinking and poke holes in it.
Problem definition
Take all of my notes and organize them into a clear problem definition.
Please structure it into:
1. Core pain point
2. Who feels the pain
3. When it happens
4. How often it happens
5. Current workflow or workaround
6. Cost of the problem
7. Desired outcome
8. One-sentence problem statement
Use this format for the problem statement:
[Customer] struggles with [problem] when [situation], which causes [cost / friction / missed opportunity].
Then audit the idea.
Please flag:
- where the problem is still too vague
- where I'm describing a feature instead of a problem
- what assumptions I still need to validate
- whether the pain seems urgent enough to solve
- whether people are already trying to solve it today
- what evidence I should look for next
- what questions I should ask real users
Be direct. If the problem does not seem painful enough yet, tell me.
Before you move on
| Check | What to look for |
|---|---|
| You're describing the feature, not the pain | "AI project manager" is not the problem. The problem is what the customer is struggling with before your product exists. |
| The problem is too vague | "People need to be more productive" won't help you build. Get specific about who feels the pain, when it happens, and what it costs. |
| There's no current workaround | If people aren't using spreadsheets, manual processes, duct-taped tools, or repetitive AI prompts, the pain may not be urgent enough yet. |
| You skipped the workflow | Pain usually shows up in the messy middle of someone's day. Find where it happens, what triggers it, and what breaks. |
| You jumped to features too early | Define the desired outcome first. Features come later. |