Roadmap

in Product Management

Selling The Future

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.

False Promises?

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.

Mike Cottmeyer points out the risk:

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.

Expectation Management

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:

  1. 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.
  2. 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.

 

JOIN OUR NEWSLETTER
Join over 80 others who are receiving tips on B2B SaaS product management & marketing, 2-3 times per month!
We hate spam. Your email address will not be sold or shared with anyone else.
Powered by Optin Forms

Write a Comment

Comment

  1. 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.