The Power of No: Cutting Scope and the Two-Roadmap Trick

Why your real roadmap should probably be smaller than the one you show your stakeholders.

A hard truth for any new PM: most of your roadmap problems aren't prioritization problems. They're scope problems. You don't have too many priorities — you have one priority with too much in it, plus six "priorities" that shouldn't be priorities at all.

At a big, process-heavy company, this is especially brutal. Every feature accumulates requests from stakeholders you can't ignore: compliance needs a field added, legal wants a disclaimer, risk wants an audit trail, marketing wants a banner, an exec wants an AI tie-in. The original scope of "let customers update their mailing address in two clicks" is now a six-month program. And you, the PM, are the person who gets to explain why it's taking so long.

The fix isn't more prioritization frameworks. The fix is learning to cut.

The two-roadmap idea

Two of the most interesting CEO conversations in Lenny's recent archive — Gaurav Misra of Captions and Varun Mohan of Windsurf — converge on the same idea: you should run two roadmaps, not one.

Gaurav Misra described it first:

We have what we think of as the public roadmap. This is basically what people have asked us for. There's all these surface areas where we receive user feedback, but these are all features that every competitor knows about. If a user is asking us for it, they're asking everybody for it. It's not going to be a game changer in terms of winning against your competition. So we have a second roadmap which we think of as a secret roadmap.

The public roadmap is the stuff people expect you to build — the table stakes, the competitive parity, the things customers have literally written in to request. You build that roadmap because it keeps you in the game.

The secret roadmap is the set of bets on where the world is going. It's not driven by user requests (because by definition, users can't ask for things they haven't imagined). It's driven by your team's point of view on the future. That's what actually wins.

Varun Mohan, on a later podcast, explicitly riffed on this: "We had Gaurav from Captions on the podcast and he told us that he has two roadmaps. They have the real roadmap, like the typical roadmap based on feature requests and user feedback and data and things like that. And then they have the secret roadmap, which is completely not informed by users or data — it's just them making bets on where they think the world is going."

Why this matters at a big company (even if you're not a startup)

You might be reading this and thinking: "I work at an insurance company. I don't have a secret roadmap. My roadmap is whatever came out of the PI planning session."

Fair. But the underlying insight still applies, and it's this: not every item on your roadmap is doing the same job. Some items are there because customers asked. Some are there because you think they'll matter in 18 months but nobody's asked for them yet. Some are there because of compliance. Some are there because your boss's boss saw a demo at a conference.

If you treat these all as one undifferentiated list, you'll optimize them as one undifferentiated list — and the forward-looking bets (the secret roadmap) will always lose to the immediate asks (the public roadmap). That's how big companies end up only shipping incremental improvements while a scrappier competitor eats their lunch.

The fix is to name the categories. Be explicit, at least internally, about which items are "reactive" (responding to requests), which are "strategic bets" (forward-looking), and which are "table stakes" (compliance, performance, tech debt). Protect a defined percentage of capacity for strategic bets. Otherwise that capacity gets eaten, every quarter, by the loudest voice in the room.

Ruthlessly cut scope, not just the roadmap

The second half of this equation is scope within a single initiative. Here the model is also Gaurav Misra, whose Captions team ships a feature every week. His core move: technical debt isn't a dirty word — it's a speed choice. "I actually think as a startup your job is to take on technical debt because that is how you operate faster than a bigger company. Bigger companies don't take technical debt, they pay it usually right away, or they're paying back technical debt from the days when they were a startup."

You're not a startup. But the scope-cutting discipline transfers. Every feature in your backlog has a v1 that could ship in two weeks, a v2 that ships in three months, and a v5 that's in the deck someone showed a VP last year. The failure mode is merging those into a single plan and then shipping v5 "in Q3." The fix is committing to v1, learning, and deciding whether v2 is still the right call.

Matt LeMay has a version of this framed as a question he calls the career-saver: "What is the smallest thing we could build that would teach us whether this is worth doing?" That's the scope-cutting question. It's not "what's the MVP" (which has become a euphemism for "the full thing minus some polish"). It's literally: what's the smallest experiment that resolves our biggest uncertainty?

If you can answer that in one sentence, you've cut your scope correctly. If you can't, you're still building v5.

How to actually say no in a big-company context

Saying no at a startup is easy: "We don't have bandwidth." Saying no at a big company is hard, because someone will always tell you that you should have bandwidth — after all, there are 800 people in the technology org.

Some language and tactics that work, based on the patterns in these conversations:

• "Which of our current priorities should move to make room for this?" This is the magic question. It reframes "will you do this extra thing" into "will you explicitly trade off." Stakeholders who are fine with extra work are often not fine with killing something else.
• "Can I get back to you with the ROI estimate by Friday?" Buys you time to actually RICE-score it. Often the idea dies on its own before Friday.
• "This is a great candidate for Later — let me add it to the backlog with the criteria we'd need to see to move it into Next." This is a genuine yes-with-a-catch. The idea lives, but only if evidence shows up.
• "I can build v1 in two weeks. v5 is a separate project." Give them a concrete, small, shippable version. Most stakeholders actually wanted v1 — they just didn't know they were allowed to ask for it.
• "Here's the public roadmap this item lives on. Here's the strategic-bets roadmap it doesn't belong on." (Internal framing, not a phrase to use out loud.) Helps you keep strategic capacity protected.

The point

The power of no isn't about being obstructive. It's about being clear. Most PMs, especially newer ones, lose their roadmaps by saying yes too quickly to everything that feels reasonable. Every reasonable yes, added up, is an unreasonable roadmap.

Two-roadmap thinking (real vs. secret) gives you a lens for what your team is actually building. Ruthless scope-cutting within each initiative gives you the speed to ship and learn. And the small vocabulary above gives you the phrases to push back without sounding obstructionist.

Shipping a smaller, clearer roadmap well is almost always the right trade against shipping a bigger, blurrier one poorly. Your exec sponsors won't remember the features you said no to. They'll remember what you shipped.

← Back to Roadmapping