L0. Problem

Outputs doc: outputs.md, L0 section. Fill it in as you work through the steps below. Raw interview captures go in captures.md. L1 reads the L0 section before starting.

Jump to: Diagnostic · Step 1 · Step 2 · Step 3 · Step 4 · Step 5 · Summary · Assumption sweep

What this layer is: The observation that a real problem exists, that people struggle with it, and that someone might pay to have it solved. No product yet. No solution yet. Just the problem and the evidence that it is real.

Why it comes first: Every layer downstream is an answer to a question that L0 sets up. If the problem definition is wrong, narrow, or assumed, the error surfaces quietly in L1 (the audience is too broad to target) and L2 (the value proposition convinces no one), and loudly in L5 (lead generation numbers look fine but nothing converts). You rarely know L0 is broken until you are two or three layers deep into something that is not working.

What finishing this layer produces: A written problem statement in the L0 section of outputs.md that a skeptical person could try to falsify, backed by at least one real primary source.

Diagnostic: is L0 actually done?

Before building anything, answer these questions in writing. Vague answers mean the layer is not finished.

1. Can you describe the problem without mentioning your product? If your problem statement contains the words “our solution,” “we help,” or your product name, you are describing a solution, not a problem. Strip it out and try again.

2. Can you name someone who has this problem right now? Not a persona. A real person, a real company, or a real situation you have observed. If you cannot name a real case, you are working from assumption.

3. Do people currently try to solve it, and how? A problem nobody is currently trying to solve is either not a real problem or not painful enough. What is the existing workaround? A spreadsheet, an agency, ignoring it entirely? The workaround is your true competition, not a rival product.

4. Is there evidence people find this painful enough to pay to solve? Evidence can be: someone is already paying for an inferior solution, someone has asked you to build this, someone has described the cost of not solving it in money or time. Absence of this is a flag, not a dealbreaker, but it needs to be noted.

5. Is the problem scoped? “B2B companies struggle with marketing” is not a problem statement. “Series A SaaS companies with a sales team of five or more lose deals in the follow-up stage because they have no system for staying in contact between first meeting and close” is a problem statement. The difference is not detail for its own sake; it is specificity that makes L1 possible.

If you answered all five clearly and in writing, L0 may already be done. Jump to the L0 section of outputs.md, fill in the fields, check the checklist, and move to L1. If not, work through the steps below.

Step 1. Write the raw problem

Duration: 30 minutes

What to do:

1. Open the L0 section of outputs.md and go to the “Problem statement (draft)” field.

2. Write a first-pass paragraph without editing. Do not worry about precision yet. Just get your assumption on paper. Use this prompt to get started:

   “I think [type of person or company] struggles with [what]. The consequence is [what happens because of it]. Currently they deal with it by [what]. That is inadequate because [why].”

3. Fill in every bracket, even if the answers feel uncertain. Uncertainty here is information, not a problem. A blank bracket means you are assuming that piece of the answer, and that assumption needs to surface before you build anything on top of it.

4. Read the paragraph back once. For each part you filled in from gut feeling rather than direct evidence, log it in assumptions.md now (Layer: L0, Status: Untested). Do not wait until the end of the phase.

5. If more than one candidate problem is in play, score them against each other in the matrix below (it is also in the L0 section of outputs.md) and carry the strongest forward. This is a first pass on current belief; refine the scores after interviews. Use a 1-5 scale in each column.

   Candidate problem	Severity of pain (1-5)	Frequency (1-5)	Evidence people pay (1-5)	Reachable sufferers (1-5)	Total

Do not edit it into something polished. The rough draft exists so you have something concrete to pressure-test in the next steps.

Step 2. Reframe from the customer’s point of view

Duration: 30-60 minutes

Your draft from Step 1 is written from the outside in: you described what you observe. This step rewrites it from the inside out, what the customer experiences, in their situation, trying to make progress. That shift matters because it removes product thinking and forces you to describe the problem as it exists in someone’s actual day, before any solution appears.

The perspective statement has a specific shape:

When [situation], I want to [motivation], so I can [expected outcome].

What to do:

1. Rewrite the problem you captured in Step 1 as a perspective statement. Fill in the three parts:

   • Situation: When does the problem occur? What triggers the person to want something done?
   • Motivation: What are they trying to accomplish in that moment? Use their language, not yours.
   • Expected outcome: What does success look like to them? Not “they use your product.” What changes in their work or life?

2. Check that your perspective statement passes these three tests:

   • No product in it. The problem exists before your product exists.
   • Active tense. “I want to” not “I need a tool to.” This is something they are trying to do, not something they want to buy.
   • Specific situation. “When I have too many leads to track manually” is a situation. “When I have a sales problem” is not.

