My playbook for managing up and owning the product roadmap.
No matter how good your roadmap is, executives are always going to come to you with new ideas, new priorities, and new directions for the business. That’s their job. The challenge is figuring out how to stay aligned without losing momentum on what you’ve already committed to.
The standard advice is to push back with data, learn to say “no” gracefully, and use frameworks to justify your decisions.
That advice isn’t wrong, but it doesn’t survive contact with a real CEO.
This is what I’ve actually done. Not theory. Not frameworks. Just the playbook I’ve built over years of working with founders and executives who have strong opinions about what the product should do next.
1. Own the vision, not just the roadmap.
Most stakeholders have a vision, and that vision is the reason the company exists. Their ambition and optimism are what got everyone in the room in the first place. What I’ve found is that they’re often challenged by staying focused on the path to getting there. The same qualities that make them great founders and executives, the energy, the pattern recognition, the instinct to chase opportunity, can also pull the roadmap in too many directions at once.
If you can take their vision, internalize it so deeply that you could keep building if the founder disappeared tomorrow, and then work backward from it into a concrete plan, you become the person who makes the vision real. Not the person who manages the backlog. The person who turns the abstract into the actionable.
That means understanding both sides of the equation: generating revenue and sequencing the product so each piece unlocks the next.
This is the starting point for everything else in this playbook. When the vision is shared, the roadmap feels like theirs too. It’s not your roadmap versus their ideas. It’s the collective vision versus anything that distracts from it.
2. Speak in business terms.
You’re not just building a great product. You’re building a great business. A lot of product people and designers miss that distinction, and in my experience it’s what causes most of the friction with stakeholders.
Frame everything as revenue, retention, or growth, depending on whatever metric the company is actually trying to move. This may sound obvious, but I’ve found that a lot of product people don’t do it. They talk about user experience, engagement, delight. Those things matter, but they’re often not the language executives speak.
This is often the difference between a seasoned executive and a product manager. Executives think in business outcomes. If you want to be heard in the room, you need to speak their language.
Nothing is more satisfying than when you’re the one advocating for the thing that will increase revenue while an executive is pushing for that shiny new dashboard. You know the one. Execs love their dashboards. In my experience, those are often vanity features. They can drive value, but they’re rarely the biggest drivers of conversion or revenue.
When you’re more aligned with the business than the person asking for the feature, the dynamic shifts entirely. You’re not the person saying no. You’re the person keeping everyone focused on what matters.
3. Descope, don’t decline.
When someone comes to me with a big idea, I don’t say no. I say yes, and then I give them the leanest possible version of it.
“Let’s test it.” Ship something that’s complete but minimal. Something that adds value even if it only serves a subset of users. Then measure it. Check interaction, traction, whether it moved the needle. If it’s working, great. They were right, and you keep going. If it’s not, the idea usually gets left behind on its own. You never said no. You just let reality do the talking.
Here’s a real example. Our marketing team was convinced we needed a full-blown referral program. They wrote docs, brought big ideas to the table: a third-party API for managing payouts, the whole thing. When I pushed back on the scope, they said managing payouts manually would be exhausting, that it would be a full-time job.
Fair point. So I set the bar low: let’s try to get to 10 payouts a month. Just 10. If we eclipse that, I’ll prioritize building to the API and doing it the right way. In the meantime, I hacked together a lightweight version using an existing feature, added some URL params to attribute signups, put a referral link in every user’s dashboard, and shipped it.
We launched that in February. It’s June. We’ve done literally zero payouts.
That full build could have taken up the majority of a sprint for nothing. But I never said no. I was enthusiastic the whole time. I genuinely wanted it to work, and I would have been thrilled if we were drowning in referral payouts.
But the lean test told us everything we needed to know.
This is how you should be building products anyway. Including your own ideas. And sometimes the stakeholder is right and you’re wrong. I’ve been frustrated more than once when leadership pushed to prioritize conversion or funnel improvements over product features I was excited about. In hindsight, those changes were sometimes more impactful to the business than what I wanted to build. You have to stay open to that.
When you’re scoping that lean version, bring your engineers into the conversation early. They often see ways to build something faster or simpler that you wouldn’t think of, and sometimes they’ll point out that a small tweak unlocks something bigger down the line. Leverage that.
4. Create a buffer.
Sometimes stakeholder feature requests come from chasing the next shiny object. They see a competitor launch something, read an article, or have a conversation that sparks an idea. It feels urgent in the moment.
I’ve found that fighting these ideas head-on often doesn’t work. Your job is to absorb that energy before it disrupts work in progress. Scope it out a little in product and design. Maybe spin up a quick prototype with AI. Sit down with the exec and walk through the details. Often, that’s enough for them to lose interest once they see the reality of what it takes to ship. Sometimes all you have to do is capture it and let time do its work.
If something does come back up, you’re ready. Instead of “oh, what happened with that?” you can say “it’s on the roadmap, it’s coming.” That buys you just enough time for them to either lose interest again or accept that priorities didn’t shift for their request. Either way, you didn’t blow up the plan.
This protects your roadmap because the backlog is absorbing the disruption, not the current sprint. By the time you actually reach that feature in the queue, you’ve probably already reprioritized it based on what you’ve learned. The roadmap stays intact.
And it protects your engineers. Ideally, engineering shouldn’t be context-switching on something that hasn’t been vetted. Product and design are the buffer between executive energy and engineering focus. This is half the job.
5. Single-file the roadmap.
When you’re prioritizing, force everything into a single sequence. One thing in front of the other. No swimlanes.
Swimlanes are fine for execution. You can absolutely break work into pods, teams, or parallel streams once priorities are set. But the prioritization conversation itself has to happen in a single queue with everyone at the table, including your CTO or engineering lead. They need space for technical debt and infrastructure work, and that has to compete in the same line. It goes both ways: product gives things up so engineering can build a solid foundation, and engineering gives things up so the business can move forward. That’s the only way to make tradeoffs visible.
When everything is in one line, nobody gets to say “I want that and that.” You have to pick. It’s like the kids’ game “would you rather.” You can’t have both. You have to choose the one that matters more.
This is more important than you’d think at a startup, where it’s already hard enough to stay on track. When priorities are in a single file, you actually finish things. You’re not starting too many things at once and completing none of them. You know what’s most important, and you work on it first.
It also makes it difficult to “squeeze something in.” You can’t just sneak a new request into the roadmap without visually displacing something else. I like to have the roadmap up in front of us with a calendar timeline when we’re discussing priorities, so stakeholders can see exactly what happens when priorities move around.
When you add something, everything else gets pushed out. That thing that was supposed to ship next month? It just moved to the month after. It forces real prioritization instead of the illusion of it.
6. Build in flexibility, and use it.
Let’s be honest: trying to build a roadmap that’s more than three months out at a growth-stage company is challenging. But investors and executives are going to make you do it, and it makes sense. You need to know where you’re going, even if the plan will change. Just accept that upfront.
Fires have to be put out. Partnerships come up that are too good to pass on. Features you agree mid-quarter are worth pivoting to. The roadmap is going to get wrecked. Build in the flexibility.
Here’s where it gets interesting. Given that you have to build in flexibility anyway, keep a running list of product quality and UX improvements that you know will make the product better. These are the kinds of things that are hard to justify from a pure business case but are what make a product feel great and cohesive. The things that separate a good product from one people love.
Keep them on the roadmap, and when an opening shows up, move them forward. If you only bring these to prioritization meetings to debate them against revenue features, they’ll almost always get deprioritized. They rarely get done. Instead, let them float on the roadmap and plug them in when you have capacity. You’re not hiding anything. They’re visible. You’re just not forcing a debate over something that will always lose on paper but always wins in the product.
7. Give them some wins.
I once watched a CPO slowly deteriorate his relationship with a CEO. Not because he was wrong, but because he was always right. He always had the data. He always had the rationale. He won almost every debate.
Pushing back became a reflex instead of a tool. The CEO never stopped bringing ideas. He just got increasingly frustrated and felt like he wasn’t being heard. The whole dynamic suffered, and the product team lost a partner.
Goodwill is a resource, and if you never spend it, you’re not managing up. You’re just managing the relationship into the ground. Sometimes the move is to just do the thing. Not every executive request needs to be descoped or parked on the roadmap for later. Sometimes the right call is to say “this is great, let’s do this.”
I try not to think of it as “picking my battles,” even though sometimes that’s what it is. Framing it as giving them wins changes your whole attitude. Instead of walking away thinking “fine, you win, I’ll just do it,” you walk away genuinely bought in.
That energy matters. People can feel the difference. And every win you give them is a deposit into the account that makes everything else in this playbook possible.
8. Build trust by delivering.
This is the long game, and it’s where everything else in this playbook leads.
Early on, you earn the right to push back by delivering on what you commit to and explaining your logic. You deliver what you said you’d deliver. You communicate clearly. You show that your roadmap isn’t just a wish list; it’s a plan that produces results.
Over time, the dynamic shifts. At a previous company, after a couple of years of delivering, explaining my reasoning, and getting wins, the CEO started responding to my pushback with something like, “ultimately you own the roadmap, so I trust you to make the right decision.”
That’s the endgame. Not winning debates. Not having better data. Building enough trust that the unproductive debates stop happening. You always want healthy disagreement. That’s how good products get built. But the adversarial back-and-forth, the kind where someone walks away frustrated, that goes away when the person across the table believes you’re going to make the right call.
You can’t skip to that. You earn it through the cumulative weight of everything above: owning the vision, speaking in business terms, delivering consistently, and knowing when to give them a win even when you disagree.
I didn’t include “have a well-defined prioritization process” on this list. That’s the most obvious, down-the-middle advice, and it’s not wrong. Frameworks, scoring models, intake processes: they all have a place. But those are a dime a dozen. Every PM blog covers them. And in my experience, they account for maybe 10% of what actually makes managing up work.
CEOs step around your frameworks. They’re above your processes. They’ll walk into a room and change the plan regardless of what your RICE score says. As Mike Tyson put it, “everyone has a plan until they get punched in the face.” You have to be able to improvise.
That’s the real point of this playbook. It’s not about picking one technique and running with it. It’s about having all of these in your arsenal and knowing which one to reach for based on the situation, the person, and the feature in question. Sometimes you descope. Sometimes you park it. Sometimes you just say yes and mean it.
The context matters more than the tactic, which is why managing up is so much more of a soft skill than a process. Building a great roadmap requires creativity, not just math. It’s more art than science, and that’s exactly why frameworks alone fall short. They’re too analytical, too rigid for the messy reality of building a company with real people who have real opinions.
The friction doesn’t stop because you got better at winning debates. It stops because the debates stopped being necessary.