Product Roadmap Detours

Roadmap Detours

Diverting from your roadmap is tough, but can have significant benefits – when should you allow it?

You’re in final negotiations for a contract that will be 20% more than your largest existing customer – if you just build a new feature that they want.

An important customer is threatening to leave you for the competition if you don’t add a key regulatory need slated for a future quarter.

A critical partner will feature you at their annual conference in 3 weeks, but they need you to build out a new integration into their platform.

What do you do?

Handling The dreaded detour

Roadmap diversions are a universal stressor for enterprise SaaS businesses. When I was younger and more innocent, I thought that having your roadmap altered by a larger, demanding client was something that you grew out of, like getting beat up on the playground. It unfortunately isn’t. Bigger companies just have bigger problems – instead of building a one-off to close your first $50k customer, you’ll find yourself building a custom integration with a 100,000 person mega-corporation.

Custom features generally suck. They distract from your carefully planned product roadmap, typically add unwanted complexity to your product, and set a bad precedent. However, all but the most obscenely successful companies will occasionally need to choose between the sweet, immediate relief of building a one-off feature and the blissful purity of leaving their product roadmap intact. I’ve never spoken to an enterprise software company that didn’t have to build at least a few one-offs along the way: everyone does it, but nobody talks about it.

When to break your roadmap

Overall, there isn’t a one-size-fits-all formula on when to break your roadmap. Do this all the time and you’ll become a custom development shop, limping along with an incoherent product that resembles Frankenstein’s monster. The default response to any sort of customer one-off should be “no.”

However, if you never break your roadmap, you are probably leaving opportunities for significant leverage on the table. Some enterprise customers actually will require you to build new functionality for them, and they can add huge momentum to your business in the form of reputational benefits or cold hard cash.

Considerations for breaking your roadmap

While there are no universal right answers on when to break your roadmap, the following factors can help you determine whether a one-off is worthwhile.

Roadmap Detour Equation

What is the business value we’ll gain?

It’s important to look at both the immediate value you’ll gain from building a one-off feature (e.g. a $1M contract will close tomorrow), as well as the long-term benefits (e.g. a custom feature is necessary to retain a Fortune 100 customer where we can dramatically expand). Additionally, arbitrary metrics such as hitting quarterly numbers can be critical for closing a new round of funding, demonstrating steady growth, or even meeting payroll.

As a very general rule of thumb, we recommend that any one-off that takes your team more than 1-2 days of work should have enough upside that it will potentially be one of your biggest wins of the quarter if all goes well.

What is the opportunity cost?

All one-offs are tradeoffs. In most cases, your product roadmap should be more important than any special request that arises (you planned out your roadmap carefully, didn’t you?). Constantly distracting from your roadmap will rapidly cause you to lose forward momentum on your overall goals.

What are the odds that the one-off actually works?

Welcome to enterprise sales!

Enterprise software buyers can sometimes behave irrationally

Enterprise customers ask for things all the time, but only some of them matter. It’s sadly common for a customer to demand a “critical” feature that they never end up using – like a puppy or a small child, complex enterprise buyers can be demanding without rationality. As a result, you should look for signs that an ask is earnest:

  • Feature requests should be consistent over time – the scope shouldn’t fluctuate much.
  • Your customer should be able to articulate the why behind their requests with clear business use-cases (note: “‘Other Vendor’ does this” is not a use-case).
  • Features which bring your product inline with compliance and regulatory needs are generally more likely to be sincere. These requests often indicate objective requirements, and will open doors to other similar customers in turn.

Is the one-off aligned with your vision?

Is this something that you would envision having in the product in 5 years? When you think about the overall story that your product is telling – is this feature part of the narrative?

It’s significantly better to shift a future roadmap item forward than to build a feature that would never otherwise see the light of day. Special requests that are vision-aligned will often pull your roadmap in valuable directions – if your largest customer has a very specific demand, it’s likely that they’re pulling you into an even juicier market.

