Are you selling roadmap items?
One of the problems B2B software companies struggle with is the proper application of a product roadmap. Sales teams want to know what’s coming up in future releases, so they can appeal to customer problems the product will solve in future releases. This form of “selling the future” carries the risk of enticing the customer with a feature that never arrives, or arrives later than expected. Both of these negative outcomes can naturally cause problems for the company after the deal is signed.
Some teams sell only features in (and appeal to problems solved by) the current version. This mitigates the risk of false promises, but puts the company at a disadvantage to competitors who have (or are willing to talk about) more features. Once a product attracts competition, and in particular once the market is mature enough that companies submit detailed RFPs, it becomes more and more difficult to sell only what’s currently available.
False promises are common. Product management presents a roadmap showing features along an estimated timeline, but this looks suspiciously like a schedule of commitments without proper context. And any account manager who shows the roadmap in document format is at risk of presenting it without context.
In agile software organizations, a significant dichotomy exists. On one hand, agility supports the ability to respond to opportunity. Responding to opportunity frequently results in re-prioritizing the roadmap, which by definition delays whatever was previously in that item’s place in line. On the other hand, many sales organizations want as much of a committed feature schedule as possible, so they can sell deals that include language that delivers revenue at the time of feature delivery. Why not wait until the features come out? One of the primary reasons is that this locks the customer in to a solution now, which establishes switching costs should the customer consider moving elsewhere later. For recurring revenue products like SaaS software, this is a significant aid in locking down future revenue.
Approaches to resolve
A number of tactics can help to bridge this gap.
- Be clear about what is committed by engineering, and what is simply estimates. This will help sales to avoid mistakenly committing to something that isn’t a sure thing.
- Clearly communicate that items promised in error will not influence the roadmap. Once it’s clear that false promises will be problems for the salesperson, fewer of them will be made.
- Include clear language on roadmap documents that indicate features are subject to change or total omission. Here’s language from one company’s roadmap:
And what are those caveats? As is usual I have to sound my standard note of caution. These plans are our best estimate at this point in time for what we should be able to do in 2011, given our resources and our understanding of the technology landscape in which we operate. Any dates given are estimates. Any functionality we describe in this roadmap, especially the further out it is, may be postponed or cancelled altogether. We strongly advise our customers not to make firm plans based on what they see here: in an industry such as ours, things can change very quickly and we have to react just as rapidly to new opportunities that may present themselves.
- A subtle cultural tactic is to be cautious about when it’s appropriate to use the word “slipped.” The word “slip” assumes something is later than planned, which implies it was planned for a certain date. If you’re in an agile shop and your engineers have done T-shirt sizing of a rough story idea without detailed analysis, they may have projected a rough completion date. But in that case, assuming they haven’t “planned” or estimated that work in detail yet, it’s not “Scheduled” In that case, it is best to use some other term that doesn’t suggest “schedule slip,” so you don’t imply an engineering shortfall.
- A tactic I’ve seen some agile shops apply is to omit all dates from roadmaps. Instead of a roadmap, they show a prioritized high level feature backlog, which includes more detail for immediate features and less detail for more distant future features. Some may even include dates on the top item or two which may be at a detailed level of planning. This eases the conversations around items beyond the short term (about which there are the fewest “unknowns”).
What other tactics and techniques do you use to manage the conflict over selling roadmap items?
Image from Stock Xchng.