Most product failures trace back to a vague problem statement. Teams jump to features, then argue about scope for months. These 15 prompts force you to articulate the user, the pain, the trigger moment and the cost of doing nothing — before a single mockup gets drawn. They cover the early founder version (one paragraph), the PRD version (one page), and the executive briefing version (three bullets).
Who this is for
Founders shaping a new product, PMs writing the opening section of a PRD, product designers running discovery, and indie devs trying to stop themselves from building the wrong thing.
When not to use these prompts
Skip these when the solution is already shipped and you only need launch copy. Skip too if the problem is genuinely a research question rather than a product question — interview users first, then write the statement.
Prompt anatomy / structure formula
A strong problem-statement prompt always carries six elements:
- Role: who the AI plays (senior PM / solo founder / product designer / indie dev / growth lead).
- Context: stage (idea / MVP / growth / scale), team size, traffic or ARR, platform (web / iOS / Android), audience, constraints.
- Goal: one concrete deliverable — one PRD section, one user-story set, one experiment design, one launch post.
- Constraints: timeline (this sprint / this quarter), scope cuts, must-not-break (existing flows, billing, compliance).
- Output format: table, checklist, ticket-ready JSON, or labeled blocks you can paste straight into Linear / Notion / Jira.
- Examples / signal: 1-2 reference docs or competitors you like, plus 1 anti-example you want to avoid.
Best for
- PRD opening section
- Pitch deck slide 2 (the problem)
- Discovery interview kickoff
- Roadmap quarterly review
- Indie-dev sanity check before building
15 copy-ready prompt templates
1. Classic “we are solving X for Y because Z”
The single most useful template. Run this before any PRD.
You are a senior PM. Help me write a problem statement in the form: "We are solving {problem} for {specific user segment} because {consequence today}." Constraints: less than 40 words, no buzzwords, the user segment must be narrow enough that I could name 3 real people in it.
Draft inputs: {raw idea, target user, pain you noticed}Variables to swap: raw idea, target user, pain you noticed
Optimization: If the output feels generic, add: “Rewrite so the consequence today is a specific moment in the user week, not an abstraction.”
2. PRD-grade one-page problem section
Write a one-page problem statement for a PRD. Sections: (1) User segment in one sentence, (2) Current workaround they use, (3) What breaks about the workaround, (4) Cost of inaction in money or time, (5) Why now (what changed in market, tech or behavior), (6) Why us (asymmetric advantage). Each section 2-3 sentences.
Context: {paste discovery notes or 3 user quotes}3. Three-bullet executive version
Compress this problem into 3 bullets for an exec briefing. Bullet 1: the user and pain in 15 words. Bullet 2: the cost of doing nothing this quarter. Bullet 3: the wedge — what we can ship in 6 weeks to learn.
Source: {paste long problem doc}4. “Five whys” problem deepening
Take this surface-level problem and run a five-whys interrogation. Start from the symptom and dig down 5 layers until you land on either a behavior, a system constraint or a belief. Output as 5 numbered Q-A pairs, then a one-sentence root statement.
Surface problem: {paste}5. Problem vs symptom diagnostic
Below is what my team calls "the problem". For each line, classify: is this a problem, a symptom, or a solution-in-disguise? Suggest a rewrite that puts every item in the right column.
{paste raw problem list}6. Job-to-be-done framing
Reframe this product problem as a job-to-be-done statement: "When {situation}, I want to {motivation}, so I can {expected outcome}." Then list 2-3 functional, 2-3 emotional and 1-2 social dimensions of the job.
Product idea: {paste}7. Anti-problem statement
Write the opposite version of this problem statement — what would make the problem worse on purpose. Use it to surface hidden assumptions about what "better" looks like. End with 3 assumptions to test.
{paste current problem statement}8. Quantified pain calculator
For the problem below, estimate: (a) how often the pain occurs per user per week, (b) time lost per occurrence, (c) approximate $ value of that time, (d) total annual pain per user. Show your assumptions. Flag any number where confidence is less than 50%.
Problem: {paste}9. “Smallest meaningful audience” filter
Take this broad problem and narrow the user segment 3 times. Each pass: cut the segment in half by adding a constraint (role, stage, tool used, frequency, geography). End with a segment you could name 5 real people in.
Broad statement: {paste}10. Problem statement critique pass
Critique this problem statement on 7 dimensions: (1) specificity of user, (2) is it actually a problem or a feature wish, (3) cost of inaction quantified, (4) why now, (5) why us, (6) testable, (7) free of solution language. Score each 1-5 and suggest the smallest rewrite.
{paste}11. Founder one-liner
Turn this into a founder one-liner I can say at a dinner party without sounding like a deck. Voice: warm, specific, slightly understated. Less than 25 words. Avoid "platform", "solution", "ecosystem".
{paste problem statement}12. B2B vs B2C variant pair
Write two parallel versions of the same problem statement: one for a B2B audience (buyer = a manager) and one for a B2C audience (buyer = the end user). Show how the consequence, urgency and decision criteria shift between the two.
Underlying problem: {paste}13. Pre-mortem of the problem
Imagine 12 months from now we built the product and it failed. List the 5 most likely reasons the problem statement itself was wrong — wrong user, wrong frequency, wrong cost, wrong "why now", wrong scope. For each, propose a cheap test to run before building.14. Competitor delta statement
For this problem, list 3-5 existing solutions users already pay for or hack together. For each: what it does well, where it fails, what segment it leaves underserved. End with one sentence: the underserved gap we will own.
Problem: {paste}15. Discovery interview kickoff doc
Convert this problem statement into a 1-page discovery interview brief: 3 hypotheses to test, 8 open questions (no leading), 3 things to observe in the user environment, 2 things that would falsify the hypothesis. Format as a checklist.
{paste problem statement}Common mistakes
- Writing the solution disguised as a problem (“users need a better dashboard”).
- Defining the user too broadly (“small businesses” — name 5 real people first).
- No cost of inaction — if nothing breaks today, the problem is not worth solving now.
- Mixing problem and feature wish list in the same document.
- Treating the statement as written-once — it should evolve every discovery cycle.
- Skipping “why now” — without a trigger, the problem has been ignorable for years.
- Using AI to make a thin problem sound rich instead of using it to interrogate weaknesses.
How to push results further
- Feed the AI 3 real user quotes before asking for a statement — verbatim language beats your paraphrase.
- Always ask AI to mark assumptions it had to make, then go test those first.
- Read the statement out loud to a non-product person; if they cannot repeat it back, rewrite.
- Force a 40-word limit on the headline version — constraint exposes vagueness.
- Run template 10 (critique pass) on every draft, then rewrite once.
- Keep a /problems folder in Notion and version each rewrite — drift over time is the signal.
- Pair the problem statement with one number you can move; if there is no number, the problem is too soft.
FAQ
- How long should a problem statement be?: One-liner for pitch (under 25 words), one paragraph for a team, one page for a PRD. All three should agree.
- Should I write it before or after user interviews?: Write a v0 first to expose assumptions, then rewrite after 5-8 interviews. The delta is the most useful artifact.
- How do I know my problem statement is good?: A stranger reads it and can name a user who would care, a moment when it hurts, and a metric that would move.
- Can AI invent the problem for me?: No. AI can only sharpen, structure, critique. The problem must come from real users; otherwise you ship features nobody asked for.
- How often should I revisit the statement?: Every quarter, or whenever a metric you expected to move did not. Stale problem statements are the silent killer.