# How to write a problem statement before choosing a solution. Name the person, situation, task, barrier, and consequence without hiding a feature request inside the problem. Includes a worked example and a practical worksheet. ## The direct answer Write a problem statement by naming a specific person, the situation they are in, the task they need to finish, the barrier, and the consequence. Attach the evidence behind the statement and label what is still assumed. Keep your proposed solution outside the sentence so you can compare different responses. Revise the statement when research changes what you understand. - Author: Daniel Ziedins (https://www.danielziedins.com) - Published: Oct 20, 2026 - Updated: Oct 20, 2026 - Scripture: James 1:19 - Read: 6 min - URL: https://www.agent-six33.com/journal/how-to-write-a-problem-statement > Let every person be quick to hear, slow to speak, slow to anger. > — James 1:19 We need an app is a decision about a response. It is not yet a description of a person's problem. Starting there can make the work feel productive while leaving the most important question unanswered: what is somebody trying to do, and what is actually preventing it? A problem statement is a small discipline of listening. It gives a team something precise enough to investigate without pretending the answer is already known. The format below is an original working aid for a low-risk project, resource, or service. It is not a diagnostic assessment, an eligibility rule, or permission to experiment with somebody's safety or access to essential help. ## 1. Put a person in a real situation. Describe the relevant situation rather than inventing a personality. First-time volunteers preparing for their first session is a more useful starting point than busy people who care. The first phrase tells you when the difficulty occurs and whose experience to investigate. The second could describe almost anyone and cannot guide a useful conversation. Be explicit about whose experience is missing. Someone with a slow connection, a different language preference, or an assisted way of completing the task may encounter a different barrier. Do not add personal details simply to make the statement vivid. Include a circumstance only if it helps explain the task or changes what a useful response would need to support. ## 2. Describe the task without prescribing the channel. GOV.UK's user-needs guidance separates the person's goal from a proposed solution. Make that distinction visible in your document. A person might need to confirm where to arrive and whom to contact; a notification, printed sheet, phone conversation, or clearer page could each help in different circumstances. Needing an app assumes a channel before establishing the task. Write the task as something the person would recognise. Avoid an internal department's objective such as increase engagement when the person's job is choose a suitable role. A team can care about engagement, but the statement should first explain what the person is trying to accomplish. Otherwise you risk improving a dashboard while leaving the actual handoff confusing. ## 3. Separate the barrier from your explanation of it. Record the difficulty and its consequence at the strength your source supports. If a participant says they contacted a coordinator because the page did not identify a meeting point, that is an account of what happened. It is not yet an observed test of the page, proof of the only cause, or a count of everyone affected. Keep an explanation such as the wording is too technical on an assumptions line until you have investigated it. The issue might instead be outdated information, a broken link, an unfamiliar place, or a mismatch between the page and the invitation. A statement that leaves these possibilities open makes it easier to compare responses without defending the first idea somebody suggested. ## 4. Attach a short evidence note and an uncertainty. Beside the statement, record the source, date, context, and whether it is observation, a participant account, or a team assumption. Use private source IDs rather than copying identifying material into a widely shared brief. Preserve contradictions too: a person who completed the task easily may have had information or assistance that another person lacked. If there is no direct evidence yet, call the statement provisional. That is a useful status, not a reason to dress it up as a validated insight. Decide what would change your understanding and whom you should learn from next. A statement can guide initial research before it is supported, provided the team does not quietly treat that provisional wording as an established fact. **Investigate the recent experience:** Use neutral questions and a concrete story to learn what actually happened. https://www.agent-six33.com/journal/first-five-customer-interviews ## 5. Rewrite a solution request as a bounded problem. This hypothetical example is not a SIX33 research result. A team starts with we need a volunteer app. Its only evidence is two recent messages from first-time volunteers asking where to meet and whom to contact. Those messages support investigating arrival information. They do not establish demand for an app or show how common the difficulty is. A provisional statement could be: before their first session, some first-time volunteers cannot confirm the meeting point and contact person from the information they received, so they need another exchange with the team before they can plan their arrival. The evidence note identifies the two messages, the invitation version, and the unanswered question of whether the information was missing, hard to find, or out of date. A next learning step is to review the invitation and ask people about their latest preparation experience. If you later observe people finding the details successfully but still being unsure about transport, revise the problem instead of forcing the new evidence into the arrival-information explanation. A solution-neutral statement should make a changed understanding possible, not merely make an old feature request sound more thoughtful. ## 6. Use the statement to choose a learning step, then a brief. Ask a colleague to name two materially different responses that could address the statement. If the only possible answer is the feature you already wanted, check whether the wording has smuggled in that feature. Also ask whether the person, moment, barrier, and consequence can be understood without an explanation from the author. Do not promise an improvement the statement has not tested. Fewer clarification messages, for example, might reflect clearer information, fewer participants, or people deciding not to ask for help. Decide what you need to learn before choosing a measure. Once the task and uncertainty are clear enough, turn the proposed delivery into a brief with an owner, scope, exclusions, and an appropriate evidence gate. Keep the earlier version and the reason for any revision. A short record of what changed prevents a team from remembering that it knew the answer all along. The goal is not a perfect sentence that survives forever. It is a precise, revisable description that helps people spend their next effort on a real difficulty rather than on the most attractive imagined solution. **Give the work a clear boundary:** Turn a supported problem and a proposed response into a complete, owned piece of work. https://www.agent-six33.com/journal/how-to-write-a-one-page-project-brief ## Problem statement and evidence worksheet Copy this blank template into your private working document. It contains no journal notes or tool drafts. ```markdown # Problem statement and evidence worksheet Version and date: [version / date] Owner and review date: [person / date] Status: [provisional / supported in this context / needs revision] ## Statement Person and relevant situation: [who / when / context] Task they need to finish: [goal in their words, not a feature] Barrier: [specific difficulty] Consequence: [what happens next, at the strength the evidence supports] Working sentence: [person + situation + task + barrier + consequence] ## Evidence boundary Source IDs and dates: [private pointers, not public personal details] Evidence type: [observation / participant account / assumption] Experience or version involved: [context] What the evidence supports: [bounded finding] What it does not establish: [prevalence / cause / demand / other limits] Contradictory experiences and missing perspectives: [details] Possible explanations, kept separate: [assumptions] ## Next learning step Question that could change the statement: [uncertainty] Who or what to learn from: [relevant people / existing material] Method and privacy boundary: [method / access / permission] Two different possible responses, not commitments: [option A / option B] Next decision and owner: [decision / person / date] Revision record: [date / change / reason] A provisional statement is not a validated need. Keep identifying source material private and use appropriate review for higher-risk work. ``` > **The short version:** A useful problem statement leaves room for the answer to surprise you. ## Questions ### What are the parts of a useful problem statement? Name the person, situation, task, barrier, and consequence. Keep a short evidence note beside the sentence, including source dates, limits, assumptions, and missing perspectives. The statement should describe a difficulty without requiring one particular solution. ### What is the difference between a problem statement and a project brief? A problem statement describes the difficulty to understand. A project brief agrees on a proposed piece of work: its promise, scope, owner, constraints, and decision gate. A brief can refer to a problem statement, but a completed brief does not prove the original problem or proposed solution. ### Can a problem statement be written before research? Yes, as a clearly labelled provisional statement. Use it to choose questions and relevant participants, then revise it from evidence. Do not present an initial assumption as an established need simply because it has been written in a structured format. ### How do I know if my problem statement already contains a solution? Ask whether it requires a particular feature or channel and whether two genuinely different responses could address it. A person needing to confirm an arrival time leaves options open; a person needing an app notification may prescribe an answer before the context is understood. ## Sources - GOV.UK Service Manual: learning about users and their needs: https://www.gov.uk/service-manual/user-research/start-by-learning-user-needs — Reference for distinguishing a person's goal from a proposed solution. The worksheet and volunteer-arrival example are original practical illustrations. - GOV.UK Service Manual: how the discovery phase works: https://www.gov.uk/service-manual/agile-delivery/how-the-discovery-phase-works — Further reading on understanding the problem and constraints before committing to build. This article is not a formal discovery process or an endorsement by GOV.UK. ## Explore the wider topic - Research and testing: https://www.agent-six33.com/journal/topics/research-and-testing — Daniel Ziedins · https://www.danielziedins.com · AGENT SIX33 https://www.agent-six33.com/journal/how-to-write-a-problem-statement