3. Write two or three alternative versions if the first feels too broad. Different phrasings surface different angles, and the one that feels most precisely true is the one to carry forward.

4. Copy the best version into the L0 section of outputs.md alongside your draft problem statement. You will use both in Step 5.

5. Check the situation and motivation fields. If you wrote them from your own inference rather than something a real person described, those are assumptions. Log them in assumptions.md (Layer: L0, Status: Untested). The perspective statement is only as good as the evidence behind it.

Why this matters for downstream layers: The perspective statement is what L3 (Message) will eventually need to translate into copy. If the problem is described from your point of view, the message will be about your product. If it is described from the customer’s point of view, the message will be about their situation, which is what actually lands.

Step 3. Stress-test the scope

Duration: 30 minutes

Read your draft statement and perspective statement back and apply these filters one at a time. For each one that fails, revise before moving on.

Filter 1: Is “type of person or company” specific enough that you could make a list of ten of them right now? If not, narrow it. What industry, company size, role, or situation separates the people who have this problem acutely from the people who have it mildly?

Filter 2: Does the problem exist before your product exists? If your product disappearing would make the problem disappear, you have described a product dependency, not a problem. Rewrite it from the customer’s point of view.

Filter 3: Is the consequence something real people have expressed as a cost, or is it something you assume they must feel? “They lose time” is not a consequence. “An account executive spends four hours a week manually chasing warm leads that go cold anyway” is a consequence. If you are not sure, log it in assumptions.md (Layer: L0, Status: Untested) and mark the consequence field in the L0 section of outputs.md as unconfirmed. Step 4 will test it.

Filter 4: Is the current workaround actually what people do, or is it what you imagine they do? If you are not sure, this is a research task, not a writing task. Log it in assumptions.md (Layer: L0, Status: Untested) and leave the workaround field blank in the L0 section of outputs.md until Step 4 confirms it.

Filter 5: Does the problem drift as you read it? You may have started with “Series A SaaS companies” and by the last sentence you were describing “any company with a sales team.” Notice the drift. Narrow back down and keep the scope consistent throughout the statement.

After working through the filters, update your draft in the L0 section of outputs.md.

Step 4. Validate with interviews

Duration: 2-5 hours active work, 3-7 days calendar time | Target: 5-10 conversations

Interviews are the highest-confidence validation method at L0. A well-run problem discovery interview does three things at once: it confirms whether the problem is real, it surfaces the exact language the person uses to describe it (which L3 will need later), and it reveals the workaround in enough detail to evaluate it. Aim for five conversations minimum. Stop when you are hearing the same things repeatedly and are no longer surprised.

Do not skip this step by substituting desk research. Forum posts and review sites are useful supplements, not replacements. The thing you cannot get from secondary sources is the pause before someone answers, the tangent they go on, or the offhand remark that turns out to be the most important thing they said.

4a. Recruit your interviewees

Duration: 30-60 minutes to set up, then wait for responses

You need people who actually have the problem you described in Steps 1-3. Not people who might have it. Not people who are politely interested in your project.

Who to target:

Look for people who are already trying to solve this problem. Signs of that: they use a workaround tool, they have hired someone to manage the problem, they have complained about it publicly, or they work in a role where the problem is structurally inevitable.

How to find them:

• Warm network first. People you know, or one degree away. Ask a mutual contact for an introduction. Conversion is highest here and the conversations tend to be more honest.
• LinkedIn outreach. Search for job titles and companies that match your L0 scope. Send a short direct message. The research framing converts better than any other angle: you are not selling, you are learning.
• Communities. Slack groups, Discord servers, LinkedIn groups, or subreddits where your target people are active. Post a short research request or reach out to people who have posted about the problem.
• Review sites. People who leave detailed negative reviews of workaround tools have the problem and are already articulate about it. Some will respond to a thoughtful outreach message.

Outreach message template:

Hi [name], I am researching how [type of person] handles [problem area] and would love to hear how it works in practice at your company. Not a sales call, I am in the research stage and genuinely trying to understand the problem before building anything. Would you have 20 minutes in the next couple of weeks?

Keep it short. The research angle works because it is honest and because people like being the expert in a conversation. If someone asks what you are building, you can say you are still figuring out whether there is a real problem worth solving, which at L0 is true.

Target: 5-10 conversations. Book them across a short window (one to two weeks) so your synthesis is coherent and your thinking is fresh.

4b. Run the interview

Duration: 20-30 minutes per interview