What is the supportability burden?

It’s hard to support complex products. One-off features that are not vision-aligned add tech and UX debt that is extremely hard to get rid of. Many one-off features are simply not worthwhile due to the supportability drag that they incur, and will punish you as years go by.

How is your team’s morale?

Breaking your roadmap will negatively impact the morale of your product & engineering team. There is no way around this. Builders want to build; they don’t want to patch holes, and they definitely don’t want to patch holes because some asshole at FacelessCorp, LLC demanded it – and that’s how these one-offs will be perceived. Make sure that your team can weather the fatigue that a shifting roadmap will cause.

How to break your roadmap

So you’ve decided that it’s worth it – the call of those sweet dollar bills is too loud and you’re going to build a customer one-off. How do you do it right?

First, you need to scope the work well. Get direct client confirmation, in writing, of what you’re going to build and what you’ll gain in return. You also need to set customer and internal expectations well: when a solution will be delivered, and how. And finally, once work begins you should be as efficient as possible in order to limit the scope of the supportability damage and distraction. Similar to fighting a forest fire, you should isolate the functionality you’re building if it’s bespoke to a single client.

Team impacts

Both you and your sales team are drawing from a pool of goodwill every time you break your roadmap. The immediate effect of overdrawing this balance is grumbling, and the long-term effect will be attrition, often of your best people.

You can counter this with a few strategies. First, avoid inundating any parts of your organization with special requests. If one team does nothing but build one-offs they’ll rightly recognize that they aren’t advancing their careers and will burn out.

You should also keep your team aligned on the business goals that they are contributing to. Everyone, especially engineers, should understand how their efforts map to business objectives such as revenue, profits, retention, and account expansion. Reinforce this by thanking the team and showing them evidence of the positive results afterwards – and also owning your mistakes if you make the wrong decision.

Beware of idealogues. It’s very easy to craft a logical argument as to why you should never break your roadmap, and this can become a point of almost religious contention on your team. Ultimately you’re building a product to make money, not run a charity, and sometimes business realities force your hand.

Building one-offs also sets a dangerous precedent to your go to market team. A custom feature concession for a client is giving the greediest mouse – your sales team – a bite of the fattest, tastiest cookie they’ve ever had. Sales teams love being able to deliver one-off functionality, as it solves their buyer’s needs while demonstrating that they can expect white glove treatment (which customers fucking love). Custom work sends a dangerous message.

Oh shit!

Your product roadmap and a monster customer opportunity are both on the table. Which do you pick?

Your team ultimately has a budget that can be spent on one-off features. As a result, you need to make sure that you are pushing back against bad requests. You need to be on the same page with sales leadership about which accounts matter and which do not, and it should not be easy for sales teams to get one-offs pushed through. We recommend that all major roadmap concessions run through the head of product and head of sales as the keepers of this budget for special product efforts.

One-offs as you scale

While the demand for special features never fully disappears, the opportunities and your approach should scale over time. One strategy that we’ve used is to have a threshold for which types of circumstances merit discussion as a potential one-off. For example, only revenue opportunities that would represent at least 5% of your current revenue will even be considered.

You should also track the one-offs that you’ve built and use the clarity of hindsight to decide whether they were good ideas. That way, you can calibrate the impact of building special requests and your threshold for tackling them.


  • Enterprise SaaS businesses should expect regular pressure to change their roadmaps in order to facilitate short-term goals.
  • You should generally try to avoid breaking your roadmap, but one-off features can sometimes deliver significant business value. The optimal path lies somewhere in the middle.
  • If you must build a one-off feature, steer towards enhancements that both deliver significant business value and align with your product vision – especially features which you would have otherwise built eventually.
  • Changing your roadmap carries costs in terms of time, product quality, and morale, and you need to clinically evaluate and manage the downsides.
  • As your business scales, the benefits of breaking your roadmap should scale as well.