# How to write a problem statement with your team _A useful problem statement names who is affected, what they need and what insight makes the issue worth solving now. This guide shows how to write one with your team in a short facilitated workshop, then points to Five Whys and Design Sprint Day 1 for the next step._ A problem statement is a short, shared description of who is affected, what they are trying to do, what gets in the way and why that matters now. Written well, it gives a team a frame for discussion. Written alone in a document and dropped into a meeting, it often becomes a polished opinion that nobody else fully owns. This guide is about creating a problem statement *with* the people who see different parts of the work. You will get a short definition of what “good” includes, weak and strong examples, a facilitated 20–40 minute flow, and guidance on when to use Five Whys, a problem statement exercise or Lightning Decision Jam. In Clarvelo, problem framing is the opening step of [Design Sprint: Day 1](/workshops/design-sprint-day-1), and [Five Whys Deep Dive](/workshops/five-whys-deep-dive) starts from a concrete problem. How Might We usually follows next. ## What a good problem statement includes Keep the statement concrete enough that someone new to the topic can picture the situation. Three ingredients do most of the work: - **Who:** the person, role or customer segment that experiences the problem. - **Need:** what they are trying to accomplish, not the feature you already prefer. - **Insight:** the obstacle, condition or evidence that makes the issue worth attention now. Separate direct observations from assumptions. Both can be useful, but the group should know which is which. A useful statement is specific without claiming more certainty than the evidence supports. ## Weak and strong examples ### Product example **Weak:** “Checkout is broken and we need to fix mobile.” It names a channel and a preferred fix, but not who is stuck, what they were trying to do or what evidence makes this urgent. > Shoppers on phones abandon checkout between shipping and payment, so they cannot complete a purchase without leaving the flow. Session recordings and a 38% mobile drop versus 11% on desktop suggest this is happening repeatedly. > — Stronger product problem statement ### Team operations example **Weak:** “Handoffs are messy.” Everyone can agree and still leave with different pictures of the mess. > Support agents escalate billing questions to engineering because the help center does not answer plan-change edge cases, so customers wait more than a day for a reply. Ticket tags and three recent chat transcripts show the same gap. > — Stronger team-ops problem statement The stronger versions keep a person visible, state the obstacle and attach evidence. They do not smuggle a solution into the first sentence. ## A facilitated 20–40 minute team flow A solo draft in a Google Doc is cheap to publish and easy to ignore. A short workshop asks the group to write alone first, critique the drafts and agree on one shared frame. In Clarvelo, the AI facilitator holds the prompts and the clock so the organizer can think with everyone else. Guests join with a link. Nobody needs a separate whiteboard account for the exercise. Use this flow when you already have a rough challenge and need a statement the room can stand behind before root-cause work or opportunity framing. 1. **Set the boundary (2–3 minutes).** Name the product area, process or incident in scope. Agree what decision or experiment the statement should inform. 2. **Diverge alone (8–12 minutes).** Everyone writes a draft that covers who, need and insight. Quiet writing first reduces anchoring on the first confident sentence. 3. **Share and critique (8–12 minutes).** Read drafts aloud or side by side. Ask what is observation versus assumption, what evidence is missing and whether a preferred solution slipped into the wording. 4. **Converge (5–10 minutes).** Merge the strongest parts into one statement. Capture open questions instead of polishing uncertainty away. Stop when the group can use the frame, not when every adjective is perfect. In Clarvelo, problem-statement writing is an exercise inside two connected workshops. On [Design Sprint: Day 1](/workshops/design-sprint-day-1), it is the opening phase before How Might We, Crazy Eights and a private vote. In [Five Whys Deep Dive](/workshops/five-whys-deep-dive), the group starts from a concrete problem and deepens the cause chain before reframing. The AI facilitator keeps context visible across steps so the statement stays in view when the agenda moves on. ## When to use Five Whys, a problem statement or LDJ These formats sound adjacent. They answer different questions. - **Problem statement exercise:** best when the group needs a shared frame for who is affected and what is blocked. Often the opening of Day 1, not the whole meeting. - **[Five Whys Deep Dive](/workshops/five-whys-deep-dive):** best when a recurring symptom already has a rough label and you need a deeper, testable cause before inventing fixes. Clarvelo’s workshop pairs the investigation with How Might We. - **[Lightning Decision Jam](/workshops/lightning-decision-jam):** best when the team is stuck on several operational issues and needs problems, reframes, actions and owners in one sitting. See also [how to run a Lightning Decision Jam](/blog/how-to-run-a-lightning-decision-jam-workshop). If people disagree about whether the problem is real, start with framing and evidence. If they agree the problem is real but keep treating the first symptom as the cause, use Five Whys. If they already have a pile of issues and need a decision path, use LDJ. ## Next step inside Day 1: How Might We A problem statement describes the situation. A How Might We question, often shortened to HMW, turns part of that situation into an opportunity without locking the team to one solution. “How might we fix checkout?” is vague. “How might we help a shopper on a phone pay without leaving the checkout flow?” keeps the user and the obstacle visible. On Clarvelo’s Design Sprint: Day 1, How Might We follows the problem-statement exercise in the same session. If the team only needs opportunity framing after a cause is already clear, [How Might We](/auth/register?user_return_to=%2Fapp%2Fworkshops%2Fhow-might-we-workshop) is also available as its own workshop. For the full Day 1 sequence in writing, see [how to run a Day 1 Design Sprint workshop](/blog/how-to-run-a-day-one-design-sprint-workshop). ## Write the statement, then run the right workshop If your team needs to turn a fuzzy challenge into a shared frame and then explore directions, start with Clarvelo’s [Design Sprint: Day 1](/workshops/design-sprint-day-1). Problem Statement is the opening exercise; How Might We, Crazy Eights and Blind Vote follow in one connected session. The AI facilitator runs the prompts and timeboxes so everyone, including the organizer, can contribute. If you already have a recurring symptom and need a deeper cause before solutions, run [Five Whys Deep Dive](/workshops/five-whys-deep-dive). For the written Five Whys agenda, read [how to run a Five Whys workshop](/blog/how-to-run-a-five-whys-workshop). Guests join with a link either way. ## Frequently asked questions ### What is a problem statement? A problem statement is a short description of who is affected, what they need to do, what gets in the way and why that matters now. It frames discussion. It should not smuggle in a preferred solution. ### Who should write the problem statement? Write it with the people who see different parts of the work: someone close to users or operators, someone who knows delivery constraints and a decision owner. A solo draft can start the conversation. The team should critique and converge so the frame is shared. ### How long does it take to write a problem statement with a team? Plan 20–40 minutes for diverge, critique and converge when the challenge is already roughly known. On Clarvelo’s Design Sprint: Day 1, the Problem Statement exercise is about 25 minutes inside a longer 68-minute session. ### Which Clarvelo workshop helps you write a problem statement? Design Sprint: Day 1 opens with a Problem Statement exercise, then moves into How Might We, Crazy Eights and a private vote in one session. If the problem is already named but the cause is unclear, Five Whys Deep Dive digs into the cause first and then reframes it with How Might We. ### How is a problem statement different from Five Whys? A problem statement agrees what situation you are talking about. Five Whys digs under a recurring symptom to find a deeper, testable cause. Use the statement to align the frame; use Five Whys when the first explanation is still too shallow. --- Written by Joe Corcoran for [Clarvelo](https://clarvelo.com). Clarvelo is an AI facilitator that guides teams through retrospectives, decision making, problem solving, prioritization and 40+ workshop formats. [Read more on the Clarvelo blog](https://clarvelo.com/blog) or [try the live AI-facilitated workshops](https://clarvelo.com).