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:

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.

Privacy and terms

I care about privacy as much as you do. I will only use your email address to send you this newsletter or to reach out to you directly, and you can unsubscribe at any time. I will not share, sell, or rent your email address to any third party, though I do store it the software I use to dispatch emails.

The information provided on this blog is for informational purposes only and should not be considered investment advice. The content on this blog is not a substitute for professional financial advice. The views and opinions expressed on this blog are solely those of the author and do not necessarily reflect the views of other organizations. The author makes no representations as to the accuracy, completeness, currentness, suitability, or validity of any information on this blog and will not be liable for any errors, omissions, or delays in this information or any losses, injuries, or damages arising from its use. The author may hold positions in the companies or products discussed on this blog. Always conduct your own research and consult a financial advisor before making any investment decisions.

Subscribe for advice

Free weekly advice covering product strategy, development operations, building teams and more.

More advice

Australia to quash angel investing

The Australian Government is about to make it nearly impossible for successful startup workers to reinvest their earnings into new startups. Let’s explore the upcoming changes and how they will affect startups, workers, and the Australian economy.

Stepping on toes

How much should competent people, confidently managing their responsibilities, meddle in the affairs of other teams they perceive to be dropping the ball?

Processes make inexperienced people wiser, and experienced people dumber

People hate process, but process is crucial to scaling a businesses. Today, we explore the difference between good and bad processes, and ways to ensure startups can benefit from standardisation, rather than suffer.