Define · Core
Write a problem statement and hypothesis
A clear problem statement keeps the team solving the right thing. A hypothesis turns your idea into something you can prove or disprove, so you know later whether it worked.
About 1-2 daysEvergreenLast reviewed 4 November 2026
Who this applies to
- Skills it builds
- Discovery and researchCommunication and influence
- PM types
- All
- Product types
- All
- Starting points
- All
- Ways of working
- All
- Experience
- All
- Size of organisation
- All
Steps, by experience
Beginner (under 1 year)
- Start from your research findings. Pick the user need or pain point with the strongest evidence and the biggest impact.
- Write the problem in one or two sentences: who has the problem, what they are trying to do, what stops them, and why it matters. Do not mention a solution yet.
- List the evidence under it: research quotes, data, support calls or complaints. If the evidence is thin, say so.
- Write a hypothesis in this shape: 'We believe that [doing this] for [these users] will result in [this outcome]. We will know we are right when we see [this measurable signal].'
- Pick one or two measures of success you can actually track, and write down the current baseline if you have it.
- Note the constraints: policy, legal, technical, budget and deadlines. Then review the statement with your team and change it until everyone agrees.
Intermediate (1 to 4 years)
- Write a solution-free problem statement grounded in research evidence.
- Frame the idea as a testable hypothesis with a clear outcome and signal.
- Agree measures of success with baselines, plus known constraints.
- Review with design, engineering and stakeholders, and record sign-off.
Experienced (5+ years)
- Write a problem statement that is solution-free and backed by evidence.
- Write a hypothesis that names the users, the change, the outcome and the signal.
- Set baselines for success measures, and list constraints and non-goals.
- Get sign-off from the team and key stakeholders.
Who can do this
Owner: Product manager
Can be delegated to
- Business Analyst: Draft the problem statement and constraints from the research and process maps
- User Researcher: Supply the evidence and check the statement reflects what users said
- Data Analyst or Performance Analyst: Find baselines for the measures of success
Reviewed by: Tech Lead, UX Designer, Policy / Legal / Compliance
Tool examples
- Confluence
- Keep the problem statement, hypothesis and measures on one page at the top of your initiative space, and link every later document back to it.
- Notion
- Create a one-page brief with fixed headings: problem, evidence, hypothesis, measures, constraints, non-goals.
- Google Docs
- Share the draft with suggestion mode on, so reviewers propose wording changes rather than overwrite each other.
- Jira
- Paste the hypothesis into the epic description, so it travels with the work into planning.
- Claude
- Paste your research summary and ask for three alternative problem statements that avoid naming a solution. Then ask it to point out where each one lacks evidence.
Definition of done
- Problem statement agreed and free of any solution
- Evidence listed for each claim
- Hypothesis and measures of success agreed, with baselines where possible
- Constraints and non-goals written down
Common pitfalls
- Writing the solution into the problem statement
- Choosing measures you have no way of tracking
- Skipping the baseline, so you cannot tell later whether anything changed
If you lead the team
What good looks like: Every piece of work has a short problem statement and a testable hypothesis that the team agrees with.
Ask your PM
- What problem are we solving, for whom, and how will we know it worked?
- What evidence supports the problem?
Warning signs
- The problem statement describes a solution.
- Different people describe the problem differently.