The goal of every question is to build a picture of the problem from the inside: what triggers it, what the person is trying to do when it appears, what it costs them, and what they currently do about it. That picture is what you will use in Step 5 to write the final problem statement, assembled from what people actually say, not from what you assumed in Steps 1-3.

Always record with permission. Transcripts catch the things you miss while thinking about your next question. If someone will not consent to recording, take notes immediately after, not during.

Open every interview the same way:

“Thanks for making time. I want to understand how you handle [problem area] today, your actual experience, not what you think I want to hear. I will ask questions and mostly listen. There are no right answers. Okay to record?”

Do not read the guide below as a script. Follow the thread the person opens. If they say something surprising, go deeper on that before moving to the next category.

Context questions (5 minutes), establishing the situation

These establish when and where the problem appears. You are trying to understand what is happening in their world when it shows up.

• Walk me through what your role looks like day to day.
• Where does [problem area] fit into that? How often does it come up?
• Who else on your team is involved when [problem situation] happens?

Problem questions (10 minutes), understanding the struggle

This is the core of the interview. You want their lived experience, not their theory about the problem and not their wish list for a solution.

• Can you walk me through the last time [problem situation] happened? What were you doing, and what did you do next?
• What is the most frustrating part of how you handle this today?
• What usually goes wrong?
• How do you know when it has gone wrong?

Impact questions (5 minutes), understanding the cost

What does failure cost them, and what would success actually look like? Concrete, not abstract.

• What happens when this does not get handled well?
• Has that ever cost you something measurable: time, money, a missed outcome?
• How often does that happen?
• What would it look like if this just worked?

Workaround questions (5 minutes), understanding current behavior

The workaround is what they do instead of using your (non-existent) product. Understanding it reveals your real competition and tests your assumption about the current state.

• What do you currently do about this? Walk me through your actual process.
• Have you tried anything else? What happened?
• What made you choose [workaround] over other options?
• What would you change about it if you could?

Closing

• Is there anything about this I did not ask that you think is important?
• Is there someone else you think I should talk to?
• Can I follow up if I have more questions?

4c. Capture immediately after each interview

Do this within an hour of each conversation, before the next one. Memory degrades fast and you will conflate interviews if you batch the capture.

For each interview, add an entry to the L0 section of captures.md using this structure:

Interview [number]
Interviewee: [role, company size or type, anonymise if needed]
Date:

Top 3 quotes (verbatim):
1.
2.
3.

Surprises (anything you did not expect):

Consequence they described (concrete cost):

Workaround they use:

Situation trigger (when does the problem hit them?):

Pain level (1-5):

Any assumptions from Steps 1-3 this confirmed or challenged:

The verbatim quotes are the most valuable output of the interview. They are the raw material for L3 messaging. Capture them exactly, not paraphrased.

4d. Synthesise across interviews

Do this after you have completed at least five conversations.

Go through all your per-interview captures in captures.md and look for patterns. Update the Interview synthesis fields in the L0 section of outputs.md, covering:

Recurring pain points. Which problems came up in more than one interview? Capture them in the table below (also in the L0 section of outputs.md), in order of frequency. The ones that surfaced in every conversation are load-bearing.

Language patterns. Which exact words or phrases did multiple people use to describe the problem? These are not just interesting, they are future headline copy. Quote them verbatim.

Consequence range. How severe was the impact across interviews? Did some people barely feel it and others feel it acutely? That tells you something about who your real target is within the broader group.

Workaround map. Did everyone use the same workaround or different ones? Lay them out in the table below (also in the L0 section of outputs.md). Different workarounds often reveal meaningful sub-segments, and each one is a form of your real competition.

Surprises. What came up that you did not ask about and did not expect? These are often the most strategically important findings.

Rewrite the perspective statement from the evidence. Go back to what you wrote in Step 2 and rewrite it from what the interviews showed. Fill in the three parts from real data, not from inference:

• Situation: when does the problem actually appear, according to the people you talked to?
• Motivation: what were they trying to accomplish when it showed up?
• Expected outcome: what did they say success would look like?

If the statement changed, note what shifted. If it held, that is confirmation. Update the L0 section of outputs.md with the revised version.

What changed in your problem statement. Compare what you wrote in Steps 1-3 to what you now know. Update the problem statement in the L0 section of outputs.md to reflect what the interviews showed. If the scope changed, note it in assumptions.md.

4e. If you genuinely cannot get interviews

If you cannot reach anyone in the time available, use secondary sources as a temporary substitute, not a permanent one.

