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
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.
No related posts.
Pingback: Software Marketing Tweetables 21 January 2013 | Smart Software Marketing
Pingback: Manage customer expectations the Agile way | Agile Wisdom
Great article John. Managing the expectations of customers, managers and developers is one of the key roles of the Agile product owner.
Business people who are used to waterfall projects are used to the idea of having a plan that gives dates for when all features will be delivered – and they’re also used to the almost inevitable failure of that plan.
So techniques such as only attaching dates to roadmap items that have been estimated properly initially invite skepticism. It’s through consistent delivery on the few promises that we make that we educate our stakeholders and build their trust.
That, and the wonderful flexibility that Agile allows – “You need to respond to an unexpected business challenge with an urgent new software feature? Sure: let’s talk to our developers to see if we can put back feature X and deliver what you need in a month’s time” – give product owners credibility so that we don’t need to feel that we must make promises that we suspect we can’t live up to.
One technique I’ve found useful is to attach a ‘Needed By’ date to features – but only when they are genuinely needed by a specific date. That way, each time the product backlog is worked on, the product owner can decide whether each of those time-sensitive features need to be reprioritised. In some cases, this will mean DEprioritising a time-sensitive feature or implementing a workaround because it’s clear that higher-priority items will mean that the feature cannot be delivered when it is needed. Such small-scale feature-level ‘failures’ are actually a strength of the Agile methodology. It’s because Agile projects are able to fail at the smal level, with full visibility of the failure to all stakeholders, that they are resistant to failure at the large scale.