Validation is a good feeling. Not because it means you’ve “made it”, but because it’s the first time your idea stops being hypothetical.

If you’ve spoken to 5–10 people and they’ve all said some version of “yes, this is annoying” and “yes, I’d pay for something better”, you’ve earned the right to move forward. The next mistake is thinking that means you should start building immediately. The better move is to slow down for one beat and turn what you heard into something you can actually build without guessing.

This is the stage where product work becomes less about spotting problems, and more about shaping the problem into a decision.

Step 1: Make the problem statement specific enough to argue with

Most early problem statements are too broad. They sound correct, but they’re not useful. If your statement can apply to ten different user types, or if it doesn’t include what people are doing today instead, it’s probably still a theme, not a problem.

A good problem statement should force specificity:

• who it’s for
• what they’re trying to do
• where it breaks
• what workaround they’re using today
• what that workaround costs them (time, effort, stress, money, missed moments)
  

If you can write it clearly, you’re already ahead of most first-time builders. If you can’t, don’t build yet. Go back and ask better questions, because the product will inherit the vagueness.

Step 2: Map the current journey, not the product you want to exist

People love skipping this step because it feels like documentation.

It isn’t.

Mapping the current journey is how you stop building features that don’t matter. Write down what happens today, step by step, in the way someone would describe it on a normal day. Include the annoying parts. Include the workarounds. Include where they hand it off to someone else, where they forget, where they abandon it and come back later. If you can, capture the exact moment they feel friction most strongly, because that’s usually the moment your MVP needs to improve first.

This is also where you start seeing leverage. The biggest improvement is often not “more features.” It’s removing one painful step, or collapsing a messy process into something that feels obvious.

Step 3: Decide what your MVP is by removing things, not adding them

Once you’ve mapped the current journey, the temptation is to design the “full” version. The clean version. The version that includes everything you can imagine users asking for. That’s how you end up with an MVP that takes six months.

Your MVP is not the smallest product you can build. It’s the smallest version of the solution that proves you can remove the pain in a way people will actually use.

A lightweight way to keep yourself honest here is MoSCoW:

• Must have: without this, the product doesn’t solve the problem
• Should have: improves the experience, but not required for first proof
• Could have: nice-to-haves that can wait
• Won’t have (for now): explicitly out of scope
  

The “Won’t have” list is the one that matters most. It’s the difference between moving fast and slowly drowning in your own backlog.

Step 4: Prototype the value moment, not the entire product

You don’t need a prototype that shows everything. You need a prototype that shows the moment where the user goes from “this is annoying” to “oh, that’s better.”

That’s usually one of three points:

• the first setup moment (where friction kills adoption)
• the first value moment (where they feel the pain disappear)
• the trust moment (where they decide this is safe, worth using, worth returning to)
  

Prototype those, test them, and pay attention to what happens in the gaps. Where do people hesitate? What do they assume? What do they try to do next without being prompted? Those are the moments that tell you whether your solution is intuitive or just pretty.

And when you test, don’t ask “would you use this?” That question is too easy to say yes to.

Ask what they would do instead, what they’re currently using, how often this happens, and what would make them actually switch.

Step 5: Decide what “success” looks like before you build anything real

Most MVPs fail because the builder doesn’t know what they’re trying to prove. So define it in advance. Keep it simple, and keep it behavioural.

For early B2C products, metrics that matter tend to look like:

• Activation: do they reach the first value moment?
• Time-to-value: how long does it take to get there?
• Completion: do they finish the core flow without dropping?
• Early retention: do they come back soon after?
  

Pick one or two thresholds so you’re not guessing after launch. Something like:

• “If 40% reach the value moment without help, we’re onto something.”
• “If people try it once but don’t return, we haven’t earned the habit yet.”
• “If users share it unprompted, that’s a signal worth building on.”
  

This isn’t about perfect analytics. It’s about being clear on what you’re testing.

Step 6: Write just enough structure so you don’t drift

This is where I like a PRD-lite.

Not a full corporate document. Just enough to keep you honest: the problem statement, the current journey, your MVP scope (MoSCoW), your assumptions, and the success metrics. If you want a lightweight structure for this stage, my PRD-lite template is designed for exactly this point in the process, when you’re moving fast but still need clarity.

Where monetisation fits

If people are already saying they’d pay, that's a good signal. But pricing is easier when the value is real. At this stage, I’d keep monetisation as a future step unless it’s part of the pain itself (for example, they’re already paying for a workaround). First prove the product removes friction and creates repeat behaviour. Then you’ll have something real to price, and the conversation becomes much less theoretical.

Validated problems are rare. But validation isn’t the finish line.

The next job is turning what you heard into something buildable: a clear problem statement, a mapped journey, a small MVP, and a prototype that tests the value moment quickly.

Ship fast. Learn fast. Earn the right to expand.