The executive team wants a feature roadmap. Detailed, sequenced, committed to dates. You want to empower your teams to discover what actually solves the problem instead of building what someone decided six months ago. The executive team wins that fight. It always does. So stop fighting it head-on. For most of us there is a third option: you change the operating model from the inside out, without permission and without getting fired.
You don't control your operating model, so stop waiting for it
If you are thinking "my CEO needs to read this," you are part of the problem. The issue is that you are looking to leadership to give you permission to work the right way, and leadership will not, not proactively. Your CEO is focused on revenue growth, not team autonomy. Your head of engineering is focused on velocity and on-time delivery. Your board is focused on roadmap execution. That is not evil, it is how incentives work. What you can control is how you work within those constraints. You cannot change the board's focus on delivery, but you can change what "delivery" means in your team. The gamble: if you make better decisions and ship better products, leadership eventually notices and lets you keep doing it.
Four moves. I keep coming back to the same four.
The first does the most work: reframe feature requests as outcomes. When leadership says "build an integration with Slack," you say "we want to reduce the time teams spend on communication handoffs, Slack is one idea, we will discover for two weeks and then build the thing that actually solves the problem." Leadership still gets a commitment. You own the approach.
Second, run discovery silently and bring evidence. Do not ask permission to do discovery, just do it. Talk to five customers, run a small experiment, come back with findings: here is what we learned, here is what the data says, here is what we are going to build instead of or on top of what was asked for. You are still following authority. You just have better information than they had.
Prototype before you ask for roadmap slots. Instead of writing a spec and waiting three weeks, spend a day on a rough prototype, test it with three customers, record their reactions. Sometimes they say this is exactly what we need and you proceed. Sometimes it misses and you iterate for a day. Sometimes they say I do not need this, and you kill it. Either way you validated or invalidated in days, not months.
And show before-and-after metrics. Track the outcome metric every feature was supposed to move, then put it on one graph. "We shipped this in February. Churn improved 12%." Numbers are objective, and leadership cannot argue with results.
How the shift compounds
You cannot shift expectations overnight, you shift them through repeated evidence. Month one you deliver on time with strong results and stakeholders think good job. Month three you deliver a feature that solved a different problem than was asked for, with better results, and when someone asks why you show the metric: it improved the outcome 3x more than the original request would have. By month six you have a pattern, and leadership starts asking why your team's stuff always works. That is the opening.
I inherited a team shipping features on a roadmap locked nine months out, on time but not moving metrics. I did silent discovery on every feature, adapted when the data said to, and tracked before-and-after obsessively. By month six, churn had improved 8% and the team shipped just as fast. I proposed committing to outcomes and discovering solutions quarterly instead of locking the roadmap. They said yes, because the evidence was overwhelming.
Two guardrails, because the whole thing rests on staying credible. Never miss a commitment. Be conservative with timelines and build in margin. And only diverge from the spec when the evidence is strong, not when you have a hunch.
So start small. Pick one upcoming feature, do the discovery before the spec locks, build from what you learned, track the outcome. Then do it again.