How a Product Roadmap Survives Your Biggest Customer

You wrote the sentence: we do not build custom integrations for enterprise warehouse systems. It took you an afternoon, and when you finished you felt good, because it was the hardest line on the page and you'd written it down.

Three weeks later there's an email from your biggest customer. They want a custom integration into their warehouse system, and near the bottom they mention that their renewal is coming up. And you notice you're already looking for the reason this one is different. The reason might even be there, but you started looking for it before you'd decided anything.

The advice that stops at the build

There's no shortage of help with roadmaps. Search for how to build one and you'll find the same video about 20 times: gather your inputs, group them into themes, put the themes in an order, publish the result where people can see it. A roadmap is a statement of intent, it should be organized around outcomes, and different people in the building need different views of it.

I went through the 12 strongest of those videos, the ones the algorithm rewards. Every one of them teaches you how to build a roadmap, and none covers what to do when somebody attacks it. That attack is the moment you're in, with the email open, and it's the first real test the roadmap gets.

Score the email

When you go looking for a way to decide, the field hands you a scoring framework. The most popular by a distance is RICE. In the sweep I ran, a four-minute explainer of it was the biggest outlier in the whole set, running about 5,000 times its own channel's normal. A company that sells a prioritization tool made it, and half of those 12 videos came from companies selling the software.

RICE has four terms. Reach is how many customers a piece of work touches in a given period. Impact is how much it matters to them, on whatever scale you choose. Effort is the work. You multiply reach, impact and confidence, then divide by effort. Three of the four are estimates about the work. The fourth, confidence, is an estimate about you: how good your evidence is. That video puts high confidence at 100%, medium at 80% and low at 50%, and calls anything below 50% a shot in the dark.

Now score the email. Reach: it's one customer, but it's your biggest, with more seats than anybody else on your list. Impact: their renewal is sitting in the same email, on the largest account you've got. Effort: your team built one of these in year two and another in year three, so they know how, and because effort is the denominator, a low number there pushes the score up. Confidence: your biggest customer has written down exactly what they want and put their renewal next to it. That's the best evidence a 40-person company will see all year, so confidence goes to 100%.

The request lands at the top, and it lands there because you filled the framework in honestly. Nothing about the framework is broken.

The bet can't score

Now score the thing your strategy is built on. Your insight was that a 20-vehicle operator has no IT department, so what wins with them is a product that works on the first day with no project attached. Reach is hard to say. Impact, you believe, is everything, but belief isn't a number. Effort is large. And confidence is where it falls apart, because you can't prove the insight. In part five I described Roger Martin's tell, that a real strategy makes you anxious because you can't prove in advance that it will work. Put that anxiety through the formula and it reads as low confidence: 50%, which by the framework's own description is a shot in the dark.

So the same term that rewards the email punishes the strategy, and it punishes it for being a strategy. None of the 12 videos says so. Check it yourself against the formula their makers publish; it's arithmetic.

The other framework you'll meet is MoSCoW: must have, should have, could have, won't have. That last bucket looks exactly like what we're after, a real won't. But the W is scoped to the release you happen to be planning, so it means you won't have it this time, and some versions of the method spell the W as wish. Neither framework has anywhere to put a permanent no.

What the frameworks decide

The frameworks end up deciding which problems we solve, and for whom, and they decide it by whichever customer escalated most recently, one defensible yes at a time. Scoring is the machine that sets it. Every yes it produces is a request with a name and a number on it, weighed against a bet nobody could evidence. A roadmap that's a ranked list of requests is your inbox with better formatting.

You weren't wrong to build one. Ordering requests is a real job, and somebody has to do it. The trouble is that a list has no way to refuse anything, so the only question it can answer is which yes comes first.

A roadmap that promises outcomes

For a roadmap to survive an email like that one, it has to promise something a request can't outrank. So it promises outcomes you owe, and it stops naming the features you'll ship. Meridian, the composite company I've carried through this series, writes its second quarter like this: by the end of it, a new customer with no IT department is running on their own inside a day. Meridian can be held to that promise, and it's a promise about the customer Meridian chose. Because it names no feature, no request for a better one can outrank it.

The outcome promise also changes what the email is. The email asks whether you'll build a thing, and a roadmap written that way answers a different question: whether the work gets a warehouse customer with no IT department running inside a day. The request fails that test. It's a six-week implementation for a company with a whole IT department, so by the time the email arrived, the roadmap had already decided it.

The customer still needs an answer

A decision on paper doesn't answer the customer, who still needs to hear something on the call. The most useful thing I found on this came from Marty Cagan. He says stakeholders who want a roadmap aren't crazy: they have dependencies and partners, and sales has to tell customers something. His objection is to dates with nothing behind them. By his account, most roadmaps fail if you judge them on whether their dates turn out right, and the people giving those dates don't know what they're talking about.

