Actor / context
Who experiences it, and under what conditions?
Product discovery workspace
Product Problem Statement Generator
Turn actual evidence into a clear product problem frame-and see when you do not yet know enough to state the problem confidently.
A polished problem statement is not evidence that the problem is real. This workspace keeps observations, interpretations, assumptions, contradictions and causal hypotheses separate, then classifies the current framing as Needs more evidence, Draft problem hypothesis or Supported problem frame.
Evidence first
Record what happened and where it came from before writing the sentence.
No fake certainty
Unknown root cause, prevalence and priority stay unknown instead of becoming a score.
HMW is gated
Ideation prompts appear only after the frame is clear enough to support solution exploration.
Is the framing ready?
Needs more evidence
The frame would overstate what is currently known: actor/context is too broad, obstacle is not behaviorally concrete, consequence is unknown, no observed evidence.
No login. The current snapshot autosaves in this browser. Share links encode the snapshot in the URL, so anyone with that URL can read it. Avoid confidential product data and identifiable research participants.
Quality checks
- Actor/context is too broad (blocker): A label such as users, customers, or teams does not define who actually experiences this problem.Fix: Narrow by role, situation, behavior, lifecycle stage, or environment without inventing demographic detail.
- Obstacle is not behaviorally concrete (blocker): The current barrier is too vague to inspect or challenge.Fix: Describe the step, behavior, missing information, constraint, or failure that is actually observed.
- Consequence is unknown (blocker): The framing does not yet show what changes because of the obstacle.Fix: Add an observed consequence such as delay, extra work, abandonment, error risk, fallback behavior, support contact, or switching. Leave it unknown if you do not know.
- No observed evidence (blocker): There is no observation supporting the problem yet.Fix: Add a sourced observation from interviews, behavior, analytics, support, sales, an experiment, or direct observation. A requested feature alone is not evidence of the underlying problem.
Needs more evidence
You do not yet have enough evidence to frame this as a supported problem.
Evidence supporting the frame
- No observed evidence provided.
Evidence behind each claim
| Claim | Status | Evidence |
|---|---|---|
| Actor/context | unsupported | No evidence mapped yet |
| Obstacle/behavior | unsupported | No evidence mapped yet |
| Consequence | unsupported | Consequence unknown |
| Mechanism | unsupported | Mechanism remains unknown |
Assumptions
- No explicit assumptions recorded.
Unknowns
- The underlying mechanism/root cause remains unknown.
This frame does not claim
- This framing does not choose a solution.
- It does not claim prevalence outside the evidence provided.
- It does not claim the root cause is known unless the mechanism is explicitly marked observed and supported.
- It does not establish market size, willingness to pay, severity, or roadmap priority.
- It does not certify the problem as universally validated.
How Might We
HMW prompts are intentionally withheld until the actor, obstacle, consequence and evidence are clear enough for ideation.
Next step
Clarify the actor, observed behavior, obstacle, and consequence before polishing the statement.
Gather stronger evidence →Export / share
What a defensible product problem frame needs
The core model is intentionally smaller than a persona or PRD: one primary actor/context, the progress they are trying to make, an observed obstacle, current behavior or workaround where relevant, an observable consequence, the evidence supporting those claims, and the uncertainty that remains.
Goal / progress
What are they trying to accomplish?
Obstacle / behavior
What concretely blocks progress today?
Consequence
What changes because of the obstacle?
Evidence
What did you observe, hear or measure, and where?
Workaround
What do people do today to keep moving?
Assumptions
What are you inferring rather than observing?
Unknowns
What still needs research before a stronger claim?
Observation is not the same as explanation
Observed
Admins repeatedly export records to spreadsheets before reconciliation.
Interpretation
The in-product reconciliation flow may not cover the exception cases they need.
Root-cause hypothesis
The comparison surface may lack the granularity required for those exceptions.
The tool keeps these layers separate. It only writes a causal mechanism as supported when you explicitly mark it observed and provide traceable evidence; otherwise it remains a hypothesis or unknown.
Do not confuse a request or metric with the problem
Request ≠ problem
“Customers want export.”
Ask what they export, what they do next, which workflow cannot be completed, what workaround exists and what consequence follows. Only then can you frame the underlying problem without reverse-engineering a justification for export.
Metric ≠ user problem
“Retention is 22%.”
That is a signal. Investigate whose behavior changed, where the journey breaks and what obstacle appears before writing a user problem. The workspace stores business/product signals separately from the user frame.
Three illustrative outcomes-including when not to generate
All examples below are fictional teaching scenarios. They demonstrate the tool's restraint rather than pretending to be real customer research.
Needs more evidence
one AI-summary request
A single sales request says ‘users want AI summaries,’ but the actor, workflow, behavior and consequence are not known.
Correct behavior: Correct result: do not manufacture a polished problem. Flag solution leakage, vague actor, missing consequence and generalization risk; route back to research.
Supported problem frame
workspace-admin permission setup
Several recent workspace admins independently stop during permission setup, contact support and delay teammate invitations.
Correct behavior: Supported frame for the current discovery purpose. The observed obstacle and consequence can be stated; the explanation for why role differences are unclear remains a hypothesis.
Draft problem hypothesis
mixed evidence by account context
High-volume operations teams use spreadsheet reconciliation after export, while smaller teams in the same research set complete the workflow in-product.
Correct behavior: Preserve the contradiction instead of generalizing. Narrow the candidate segment and investigate which workflow conditions create the gap.
Readiness is descriptive, not a score
Needs more evidence
The wording would overstate what is known: for example the actor is vague, the obstacle is a requested solution, consequence is missing, or no observed evidence exists.
Draft problem hypothesis
Useful evidence exists, but coverage, provenance, assumptions or contradictory cases still make provisional wording more honest.
Supported problem frame
The actor, obstacle, consequence and traceable evidence are coherent enough for the current discovery purpose. This still does not mean universal validation or highest priority.
Why there is no ProblemScore
Frequency, severity and evidence quality are important questions, but multiplying three subjective 1–5 ratings produces pseudo-precision and silently turns problem framing into prioritization. This tool preserves the evidence and consequence; when multiple credible opportunities compete, use the dedicated Product Prioritization workspace.
How Might We comes after the problem is clear enough
Weak framing does not earn ten polished ideation prompts. When readiness allows ideation, CraftUp produces three intentionally different lenses-broaden, neutral and narrow-while keeping the underlying evidence visible. If the frame is not ready, HMW is withheld and the next step is research.
Where this fits in the discovery workflow
| Job | Owner | Boundary |
|---|---|---|
| Gather behavioral evidence | Customer interviews / Interview Script | Learn what actually happened; do not pre-write the answer. |
| Compare research patterns | Insight Clustering | Synthesize observations while preserving provenance and exceptions. |
| Frame current evidence | This tool | Express only what the current evidence supports and expose uncertainty. |
| Decide whether evidence is sufficient | Problem Validation | Test confidence for the decision at hand; this tool does not certify validation. |
| Frame desired progress | JTBD | Use situation/motivation/progress semantics when that lens helps. |
| Connect opportunities to solutions | Opportunity Solution Tree | Use supported problems/opportunities as upstream inputs. |
| Choose among credible candidates | Prioritization | Compare competing investments; framing quality alone does not determine priority. |
Evidence-framing tips
- Start with what was observed. Put explanations, emotions and causal claims in assumptions unless the evidence actually supports them.
- Define one primary actor/context per frame. B2B products can have admins, users, champions and buyers, but combining them hides whose problem you are describing.
- A workaround is useful behavioral evidence, but it does not prove market size, willingness to pay or roadmap priority.
- Treat a KPI change as a signal to investigate. Retention, conversion or revenue alone is not a user problem statement.
- One quote can document one case. Do not convert it into segment-level prevalence without additional relevant evidence.
- Keep the mechanism/root cause unknown when you do not know it. A clearly labeled hypothesis is more useful than false causal certainty.
- Generate How Might We prompts only after the frame is clear enough to support ideation. Weak evidence should produce research questions instead.
- Revisit the frame as evidence changes. A problem statement is a current synthesis, not a permanent truth certificate.
Common framing mistakes
The statement is a requested feature with a user noun attached.
Why: A solution request was treated as the underlying problem.
Fix: Ask what the person is trying to accomplish, what happens today, what workaround exists and what consequence follows before naming a solution.
The actor is simply ‘users’ or ‘customers’.
Why: The evidence context was generalized beyond what was actually observed.
Fix: Narrow by role, situation, behavior, lifecycle stage or environment. Do not add fake demographic precision.
The obstacle says only that something is hard or confusing.
Why: A feeling or judgment replaced an observable barrier.
Fix: Describe the step, behavior, missing information, constraint or failure that blocks progress.
The statement says ‘because X’ but X came from team intuition.
Why: A root-cause hypothesis was promoted to fact.
Fix: Mark the mechanism as hypothesis or unknown until evidence supports the causal explanation.
A low KPI is presented as the problem itself.
Why: A business/product signal was confused with user behavior and obstacle.
Fix: Keep the metric as a signal and investigate whose behavior changed, where and why.
A single quote unlocks confident language for a whole segment.
Why: Evidence existence was mistaken for evidence coverage.
Fix: Keep the frame at hypothesis level and gather additional relevant evidence or narrow the statement to the observed case.
Contradicting users disappear from the final narrative.
Why: The synthesis optimized for a clean story instead of preserving exceptions.
Fix: Record counter-evidence and investigate the contextual boundary before generalizing.
The team uses the problem statement as an automatic roadmap ranking.
Why: Framing quality and prioritization were conflated.
Fix: Use the statement to make the opportunity inspectable; compare credible opportunities in the dedicated prioritization or OST workflow.
FAQ
Is this for academic problem statements?
No. This workspace is specifically for Product discovery and operational problem framing. It helps a team separate observed behavior, evidence, assumptions and unknowns before expressing a user or internal problem. Academic research questions, thesis statements and literature-review problems have different evidence and writing requirements.
What do Quick, Standard and Evidence-based modes mean now?
Quick mode creates a working hypothesis and is deliberately capped below a supported frame. Standard mode lets the readiness result follow the evidence you provide. Evidence-based mode is optimized for traceable observations, source context, consequences, assumptions and contradictions; it does not become ‘validated’ merely because one quote exists.
Why did you remove ProblemScore?
Multiplying subjective 1–5 frequency, severity and confidence ratings creates pseudo-precision and mixes framing with prioritization. This tool now describes what is supported, assumed and unknown. When several credible opportunities compete for investment, use the dedicated prioritization workspace and make the decision criteria explicit there.
Do I need to know the root cause before writing a problem statement?
No. In discovery, the mechanism is often still a hypothesis. Mark it as unknown or hypothesis unless you have evidence for the causal explanation. The core frame can still describe a specific actor, goal, observed obstacle and consequence without pretending the underlying root cause is already established.
Is one customer quote enough evidence?
It is evidence of that participant's reported experience, not proof that the same problem applies across a segment. The workspace therefore keeps single-observation framing provisional. Add relevant observations, behavioral data or other sources when the decision requires broader confidence, or narrow the actor/context to what the evidence actually supports.
When are How Might We questions generated?
Only after the framing clears the basic evidence-readiness gate. If actor, obstacle, consequence or evidence is missing-or the input is a solution request-the tool withholds HMW prompts and routes you back to research. When available, it generates three deliberately different lenses: broaden, neutral and narrow.
What is stored when I use the tool or share a link?
The workspace autosaves the current snapshot in this browser's local storage. A Share link compresses the snapshot into the URL, so anyone who receives that URL can read the included content and the URL may appear in browser history or logs. Avoid identifiable participants, confidential customer data and sensitive product information.
How does this differ from Problem Validation?
This tool frames what the current evidence suggests and makes uncertainty visible. Problem Validation is the broader job of deciding whether the available evidence is sufficient for a higher-stakes product decision. A supported frame here is useful input to validation; it is not a universal validation certificate or a priority decision.
Last materially updated: 2026-09-16
- Rebuilt the core workflow around evidence readiness rather than automatic statement generation.
- Separated observed evidence, causal hypotheses, assumptions, unknowns and contradictions; removed ProblemScore from the product workflow.
- Gated How Might We prompts until the problem frame is clear enough for ideation and reduced them to broaden / neutral / narrow lenses.
- Upgraded exports and share links to preserve uncertainty, with migration support for older v1 snapshots.
Learn the method, not just the wording
The static guide owns deeper methodology and examples; the courses own broader discovery and validation capability. This page stays focused on the live framing workflow.
The next step depends on what the evidence says
Evidence missing? Go back to research. Evidence scattered? Cluster it. Frame supported but validation still matters? Strengthen validation. Multiple credible opportunities? Move to OST or prioritization. Do not skip ahead because the sentence sounds finished.