When stakeholders start asking for features again, show your work

Here's a pattern I see in almost every organisation six months into a product transformation.

The team is set up properly. There's a real trio, continuous discovery is running, outcomes are assigned instead of feature lists. And then, quietly, the stakeholders revert. They start asking for specific features by name. They ask for dates. They want to know why an engineer spent Tuesday on a prototype.

Teresa Torres calls this reverting to old habits, and it isn't a sign the transformation failed. It's a sign that trust ran out before the evidence arrived.

The three things teams do that make it worse

The instinct, when your autonomy gets squeezed, is to protect it. All three of the obvious ways to do that backfire.

Refusing every feature request. "We're outcome-driven now" is a true sentence that reads as "we've stopped being useful to you." Say it enough times and someone above you concludes the new model isn't working.

Hiding the work. If the discovery happens where nobody can see it, then from the outside your team went quiet for six weeks and produced one screen. That's not a story anyone will defend for you.

Fighting for autonomy on principle. Autonomy isn't a right you win in an argument. It's the thing you get handed once people can predict your judgement. Arguing for it directly is the slowest possible route.

The move that actually works: show your work

A stakeholder asking for a feature is not attacking your process. They're managing a risk they can see and you haven't addressed. Once you read the request that way, the response is obvious. Three steps.

1. Find out what's actually being asked

Before you respond to the request, understand why it arrived. "Can we add bulk export?" usually decodes to something else: a deal at risk, a board question about churn, a competitor mentioned three times in one week, a support queue somebody is tired of reading.

That underlying concern is real and it's usually legitimate. Feature requests are a clue about the requester, not just about the product. It's the same discipline you'd apply to a customer request rather than a colleague's, and if your team already treats customer requests as clues rather than specs, this is the same muscle pointed internally.

Ask what happens if you don't build it. The answer tells you which risk you're actually managing.

2. Show how you got there, not just the conclusion

This is the step teams skip. They present the decision: we're not building bulk export, we're solving the underlying reporting problem instead. Clean, confident, and completely unpersuasive, because the stakeholder has no way to check your reasoning. All they can evaluate is whether they like the answer.

Show the path. Which customers you spoke to and what they said. Which opportunities you found and why you picked one. What you tested, what came back, what you dropped as a result. The conclusion becomes almost incidental once someone has walked the road with you.

There's a second benefit that matters more over time. A stakeholder who has seen your reasoning three times starts predicting your fourth decision correctly. That's the moment the requests stop, and it arrives through exposure, not argument.

3. Synthesise it into something readable in two minutes

Nobody outside your team will read forty pages of interview notes. Raw research isn't transparency, it's a different way of hiding. You need artifacts that compress the work without flattening it:

• Interview snapshot - one page per customer conversation. Who they were, what they were trying to do, what got in the way, the quote that made you sit up.
• Experience map - what you're learning across interviews, laid out as the customer's actual journey rather than your feature list.
• Opportunity solution tree - the outcome at the top, the opportunities under it, the solutions and tests under those. This one does the heaviest lifting, because it makes the shape of the decision visible. I've written about how to build one from an outcome down.

All three come from Teresa Torres's continuous discovery work, and all three were designed to be shared. Use them that way. A tree on a wall answers "why aren't we building the thing I asked for" faster than any meeting will.

The one thing you should still push back on

Showing your work is not the same as agreeing to everything. There's one thing worth holding the line on, and it isn't a feature.

If a stakeholder hands your team a business target and calls it an outcome, that's the moment to talk. A team can move product outcomes. It cannot move a revenue number directly, and pretending otherwise sets up a failure that gets blamed on the model. I've written about why handing a team a revenue target backfires and how to translate one into something the team can actually own.

Everything else is negotiable. Show enough of your reasoning and most of it stops being contested anyway.

Why this keeps happening

Reverting isn't a character flaw in your stakeholders. It's what happens when the visible evidence of product work drops below the visible evidence of delivery work.

Shipping is legible. Everyone can see a release. Discovery is illegible by default: it's conversations, tests, and a lot of ideas killed quietly, and killing an idea produces no artifact unless you make one. So when the pressure rises, people reach for the thing they can see.

Which means the work of staying outcome-driven is mostly communication work, and it's ongoing rather than a one-time transformation. It's the piece most teams underinvest in, and it's a large part of what we do in product advisory engagements: not teaching teams discovery, but helping them make discovery visible enough to survive.

Don't defend the process. Show the work, and let the process defend itself.