His alternative is what he calls a high-integrity commitment: you give a date only once you understand what the customer needs and you know what delivering it takes. He tells engineers never to put a date on a roadmap until somebody has built a feasibility prototype, because otherwise the reputation and the business are riding on a guess. Cagan also sells transformation services for a living, which I'll keep saying every time I cite him. Nothing I found measures whether any of this works better.

At 40 people you don't have an engineer to spare for prototyping every request that arrives, so the part of his rule you can run at your size is the half that costs nothing: never accept proxies. A salesperson's account of what the customer needs is a proxy, and so is the customer's own summary. Somebody from your side sits with them and finds out what they're trying to do, and at your size that somebody is probably you, on one phone call or over a coffee. The call is worth making even when the answer is going to be no. The customer asked for a custom integration into their warehouse system. What they might need is for their data to arrive somewhere once a day without anybody retyping it. One of those is already on your roadmap. The other is a business you said you're not in.

Who gets to say no

Somebody has to decide, and the hard case is when that somebody isn't you. The decline you wrote in part five needs protecting, because a decline can be undone without anyone ever overruling it. A head of product says no, and by Thursday it's back on the roadmap because the founder said yes to an account executive in a hallway.

So write an escalation rule at the same time as the decline, before a request like this one gives everybody a stake in the answer. Mine is three lines:

1. 1. Who can say no on their own.
2. 2. What size of exception has to come to the founder.
3. 3. What has to be true for the answer to change.

The third line does the work. If the answer is a number, write the number. If it's evidence, say what evidence. If nothing could change it, say that. Meridian's version reads: any single customer request, the head of product decides; anything that needs a new kind of engineering commitment goes to the founder; and the decline changes only if three customers in the chosen focus ask for the same thing. That last line is what lets the strategy learn something without simply folding.

The first two lines set how much reaches the founder. Every founder is a bottleneck in something, and at 40 people that's the correct place to be. The bottlenecks that hurt are the escalations your team could handle and you keep anyway, because of who you think you are.

What you say on the call

The customer is on the line, their renewal is on the table, and they want an answer. Leave your strategy document closed. Tell them what you're for, and then tell them the truth about what the thing they asked for would cost:

We build for operators who need to be running on their own inside a day, without an IT project. That's the whole company, and it's why we're fast for you in the places we're fast. Building your integration would put more of our engineering on one account, the way two of our six engineers already spend most of their week on three accounts. I'm not going to say yes to that on a call, and I'm not going to say no to it either. What I'll tell you is what would change our answer. If the operators we're built for need this too, we'll build it properly, for all of them. Give me time to find out whether you're the only one.

Said that way, the renewal hangs on something you can both go and check.

When the answer should be yes

Sometimes the answer is yes. A strategy is a bet, and bets get updated. If this is the third warehouse operator in your focus asking for the same thing, the market is telling you your insight was incomplete. The test is where the yes came from: the rule you wrote, or whoever happened to be loudest that week.

There's a failure in the other direction too, and everything so far has argued for no. A decline is supposed to buy you something. You turn the integration down so that the thing you're for gets better, and gets better faster. If you turned it down and nothing got faster, all you did was say no and file it under focus. So I ask two things about my own page: what did this cost me, and what did I buy with it?

What I can't tell you

I can't tell you that any of this makes you more money. There's no study comparing companies with written escalation rules against companies without them. I looked. What exists instead is people describing what worked for them, and the ones I read were selling the describing.

What I'll stand behind is smaller: when a decline is written down, people can point at it, and when it lives only in your head, it gets relitigated every time it comes up and you lose a little of it each round.

Meridian's answer

The request went to Meridian's head of product, because a single customer request is hers to decide, and she picked up the phone herself. The customer wanted the integration because their operations team was retyping numbers from one screen into another every morning, about 40 minutes a day.

That changed the question. A custom integration into one warehouse system is a business Meridian said it isn't in. Getting data out once a day without anybody retyping it might be something every operator in the focus needs. So she used the rule: the integration stays declined, and the only thing that changes the decline is three customers in the focus needing the same thing. That was the question she took off the call. The renewal is still open, and Meridian now has a question it can go and answer.

One line, this week

Take the decline you wrote and add one line underneath it naming who can say no without asking you. If you can't answer that in one sentence, the decline isn't finished.

Dave Saunders is the founder of Base Reality Group and a Fractional CPO for product companies. He was a founder and operator at Galen Robotics, where the surgical-robotics platform earned FDA De Novo authorization in 2023, and he managed a 35-patent portfolio licensed from Johns Hopkins. He wrote Founders Who Finish and publishes The Build. More about Dave →