How to validate product ideas before building an MVP

April 1, 2025
Dana Vetan

Most teams jump straight to building an MVP — and produce a perfectly built minimum viable product for an idea nobody validated as worth building. The more reliable move, especially when stakeholders are misaligned and your credibility is on the line, is to validate the problem first, then the solution, and only then commit to the build. This article walks through what goes wrong when teams skip that work, why it happens inside large organizations, and the two-step move that fixes it.

You will leave with the language to name what is breaking before you commission an MVP, a clear sequence to follow instead, and a set of links to the methods that produce each step.

Validating a product idea before an MVP means testing the problem before the solution — and the solution before the build. Skip either step and you produce a perfectly built MVP for an idea nobody validated as worth building.

What going wrong looks like

The most expensive product failures inside large organizations are not failed MVPs. They are well-built MVPs of an idea nobody validated as worth building.

The pattern is familiar to anyone who has shipped product inside a complex organization. The roadmap looks reasonable. The data is there. The team moves. The product launches. And somehow the result lands short of what was promised.

Five symptoms show up again and again:

  • Features no one asked for. The MVP shipped what stakeholders lobbied for, not what customers needed.
  • Half-hearted releases. Engineering built it, but no one in the leadership group is willing to put their name on it.
  • Zero customer pull. Adoption metrics never hit the threshold that would justify a second investment round.
  • Internal blame for execution. The post-mortem points at the build team. The actual failure was upstream.
  • A team that spent six months on a product they no longer believe in. Credibility is eroded — yours, your team's, and the leadership group's tolerance for the next bet.

If any two of those describe a recent launch in your organization, the problem was not execution. The problem was that the team committed to an MVP before anyone had validated whether the idea was worth building at all.

Why this happens inside large organizations

Three structural dynamics push teams to commit to an MVP before the upstream work is done.

Inside large organizations, MVPs often become political. Everyone wants their slice. The pressure to move fast is real, the calendar is full of stakeholder meetings, and the team is rewarded for visible activity. The default next move after any product idea is let's build an MVP and see what happens — not because the team is careless, but because the alternative requires saying no to something a senior leader is pushing.

The three dynamics that make this hard to catch in the moment:

  • Stakeholders are misaligned but nobody admits it. The leadership group has agreed on the direction — "do something about retention" — without agreeing on the actual problem. The team moves into solution mode anyway, because that is where the energy is.
  • Customer insights exist but stay disconnected. Research is sitting in PDFs, decks, interview notes, and support tickets. The volume makes it impossible to act on. Every meeting reopens the same questions, because nobody has translated the evidence into a shared picture the room can engage with.
  • The pressure to ship outweighs the pressure to validate. Validation feels like a slowdown. Building feels like progress. By the time anyone notices the underlying problem was never properly framed, the budget is committed and the team is three sprints in.

For a product leader inside this dynamic, the failure mode is especially expensive. You are not only trying to ship features. You are protecting your credibility, holding your team's confidence, and rebuilding stakeholder trust that the last initiative may have eroded.

The way to protect all three is to validate the idea before you commit to the build.

What does validating a product idea actually mean?

Validating a product idea means answering two questions, in sequence, before any engineering team commits to a build: Is this idea pointing at a real problem worth solving? and Does our proposed solution survive contact with real users?

Each question lives in a different room and produces a different output. Skipping either does not make the validation faster — it makes the eventual failure more expensive.

  • Question 1 — the problem. Before any solution gets prototyped, the senior decision-makers need to agree on what problem actually matters. Vague mandates produce vague MVPs.
  • Question 2 — the solution. Once the problem is clear, a proposed solution direction needs to be tested with real users. A team's confidence in a direction is not evidence. A customer holding the prototype is.

What gets built afterward is no longer a hopeful MVP. It is an MVP the leadership group has already decided is worth shipping, framed precisely enough to brief engineering on, with a solution direction that has already survived contact with real users.

The next sections describe the methods that answer each question.

The method that answers Question 1: Problem Framing

A Problem Framing workshop is a one-day structured session for six to eight senior decision-makers that produces a validated problem statement — clear enough that a build team could act on it Monday morning.

The workshop takes a vague mandate — "do something about retention," "modernize the customer experience," "explore opportunities in this segment" — and runs the room through three movements:

  • The business context. What is the strategic frame the problem sits inside? What metric is the leadership group accountable for? What constraints shape the answer?
  • The customer reality. What do we actually know about the people affected? Where does the existing research disagree with itself? What evidence are we treating as fact that is actually assumption?
  • The convergence. What is the single problem statement the room agrees on, written precisely enough that a sprint team could begin work on Monday morning?

Two to three weeks of preparation precede the workshop. The preparation translates messy customer research — PDFs, decks, interview notes, support tickets — into a single visual map the room can engage with. The map is the artifact that makes alignment possible.

The output is a validated problem statement co-owned by the senior stakeholders. A strategic reset button. No more circular debates. Just clarity.

The method that answers Question 2: Enterprise Design Sprint

An Enterprise Design Sprint is a four-day structured process that takes a defined problem and produces a tested prototype with real customer feedback — before the team commits engineering time at scale.

The sprint runs with a cross-functional team of five to seven hands-on experts plus one Decider — the senior stakeholder who makes the call when the team needs to converge.

