Are you selling the future?
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” or “selling ahead” 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–or those who already have them. 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.
Confusion is 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. They want to “Sell the Future.”
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.
If your company is in position that it has to sell features it doesn’t have to stay viable, you are taking a huge gamble that you’ll be able to deliver………Failure to have a strategy for dealing with estimates when they are wrong is bad management. Having a well groomed backlog, keeping teams together over time, aligning teams with business units or products, holding teams accountable for establishing a stable velocity, will all help make estimates more accurate over time. Nothing is going to help if we can’t deal with the reality of an oversubscribed product delivery team.
Once you get past the needs assessment and high level vision conversations, you’ll get down to brass tacks in the RFP and the statement of work. At this point, you need to be very clear about what the product does today, versus what you project it will do in the future.
This is critical in either of two outcomes:
- Your buyer may change his mind, identifying that required capabilities aren’t in your product. In this case, you have avoided a feeling of misrepresentation by your buyer.
- Your buyer may choose to proceed anyway, given that they don’t actually need all the “required capabilities” right away. In this case, you gain the opportunity for a healthy relationship and possible reference if your product solves the immediate problems well and you continue to improve the solution.
Thinking in terms of the Kano model, you won’t get references to help you cross the chasm if buyers discover any basic attributes aren’t met.
Approaches to resolve
A number of tactics can help to bridge this gap.
- If you’re demonstrating anything besides the product you have in production–for example, a prototype–be clear with customers before signing a contract about what is in the product now, and what is a planned future capability.
- Be clear with sales 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.