7. Problem definition
The first half of the sprint ends in a problem statement: who has it, in what situation, why it matters, what they do now, and why that fails, written in the customer's own words with a number attached. Take it back to customers and experts and never ask whether they have the problem. Ask what would happen if it went away. Four red flags mean you are not ready. Five conditions mean you are.
- How do you write a problem statement for a startup?
- How do you validate a problem statement with customers?
- When is a startup ready to move from problem to solution?
§The question this chapter answers: can we say, in the customer's words and with a number, what is going wrong for whom?
§This is where the first half of the cashes out. Everything you have read, heard and clustered becomes a few lines that the whole team agrees are true. Teams rush this step because they believe they already understand the problem. The story below is why they should not.
§ 7.1The statement#
§Five lines. Each has a job.
§For a specific type of person. Not a segment name, a description someone could recognize themselves in. Who is in a specific situation. The context in which the problem occurs, because problems are situational and a statement without a situation is a slogan. The problem is a problem because of a specific impact. The cost, in the customer's terms: money, time, a lost table, a missed deadline, an embarrassment. Currently, they do a specific workaround. What the market has already built, with spreadsheets and habit. Which fails in a specific way. The gap the workaround leaves, which is the only place a new can live.
§Filled in from the conversations in chapter 5:
§Every phrase in that statement came out of someone's mouth. That is the test. If you had to invent a phrase to make the statement work, you have a , not a finding.
§ 7.2Scoring the two or three that survived#
§The matrix from the last chapter left you with a short list. Score each candidate statement on four things: impact, how much it costs when it happens; frequency, how often it happens; urgency, whether the customer is trying to solve it now or someday; and willingness to pay, whether anyone has shown it with money, time or a workaround they resent. A cluster that scores high on frequency and low on the other three is a cluster that will get you users and no revenue. It is the single most common thing early teams build.
§ 7.3The validation loop that never asks the question#
§Take the statement back to five customers and two experts. Do not ask "do you have this problem?" People say yes to that out of kindness, and you have spent weeks learning not to trust a kind yes. Ask instead:
§"What would happen if this problem went away?" A vivid answer means the problem is real. A shrug means it is not. "How are you solving this today?" If the answer differs from your statement, your statement is wrong. "What else have you tried?" This surfaces the competitors and the failed workarounds you missed. "Why haven't you solved this yet?" The answer is usually the real constraint, and it is often not the one you assumed.
§Christensen's jobs-to-be-done framing helps here: you are checking whether the job you named is the job they are hiring for, and the check is in what they say they would do differently, not in whether they agree with your wording.
§ 7.4Red flags#
§Four phrases, from you or from a customer, that mean the statement is not ready.
§"Everyone has this problem." No, they do not. If you cannot say who does not, you have not found who does. "It's a nice-to-have." Translation: nobody will pay. This is a cluster that scored on frequency alone. "People will change their behavior." Maybe. It is very hard, and a statement that requires it should say so and price it in. "The technology will make them change." It almost never does. Capability does not create demand; it lowers the cost of meeting demand that already exists. The AI era has produced a thousand products that forgot this.
§ 7.5Readiness#
§You are ready to move to the second half of the sprint when five things are true. You can explain the problem in a customer's own words. You have evidence of its impact, with a number. You understand the current solutions and exactly how they fall short. You can say roughly what solving it is worth to the person who has it. And everyone on the team agrees on the statement, in writing, including the person who liked a different cluster.
§Marty Cagan names four risks a product must survive: value, usability, feasibility, viability. The problem statement is your first pass at the first of them. If the value risk is not retired here, no amount of building retires it later.
§ 7.6What you leave with#
§A document. The statement, in the five-line form, in the customer's words. The key quotes behind each line. The quantitative evidence you have. The current solutions and why they fail. The impact, in the customer's units. The assumptions still open, and the research gaps you have chosen to carry into Part II rather than close now. This is the document the second half of the sprint argues with.
A well-defined problem is worth more than a hundred solutions. Write it in their words, with a number.
- Clayton Christensen, Taddy Hall, Karen Dillon and David Duncan, Know Your Customers' Jobs to Be Done, Harvard Business Review (2016). hbr.org/2016/09/know-your-customers-jobs-to-be-done
- Marty Cagan, The Four Big Risks (2017). www.svpg.com/four-big-risks
- Ash Maurya, Running Lean, 3rd ed. (2022), on problem-solution fit before product. leanstack.com/books