• Review sites (G2, Capterra, Trustpilot) for workaround tools. Read the negative and mixed reviews. People describe the problem in detail when reviewing the thing they use to manage it.
• Reddit, LinkedIn posts, or community threads where people have described the problem in their own words.
• Job postings that describe the problem as a responsibility. A company hiring to manage something is experiencing it.

Document each source in the L0 section of captures.md using the same structure as a per-interview capture, noting that it is secondary. Log the absence of interviews as an assumption in assumptions.md. L0 built entirely on secondary sources is weaker than L0 built on conversations, and that needs to be visible.

Step 5. Write the final problem statement

Duration: 30 minutes

You now have a draft statement, a customer perspective statement, a stress-tested scope, and at least one primary source. Write the final version.

A complete problem statement has four components. Write one sentence for each:

1. Who: The specific type of person or company that has this problem.
2. What: The problem itself, described in terms of what they experience, not what they need.
3. Consequence: What it costs them to have the problem unsolved. Concrete, not abstract.
4. Current state: What they do instead, and why that is not good enough.

You can combine these into a single paragraph or keep them as four separate sentences. Format does not matter. Precision does.

Template:

[Who] struggle with [what]. Because of this, they [consequence]. Most currently [workaround], but that [why the workaround fails].

Example (filled in):

Series A B2B SaaS companies with a direct sales team struggle to stay in contact with warm prospects between first meeting and contract signature. Because of this, deals go quiet and close in a competitor’s favour or not at all. Most currently rely on individual salespeople to follow up manually, but that depends on the discipline of each rep and produces no institutional knowledge about what works.

What to do:

1. Write the final statement directly in the L0 section of outputs.md, in the “Problem statement (final)” field.
2. Read it once pretending you are a skeptical colleague who wants to argue with it. Where does it feel soft? Tighten those parts.
3. Run the diagnostic from the top of this page one more time. If all five questions now have clear written answers, L0 is done.

What you’ve built

After completing the steps above, the L0 section of outputs.md should contain:

This is not a deliverable for anyone else. It is a constraint on L1.

Assumption sweep

Before moving on, scan the L0 section of outputs.md for any field you filled in from reasoning rather than evidence. Common ones at L0:

• The type of person or company (did you observe this or infer it?)
• The consequence (did someone tell you the cost, or did you estimate it?)
• The workaround (did you see someone use it, or assume they must?)
• The situation trigger in your perspective statement (is this what you observed, or what you imagined?)

Each unconfirmed field is an assumption. Log it in assumptions.md now if you have not already. A long list here is not failure; it is an honest picture of what the interviews still need to confirm.

What this layer hands off to L1

Before moving on, confirm the L0 section of outputs.md is complete. L1 opens by reading it. Specifically, L1 needs:

• Your scoped problem statement (the four-component version from Step 5)
• Your perspective statement (revised from interview evidence)
• At least one primary source entry
• The named workaround and why it is inadequate

The precision of your L0 statement sets the ceiling on how sharp your L1 audience can be. If you wrote a broad problem statement, your audience will be broad. That is not an L1 problem. That is an L0 problem. Go back.

The other thing L0 hands off: the workaround. The people who have this problem and are currently using the workaround are usually your best early audience. L1 will ask you to make a sharper version of that observation.

Common failure modes

“We did customer discovery, so L0 is done.” Customer discovery surfaces problems; it does not automatically produce a written, scoped problem statement. If you cannot point to the statement in outputs.md, it is not done.

The problem statement is actually a product pitch. Read it again. If a skeptical investor could say “that just sounds like you describing your product,” rewrite it from the customer’s point of view.

The problem is real but not painful enough. Some problems are real and widely acknowledged and nobody pays to solve them because the cost of the workaround is lower than the cost of switching. This does not mean the problem is wrong; it means L2 will be harder, and you should note it in the L0 section of outputs.md under scope notes.

The scope crept during writing. You started with “Series A SaaS companies” and by paragraph three you were talking about “any company with a sales team.” Notice the drift. Narrow back down.

The perspective statement is still product-shaped. “When I need a CRM, I want to track my leads” is not a customer perspective. That is a product description in disguise. A real perspective statement describes a situation that exists before any product exists: “When a deal goes quiet after a first meeting, I want to know whether to keep pursuing it or move on, so I can focus my follow-up time on deals that are actually alive.”

Sources

• The Mom Test by Rob Fitzpatrick. The foundation for the interview approach in Step 4. Covers how to ask questions that produce honest answers rather than polite ones, and why asking about problems beats asking about solutions.
• Value Proposition Design by Alex Osterwalder, Yves Pigneur, Gregory Bernarda, and Alan Smith. The customer profile section covers customer jobs, pains, and gains, the framework behind the perspective statement format in Step 2.