How to Write a Problem Statement: A Step-by-Step Guide for Business Decisions

To write a problem statement, define what's wrong, quantify the gap, set a timeframe, and frame the decision as a key question. A well-written problem statement turns a vague concern into a focused investigation that your team can actually solve.

A problem statement is a concise description of an issue that needs to be addressed. It specifies what is happening, the magnitude of the impact, who is affected, and by when a decision or solution is needed. Without this clarity, teams waste time debating scope, chasing symptoms, or solving the wrong problem entirely.

The key question is the heart of any problem statement. It's the specific question you're trying to answer—phrased so that answering it will drive a decision. 'Revenue is down' is an observation. 'What should we do to return to 15% year-over-year revenue growth by Q2?' is a key question that can be investigated and answered.

Writing a problem statement requires moving from a general concern to a specific, measurable, time-bound key question. Follow these five steps to convert any business problem into a statement your team can act on.

1. State the observable symptom. Start with what you can see: revenue is declining, churn is rising, product launches are delayed. Don't interpret or assign blame yet—just describe what's happening.

2. Quantify the gap. How big is the problem? 'Sales are down' becomes 'Sales are down 12% year-over-year.' 'Customer satisfaction is low' becomes 'NPS dropped from 45 to 28 in six months.' Numbers create shared understanding and reveal whether the problem is worth solving.

3. Identify who is affected and who decides. Specify the stakeholder: a product line, a region, a customer segment, or the whole company. Name the decision-maker—the person or team who will act on your answer. This scopes the investigation and ensures relevance.

4. Set a timeframe. Every problem statement needs a deadline. 'We need to decide by end of quarter' or 'The board expects a recommendation in 30 days.' A timeframe forces prioritization and prevents analysis paralysis.

5. Frame the key question. Combine the elements into a single question: 'What should [decision-maker] do to [close the gap] for [affected stakeholder] by [deadline]?' This is the question your analysis will answer. If you can't state the key question clearly, you haven't finished defining the problem.

A good problem statement meets SMART-style criteria: it is Specific (not vague), Measurable (quantified), Actionable (someone can decide), Relevant (worth solving), and Time-bound (has a deadline). If any element is missing, the problem statement will fail to focus your team.

Bad problem statements share common flaws. They're too broad ('improve customer experience'), lack numbers ('sales could be better'), blame instead of describe ('the sales team isn't performing'), or skip the key question entirely. These statements generate meetings, not solutions.

A strong problem statement does three things: it aligns the team on what success looks like, it scopes the investigation so you don't boil the ocean, and it connects directly to a decision. When you finish your analysis, you should be able to answer the key question with a clear recommendation. For more on structuring recommendations, see answer-first writing.

Consider a B2B SaaS company whose net revenue retention (NRR) has fallen from 108% to 94% over three quarters. The CEO hears complaints: 'Customers are churning,' 'The product isn't sticky,' 'Support is overwhelmed.' These are symptoms, not a problem statement.

Here's how to convert this into a sharp problem statement: The observable symptom is declining NRR. The quantified gap is 14 percentage points (from 108% to 94%) over three quarters. The affected stakeholder is the mid-market customer segment (where most of the decline occurred, per cohort analysis). The decision-maker is the VP of Customer Success. The timeframe is 60 days, because the board meets in Q1 and needs a retention plan.

The key question becomes: 'What should the VP of Customer Success do to return mid-market NRR to 105% within 60 days?' This statement is specific, measurable, and actionable. It scopes the investigation to mid-market customers (not enterprise, not SMB) and sets a realistic target (105%, not 108%). From here, you can build a root cause analysis to find why mid-market NRR dropped, then use a decision matrix to prioritize interventions.

How long should a problem statement be? One to three sentences for the statement itself, plus the key question. If you need a paragraph to explain the problem, you probably haven't narrowed it enough. The key question should be a single sentence.

What if I don't have data to quantify the gap? Estimate. 'We believe churn increased by approximately 20% based on support ticket volume' is better than 'churn is up.' State your assumptions explicitly, then refine as you gather data. Hypothesis-driven problem solving works even with imperfect information.

Can a problem statement change during an investigation? Yes, and it often should. As you learn more, you may discover the real problem is different from your initial framing. Update the problem statement when your understanding changes—don't cling to a framing that no longer fits the evidence.

What's the difference between a problem statement and a hypothesis? A problem statement defines what you're trying to solve. A hypothesis is a testable explanation or proposed solution. First write the problem statement, then generate hypotheses about causes or fixes. The problem statement stays stable while you test and discard hypotheses.

A problem statement is the starting point, not the destination. Once you've framed the key question, the next step is to break it into investigable parts using a MECE issue tree. Each branch of the tree becomes a sub-question you can answer with data or analysis.

Razn is a workspace for structuring problems and writing answer-first documents. Use it to turn your problem statement into a MECE issue tree, investigate each branch, and synthesize your findings into a recommendation. When you need to move from 'we have a problem' to 'here's what we should do,' Razn helps you structure the work.

The discipline of writing a clear problem statement pays dividends throughout your investigation. Every analysis decision—what data to gather, which branches to prioritize, when to stop—becomes easier when you can check it against the key question. Start with the problem statement, and the rest of the work has a foundation.