The four days follow a defined sequence:

  • Day 1 — Understand and define. Align on goals, map the customer journey, surface assumptions, and identify the highest-leverage moment to focus the rest of the week on.
  • Day 2 — Sketch and decide. Generate solution directions individually. Critique structurally. Converge on one direction worth prototyping. The Decider makes the call.
  • Day 3 — Prototype. Build a high-fidelity, customer-facing prototype using AI-assisted tools like Uizard, v0, or Lovable. What used to take a full day of design work now takes a few hours, which is why a four-day sprint is now standard.
  • Day 4 — Test with real users. Five customers, scheduled interviews, prototype on the table. Watch what works. Watch what breaks. Capture the questions they ask that the team never thought to ask.

You are not validating features. You are validating value.

The output is a tested prototype and direct evidence of how real users respond — enough to make a confident build, iterate, or kill decision.

The artifact that makes the decision: the Replay Report

A Replay Report is the structured artifact a sprint team produces after testing — the document that turns four days of work into a build, iterate, or kill recommendation the leadership group can act on.

The Replay Report does three things:

  • Shows exactly what was learned from real users.
  • Recommends the next move: build, iterate, or pivot.
  • Communicates the strategy to senior leaders with the evidence to back it.

This is the artifact the product leader walks into the next stakeholder meeting with — the proof that the team has done the validation work before asking for engineering commitment.

All three recommendations are useful outcomes. A killed idea after a four-day sprint costs the organization a week. The same idea killed after six months of engineering build costs a quarter and a team's morale.

What the MVP looks like after this work

After the problem is framed and a solution direction has tested well with real users, the MVP becomes a focused, fast, customer-backed move rather than a political one.

The MVP that gets commissioned at this point is materially different from the MVP a team would have built at the start.

  • The team knows which problem it is solving, because the leadership group agreed on it in a Problem Framing workshop.
  • The team knows what exactly about the problem matters, because the workshop produced a precise problem statement.
  • The team knows that a customer-facing solution to this problem can plausibly work, because the Design Sprint tested a prototype with real users and the prototype landed.

The MVP is now a vehicle for testing the next layer of uncertainty — usually whether the validated solution can be built at scale, whether the unit economics work, or whether the operational model holds up under real demand. Those are real questions. They are also much narrower questions than will anyone want this?

You are not launching to prove something to leadership. You are launching to solve something for customers.

Three questions to ask before you commission an MVP

Before any team commits engineering time to a build, three questions are worth asking out loud:

  • Have we validated the problem this idea solves?
  • Have we seen how customers respond to a solution direction — before we code?
  • Do we have alignment, or are we still reacting to noise?

If the answer is not a confident yes on all three, don't start with an MVP. Start with a Problem Framing workshop. Then run a Design Sprint. Then walk into your next stakeholder meeting knowing you have done it right.

What to do before your next stakeholder meeting

If an MVP is on the table and the symptoms above feel familiar, the next move depends on how much room you have to act.

📞 If the investment is significant and the stakes are high

Book a 30-minute call with us.. Most calls end with a clear answer on whether the next move is a Problem Framing day, a Design Sprint, both, or neither — and the language to take that answer back to your leadership group.

🧰 If you want to run the validation work in-house

Two kits cover the methods this article describes, designed for teams running them independently:

FAQs

Do I need to run a Design Sprint after Problem Framing?

No. The Problem Framing output is not always a problem to sprint on. Sometimes it is a roadmap reprioritization, sometimes targeted research, sometimes a go/no-go on whether the problem is worth solving at all.

Run a Design Sprint when the chosen problem has a genuinely unknown solution direction that needs testing with real users. Skip it when the answer is already clear. The Problem Framing vs Design Sprint diagnostic walks through the decision in more detail.

Can I skip Problem Framing if I already know the problem?

Sometimes — but the question to ask honestly is whether the leadership group shares your view of the problem. Problem Framing is not just a filter against bad ideas. It is an alignment moment that creates co-ownership of the chosen direction.

If the team will need senior sign-off later — for budget, for engineering time, for go-to-market — the upstream alignment is what makes that sign-off frictionless.

How is this different from a lean startup MVP approach?

The lean startup model assumes a small, founder-led team with direct access to customers and the ability to pivot quickly based on what they learn. That model works well for early-stage startups.

Inside large organizations, the assumptions break down — there are layers of stakeholders, internal politics, capability constraints, and the cost of a wrong direction is measured in quarters, not weeks. The pre-MVP validation move is the enterprise-calibrated version of the same principle: validate before you commit, at the altitude and pace large organizations actually operate at.

What if leadership won't fund the upstream work?

Two moves usually work. First, frame the spend against the cost of the alternative — the quarter of engineering time that would otherwise go into a build that may not survive contact with the market. A facilitated Problem Framing day and a four-day Design Sprint cost a fraction of a quarter of build.

Second, propose the smaller step first — a Problem Framing day alone is often hard to refuse, and its output frequently surfaces a disagreement the leadership group did not realize they had.

How long does the full sequence take?

From the moment a leader proposes a product idea to the moment an engineering team can begin work on an MVP brief: roughly four to six weeks.

Two to three weeks of preparation for Problem Framing — which can run in parallel with other work — one day for the Problem Framing workshop, four days for the Design Sprint, and a few days to synthesize the Replay Report into an MVP brief.