Discovery when the decision has already been made

Almost everything written about product discovery assumes a situation I rarely work in. A team with a blank roadmap, an open question, and the authority to change course when the research says so.

That’s a real situation. I’ve been in it, and the work where the evidence did change the plan is the clearest example I’ve of research genuinely changing the plan.

It isn’t the situation most product managers in large organisations are in. In enterprise the sequence usually runs the other way. Somebody committed to the thing in a planning cycle. A budget exists against a named deliverable. A partner has been selected. A date has been announced to a customer or a regulator. Then you’re hired, or assigned, and asked to deliver it.

At that point most discovery advice becomes useless, because it is all built on a veto you don’t have.

So what’s discovery actually for?

First, be honest with yourself about the constraint

The failure I see most often is a product manager running discovery as though the decision were open, finding that it is a bad idea, presenting that finding, and being overruled. Then spending the rest of the project as the person who said it wouldn’t work.

That helps nobody. It burns the credibility you’ll need for the decisions that genuinely are open, and it doesn’t save the project.

The opposite failure is treating a committed decision as a reason to skip discovery entirely. If it’s decided, why research it. That one ends with a thing that was delivered on time and nobody uses.

Between those there’s a narrow, useful position, and it starts by naming what is actually fixed. Usually less than people assume. The what is fixed. The scope, the sequence, the rollout, the definition of done and the success criteria are often wide open, and nobody has thought about them because all the attention went to the commitment.

Those are your levers. They aren’t small.

What discovery is still for

Finding the version that works. The commitment is usually a noun. Build the portal, ship the assistant, migrate the platform. Nobody at the committing level specified which workflow it enters, what it replaces, or what happens on the days it’s wrong. That is where success is actually determined, and it is entirely yours.

Finding what it breaks. Large organisations have dependencies nobody has drawn. Research that surfaces the three teams whose work changes when this ships beats research that questions the premise, because it prevents a specific failure that would otherwise arrive in week ten.

Finding the baseline. If you measure how the work performs today before anything changes, you’ve created the only thing that will let anyone evaluate the outcome honestly. This is also what makes the next decision arguable with evidence instead of opinion. I’ve written about why this matters in sizing an AI feature, and it applies to any committed project.

Finding the earliest honest checkpoint. You can’t cancel it. You can often propose a point at which everyone looks at real evidence together. Framed as de-risking a commitment rather than reopening it, this is usually accepted. It is the closest thing to a veto available, and it works because it isn’t one.

How to ask when you can’t say no

The framing that has worked for me is to stop asking whether and start asking which.

Not should we build this, but which version of this survives contact with the people who have to use it. Nobody is threatened by the second question, and it gets you into the same rooms with the same users.

One more thing that helps, and it’s borrowed. Teresa Torres, in Continuous Discovery Habits, argues that you break an idea into its underlying assumptions and test the riskiest ones first, cheaply, before building the full solution. Her framework assumes a team that can act on the answer, which is exactly the assumption I’m setting aside here. The assumption mapping still works when you can’t.

So write down the assumptions the commitment rests on, as plainly as you can, and circulate them as a list rather than a challenge. Something like: this works if the operations team has capacity in Q3, and if the data in the legacy system is complete enough, and if users will adopt without a training programme.

You aren’t arguing. You’re stating the conditions under which the plan is true. Three things tend to happen. Somebody tells you one of them is already false, which is the cheapest finding you’ll ever get. Somebody takes ownership of one. Or the list is agreed, which means when one of them breaks later the conversation is about the assumption rather than about you.

What still applies from the standard playbook

Not all of it survives the constraint, but more than you’d think.

The weekly cadence does. Torres’s benchmark is that the product trio — product manager, designer, engineer — talks to at least one customer a week, treating discovery as a rhythm rather than a phase. Nothing about a committed roadmap prevents that, and it’s the single habit that most reliably keeps a team’s picture of reality current.

The opportunity solution tree mostly doesn’t, at least not at the top. It starts from a desired outcome and maps the opportunity space beneath it, and when the solution is already fixed you’re working bottom-up rather than top-down. What survives is the lower half: given this solution, which opportunities does it actually address? And what is it resting on?

Outcomes over outputs survives, and it’s the most useful thing you can import. If the commitment is an output — ship the portal — then naming the outcome it’s supposed to produce is both legitimate and clarifying. Nobody will stop you asking what this is meant to achieve, and the answer is often vaguer than the deliverable, which is where your scope decisions come from.

When to escalate anyway

I’m not arguing for going quietly. There’s a line, and I want to be clear about where it sits.

Scope, sequence and definition of done are yours to shape. Say your piece once on the premise, in writing, then commit and make it work.

But if discovery surfaces something that makes the plan unsafe rather than merely suboptimal — a regulatory exposure, a security hole, harm to users, a legal obligation nobody has noticed — that’s a different category and it escalates regardless of how committed the decision is. A committed roadmap isn’t a reason to let something dangerous ship. The distinction is between a plan you disagree with and a plan that shouldn’t proceed, and conflating the two is how people lose the standing to raise the second.

The part that took me longest to learn

I used to think discovery that didn’t change the decision was wasted work.

What changed my mind is watching the same committed project go two ways depending on whether anyone had done this work. The version with no discovery ships on time and quietly fails, and nobody can say why because there was never a baseline. The version with discovery ships roughly on time in a shape nobody originally specified, into a workflow somebody checked, with a number attached.

Same commitment. Same constraint. Different outcome. The research did not change what was built. It changed whether it worked.

Common questions

What is the point of discovery if the decision is already made?

The commitment usually fixes what gets built and leaves scope, sequence, rollout, definition of done and success criteria open. Those determine whether the thing works in practice, and they are typically unexamined because attention went to the commitment itself. Discovery also establishes the baseline that makes the outcome measurable afterwards.

How do you run discovery without the authority to cancel a project?

Stop asking whether it should be built and start asking which version survives contact with the people who have to use it. That question reaches the same users and the same evidence without threatening a decision that has already been made.

What should you do when research shows a committed project is a bad idea?

Say it once, in writing, then commit and shape the version most likely to work. Presenting a finding you have no authority to act on, repeatedly, spends credibility you will need for the decisions that are genuinely open. The exception is anything unsafe rather than merely suboptimal, which escalates regardless.

How do you surface risky assumptions without appearing obstructive?

Write the assumptions the plan depends on as a plain list and circulate it as a statement of conditions rather than a challenge. Someone often reveals one is already false, someone may take ownership of another, and if the list is agreed then a later failure becomes a conversation about the assumption rather than about you.

Why does a baseline matter on a project you did not choose?

Without a measurement of how the work performs today, nobody can evaluate the outcome honestly, and the next decision gets made on opinion. Recording the baseline is the one piece of discovery that retains its value even if everything else about the plan is fixed.

Does continuous discovery work in a large organisation?

Parts of it do. The weekly interview cadence Teresa Torres recommends for the product trio works regardless of how committed the roadmap is, and assumption testing survives intact. The opportunity solution tree works less well from the top down when the solution is already fixed, though the lower half — which opportunities does this actually address, and what's it resting on — still applies.

How do you push back on a decision as a product manager?

Once, in writing, then commit. Repeating a finding you have no authority to act on spends credibility you'll need for decisions that are genuinely open. The exception is anything unsafe rather than merely suboptimal, which escalates however committed the plan is.

What is assumption mapping and why use it on a committed project?

Writing out the conditions a plan depends on as a plain list, then circulating it as a statement of conditions rather than an objection. Someone often reveals one is already false, which is the cheapest research finding available, and if the list is agreed then a later failure is discussed as an assumption rather than as your judgement.