The Product SystemThe Vault
Product Manager Headaches: Why a Small Change Needs Product Judgement, the infographic in this PDF

Product decision-making

Product Manager Headaches: Why a Small Change Needs Product Judgement

One small change can eat a quarter. What a senior PM hears behind the request, and why the judgement that stops it is the hardest thing to prove.

Want this as a PDF?

You'll also get The Product System, my weekly note on leading product in the AI era. Unsubscribe anytime, and I'll never sell your email. How I handle your details

1

The full infographic, as a PDF

The exact one from the post, sized to print or keep within reach.

2

A copy in your inbox

The download link lands in your email too, so it's there when you need it. No follow-up campaign.

3

The Product System, weekly

My note on leading product in the AI era. One idea a week that compounds. Unsubscribe anytime.

Product managers get a different kind of headache.

Some product headaches come from deadlines. Some come from stakeholders. And some begin with one harmless sentence: "It's a small change." "Let's not overthink it." "Sales already promised it." "It should only take a sprint." "We'll validate it after launch." "The CEO saw a demo at the weekend." And the all-time classic: "AI can just do it?"

Each of these sounds like a request for a little work. Each one can turn into a lot of it. This piece looks at how that happens, what a senior PM hears behind the request, and why the skill that stops it is the hardest one to prove.

How one innocent sentence grows

The cost of a "small change" rarely shows up on day one. It shows up as a chain.

First come two "quick syncs" to work out what was meant. Then a re-prioritised roadmap, because the small thing had to go somewhere and something else had to move. Then an OKR nobody can explain, written to justify work that had already started. And at the end, a feature nobody uses, with your name on it.

None of those steps feels like a big decision when it happens. That is the trap. The real decision was made in the first sentence, and nobody stopped to price it.

What a senior PM hears behind the request

A senior PM doesn't just hear the request. They hear what sits behind it.

They hear the trade-off: the work this will push out of the way. They hear the dependency: the team, system or promise that has to move first. They hear the assumption nobody tested: the belief about customers that the whole request rests on. And they hear the quarterly business review, months from now, where someone asks why the number didn't move.

Hearing those things is not pessimism. It is the job. A request usually arrives as a solution. The product manager's work is to see what it will cost and what it is meant to change before the team spends a sprint finding out.

Questions are not a delay

So a senior PM asks questions. Not to slow things down. To stop a "small change" from eating a quarter.

The questions are plain. What problem does this solve, and for whom? What do we stop to make room for it? What has to be true for it to work? How will we know, a month after launch, whether it did? A few minutes of questions at the start costs very little. A quarter spent on the wrong thing costs a lot.

The same move sits behind pushing back on urgent work, which is covered step by step in /vault/how-to-push-back-on-urgent-requests.

The catch: nobody counts what never got built

Here's the catch. Nobody counts the features that never got built.

A shipped feature leaves a trail: a release note, a demo, a line in the quarterly review. A bad idea stopped early leaves nothing behind. The quarter it saved never appears on any slide. So the thing that makes you senior is the hardest thing to prove.

That's not overthinking. That's product judgement. When anyone can build fast, it's worth more than ever. Building got cheaper. Deciding what deserves to be built did not.

But what the org can't see, it can't value. If some of your best work is work that never happened, it helps to make it visible: what you stopped, why you stopped it, and what that freed the team to do instead. For more on deciding what stays off the roadmap, see /vault/how-to-cut-a-product-roadmap.

So here's a question worth sitting with: what's the best thing you ever killed, and what did it save?

Questions people ask

What is product judgement?
Product judgement is the ability to see what a request will really cost and change before the team builds it. It means hearing the trade-off, the dependency and the untested assumption behind a request, then deciding whether it deserves a place on the roadmap. It matters more as building gets faster, because the expensive mistake moves from building slowly to building the wrong thing.
Why do senior product managers ask so many questions?
Senior product managers ask questions to stop a small request from turning into a quarter of work. A "small change" can trigger extra meetings, a re-prioritised roadmap and a feature nobody uses. A few questions at the start, about the problem, the trade-off and how success will be measured, are far cheaper than finding the answers after launch.
How should a product manager respond to a "small change" request?
Treat it as a decision, not a task. Ask what problem it solves and for whom, what has to stop to make room, what has to be true for it to work, and how you will know whether it worked. If the answers are clear, build it. If they are not, you have found the cost before paying it.
Why is it hard to prove the value of features you stopped?
A shipped feature leaves evidence, such as a release note, a demo or a line in a review. A feature that was never built leaves nothing, so the time and money it saved stays invisible. Writing down what you stopped, why, and what it freed the team to do turns that judgement into something others can see.
Is asking questions before building just overthinking?
No. Overthinking delays a decision without improving it. Product judgement asks the few questions that change the decision: what it costs, what it displaces and what it assumes. Those questions take minutes and can save a quarter.