How roadmaps and commitments can hamper continuous improvement

As a product company, feature requests are inevitable and it can be really difficult to resist the urge to commit to requests from customers, especially if they are features you already plan on implementing, and if a new sale depends on it (or you believe it will mitigate the churn of an existing customer). As harmless as these commitments may seem, promising future features to new and existing users almost always leads to poor outcomes and a lack of control over your product strategy, because they build up over time and eliminate opportunities to adjust course.

Many product companies are burdened by a multitude of commitments that have been made to customers and other stakeholders. Some of these might be unavoidable commitments. For example, changes to upstream dependencies (like APIs) and regulations often compel product teams to prioritise work they’d rather not do. Other commitments are often made to keep a customer from churning or to win a new deal. When early-stage companies are still finding product-market fit, these commitments can be a good way to nudge the product in the right direction. As a company matures, though, these pledges compile and result in a product strategy that product teams have very little control over. In many cases, every team is simultaneously backed up with months of work that may not be the most strategically important or valuable but instead is required to satisfy the backlog of promises that have accrued over time. The result is a product strategy that delivers on commitments made to individual customers, rather than improvements for the entire target market.

Sometimes, commitments are not made because of pressure from individual customers or other external forces. In fact, many commitments are led by product teams! Typically, this is done through the roadmapping process. Teams identify opportunities to improve their products, and they commit to these improvements by adding them to their roadmap which is visible to stakeholders like customers and partners. By doing this, teams are creating an environment where the purpose of execution is to progress through a pre-defined roadmap, rather than to solve the most pressing problems at any point in time. This is the case no matter how much value is in the roadmap. Undeniably, there are benefits to having a firm plan for your product: by knowing what will come, and when, you can much more easily align other business activities with the future state of the product. These benefits, however, are negated by two critical factors. First, there is no way to know how long something will take, nor how feasible it may be. Therefore, having a roadmap does not actually bring any certainty to the question of when will an individual problem be solved, because they are full of inaccurate assumptions around scope and timeline. Secondly, deliverables on roadmaps are almost never outlined in enough detail for stakeholders to be on the same page about what is going to be delivered. Different customers, partners, and internal stakeholders are likely to have very divergent interpretations of what each feature on the roadmap truly means. This quickly leads to a constant state of overpromising and under-delivering. On the roadmap, customers see a feature they want, and they start to plan their business around this. After waiting longer than they expected, the feature is finally delivered, only to be implemented in a way that doesn’t satisfy the needs of this specific customer, in spite of being implemented in a way that is well-suited to the broader target market for the product. Disappointment inevitably ensues.

The biggest problem with committing to a prescriptive product plan, whether via a roadmap or simply through conversations with customers and prospects, is that this always leads to a suboptimal product strategy because what makes sense today might not make sense in a months time. This is because:

• Teams learn as they execute. Great product teams embrace short feedback loops, meaning they release value frequently and in small batches, and they learn from these incremental outcomes. Teams that are constantly learning are constantly becoming more capable of making great decisions because they have more information and a more thorough understanding of the needs of their target market. Learnings from recent work may adjust the parameters for what makes the most sense to tackle next, so great teams lean into this advantage by taking on as little commitment debt as possible and making decisions in a just-in-time manner.
• Circumstances inevitably change over time. By committing upfront, you’re making long-term decisions based on short-term information. Most startups operate in an environment of uncertainty. So, changes to the competitive landscape, industry regulations, and customer needs should be expected.
• Product changes beget new opportunities. Any change to your products’ capabilities also changes your options for what comes next. A common example is circumstances where you may think that by adding a certain feature, you will open yourself up to a new (or better support an existing) vertical. You might hear a lot of “customers/prospects in this segment only ever request this one simple feature, if we had it, we’d be able to say yes to a lot more deals”. This is rarely the case because the lack of certain functionality not only stops certain prospects from using your product, it also blocks a tonne of feedback that you would get from those prospects. Feature requests, when executed, often lead to additional feature requests. So, if you’re earnest about better supporting a segment of your market, you will most likely need to prioritise subsequent, unexpected work. This can be really difficult when your roadmap is mostly locked-in, potentially rendering the work you just completed mostly valueless until you find space to double down.

The best product teams I’ve worked with embrace the iterative nature of software development. Instead of committing to roadmap items, they commit to high-level, long-term goals. These goals are the focus of one or more teams for at least a year, and teams work towards these goals by tackling small chunks of work and constantly re-prioritising and re-thinking their approach. This is made dramatically easier by great DevOps practices, like automated testing, feature toggles, and highly automated releases, as this environment ensures tight feedback loops. The ability to quickly get changes out into production enables teams to quickly learn from the impact of their changes, and optimise their approach with regularity. This is a difficult approach to sell to your stakeholders, but should ultimately lead to better outcomes.