Table Of Contents
TL;DR
- Customer-driven roadmaps protect short-term revenue but fragment your product over time – and eventually kill growth, innovation, and engineering morale
- The solution is simple but hard: stay ahead of your customers so they can’t dictate your roadmap
- If only one customer needs it, it’s professional services – not product work
- Revenue concentration is a business risk, not a product strategy. Fix it through sales diversification, not feature compliance
- Engage large customers as design partners. The ask is rarely the actual need
- Set a visible ratio (e.g. 60% roadmap / 25% customer-segment / 15% tech debt) and defend it
- Make the cost of customer-specific features explicit – “2 engineers permanently” changes the conversation
- None of this works unless leadership can say no to a top-5 customer. If they can’t, start by reducing the dependency
Intro
Here’s a pattern I keep seeing in B2B companies, especially in the scaleup phase: a handful of large customers contribute a disproportionate share of revenue. And because they’re so important, they end up dictating the product roadmap.
On the surface this seems reasonable. Big customer wants feature X. Big customer pays the bills. We build feature X. Everyone’s happy.
Except nobody’s happy. Engineering is drowning in one-off features. The product team has become a project management office for customer requests. And the product itself? It’s slowly turning into 5 bespoke solutions wearing a trenchcoat.
I’ve been on both sides of this – as an interim CTO inheriting a customer-dictated roadmap, and as an advisor helping companies find their way back to a product-driven one. Here’s what I’ve learned.
The Core Tension
It really comes down to this:
- Customer-driven roadmap = short-term revenue protection, long-term product fragmentation
- Product-driven roadmap = short-term revenue risk, long-term market defensibility
Neither extreme works. But most companies I see are way too far on the customer-driven side without even realizing it. Hamilton Helmer’s 7 Powers framework is a great lens here – long-term defensibility comes from things like scale economies and cornered resources, not from building whatever your biggest customer asks for.
How to Tell You’ve Drifted Too Far
A few warning signs:
- You have features that only one customer uses, but everyone pays the complexity cost for them (more code, more tests, more edge cases)
- Engineering capacity is dominated by “customer X needs this by date Y” – there’s no room for anything else
- Your product team doesn’t act as strategists. They’re dispatchers, routing customer requests to engineering
- Your product/tech investment split looks healthy on paper (say 88/12), but if you look closely, most of the “product” work is really customer request fulfillment relabeled. A Tech Investment Framework can help you see through this
If this sounds familiar, you’re not alone. It’s incredibly common, especially when revenue is concentrated.
What Happens If You Don’t Course-Correct
This isn’t just an engineering annoyance. A customer-dictated roadmap is a slow-motion existential threat to the business.
When all your engineering capacity goes into servicing existing customers, you stop investing in the product itself. No new capabilities, no market expansion, no innovation. The product stagnates. And a stagnating product is a shrinking product – competitors who invest in real product development will eventually offer more value, even to your current customers.
It gets worse. The more customer-specific features you build, the more complex the product becomes. This is tech debt in disguise – and it compounds. Complexity slows everything down: new feature development, onboarding, bug fixing, hiring. Engineers spend their time navigating a maze of customer-specific edge cases instead of building things that matter. The best engineers leave because the work isn’t interesting anymore. The ones who stay become maintenance specialists.
Meanwhile, the company loses its mojo. There’s no vision to rally behind, no exciting roadmap to show prospects, no dream to sell. Sales cycles get longer because the product doesn’t clearly solve a problem – it solves 5 different problems for 5 different customers, and none of them particularly well.
The irony is brutal: by trying to keep every customer happy, you end up with a product that doesn’t make anyone excited. Revenue doesn’t collapse overnight. It just slowly stops growing. And by the time leadership notices, the hole is deep.
The Solution Is Simple (But Hard)
The answer to all of this is conceptually straightforward: stay ahead of your customers.
If your product is ahead of the curve – if you’re solving problems your customers don’t even know they have yet – they can’t dictate your roadmap. They’re too busy being impressed by what you shipped last quarter to send you a list of feature requests.
Think about the products you love as a customer. You don’t send them feature requests. You trust that the next release will make your life better in ways you didn’t anticipate. That trust comes from a team that deeply understands the problem space and has the freedom to explore it.
That’s the goal. Not ignoring customers – but understanding their world so well that you’re building what they need before they ask for it. Dual Track Agile is one way to structure this – a dedicated discovery track that continuously researches customer problems while delivery keeps shipping. When you’re ahead, customer conversations shift from “here’s what we need you to build” to “wow, how did you know we needed this?”
Getting there is the hard part. It requires protecting product investment even when the short-term pressure says otherwise. It requires leadership that believes in the long game. And it requires a product team that’s empowered to think, not just execute.
A Framework for Getting Back on Track
Classify every request
Before anything goes on the roadmap, ask: Is this (a) only useful to the requesting customer, (b) useful to a whole segment, or (c) useful to the broader market?
Only (b) and (c) belong on the product roadmap. Category (a) is professional services or a paid customization. That distinction alone changes the conversation dramatically.
Reframe revenue concentration
“Customer X will leave if we don’t build this” is a scary sentence. But the answer isn’t “build what they want.” The answer is “make sure no single customer has veto power over our roadmap.”
That’s a sales and GTM problem, not a product problem. Revenue concentration is a business risk that needs to be addressed through pipeline diversification, not through feature compliance.
Negotiate instead of complying
Here’s something I’ve seen work surprisingly well: large customers often accept “we’re building something better that solves your underlying problem” – if you engage them as design partners rather than treat them as order-takers.
The ask is rarely the actual need. A customer asking for a specific CSV export might really need better reporting. A customer asking for a custom workflow might really need configurable automation. Dig into the why, and you often find a solution that serves the whole market. This is essentially what Marty Cagan calls “discovering the real problem” – the difference between a feature factory and a product company.
Set a ratio and defend it
Pick a split and make it visible. Something like: 60% roadmap-driven, 25% customer-requested (but segment-relevant), 15% tech debt and platform work. (For a more detailed approach to budgeting engineering capacity, see my post on the Tech Investment Framework.)
The exact numbers matter less than the discipline. When a customer request would break the ratio, it forces a real prioritization conversation instead of silent drift. Without the ratio, drift is invisible until it’s too late.
Make the cost visible
Every customer-specific feature has ongoing costs: maintenance, testing, documentation, complexity for every other customer. If leadership sees “this feature for Customer X costs us 2 engineers permanently,” the calculus changes fast.
Most of the time, these costs are invisible. Making them explicit is often enough to shift the conversation.
The Honest Question
In my experience, the real question isn’t “should we own our roadmap?” – almost everyone agrees on that in theory.
The real question is: Does leadership have the risk tolerance to say no to a top-5 customer’s request when they threaten to leave?
If the answer is no, then the roadmap conversation is theater. The actual first step is building enough pipeline and diversification that losing one large customer isn’t fatal. And that’s a 12-18 month GTM investment, not a product decision.
The good news: once you start that investment and the dependency shrinks, the product conversations get a lot easier. And a lot more fun.
