The PM Vision

Can a Product Roadmap De-Emphasize Dates?

In a recent post, I wrote about Selling roadmap items.  To communicate “what’s coming” with Sales, Product uses an internal roadmap–and if not carefully formatted, this document may convey more certainty than is accurate.  One of the strategies I suggested is to publish a product roadmap without dates:

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”).

This week, Simon Cast of ProductTank and MindTheProduct wrote about this suggestion at length, in a post titled Roadmapping Without Dates.  In this post, Simon describes why his product management planning software, called ProdPad, omits all dates from product roadmaps.  The rationale is pretty solid and echoes the theme of the suggestion I’d posted.

Simon explains that too much granularity in the roadmap makes a document more of a project plan than a product roadmap:

The granularity turned out to make it very hard to manage. Not because of complicated UX but because, suddenly, you are managing a single idea on a day to day basis, shifting them around changing their “delivery length”. It was very Gantt-like and more about project management than product management.

He describes in a nutshell the primary problem with including dates in a roadmap, especially dates that are far out in the future:

As Martin pointed out, the point at which a specific date is added to a roadmap is the point at which everyone but the product manager believes the item in question will be delivered. Too often,it doesn’t matter how you caveat the date, it becomes gospel. Suddenly, you are judged on whether you meet the entirely fictitious dates. The judgement, unfairly, doesn’t take into account changing priorities, the cyclical nature of product management, or the fact that it is non-linear.

A better Roadmap Format

Simon shared an image of the roadmap used in ProdPad, and I like it a lot.  It resonates with a problem I’ve been wrestling with: I believe that a roadmap format which shows no difference in likelyhood of early items vs. late items is often responsible for mistrust and miscommunication between product development and sales & marketing.  Agile organizations deliver value by being able to shift priorities as more learning takes place.  Why not embrace the flexibility?

I’ve also been working on a roadmap concept, a sketch of which I’ve included below.  I have been churning over several objectives which I tried to address in this concept:

1. Certainty in the immediate term.
2. Progressively lower degree of certainty into the future
3. Phrasing to encourage discovery around problems and features imagined for later development.
4. Inclusion of proper language to be used with prospects and clients around the features.

The following sketch was developed with those objectives, and with input from a product roadmap I spotted during a tour of Daxko’s Atlanta offices and with a few words from Will Sansbury:

Some thoughts about my sketch:

• First, you’ll see that this is depicted as more of a backlog than a roadmap.  It’s easy to shift the dividers between segments up or down quite easily, which is especially useful when managing a portfolio of products and having to shift capacity across product roadmaps.
• The fact that the order is descending by priority is important.  This means that as people scan down the list, if you’ve done a good job of ordering the most important things first, many of the “most important things” will resonate highly.  If items aren’t getting traction with prospects, perhaps they should be de-prioritized.
• The answer to prospects’ questions of “When?” for items down the line should be met with discussion.  How important is it to the prospect?  This might be a great conversation for the product manager.  Perhaps it’s more important than understood.  Perhaps it’s an item that can be raised in priority should a deal be feasible.  This should be a trigger point for a conversation, NOT a question that should be dreaded or dodged.
• Items planned for the current quarter (Q) are planned, measured and sized.  This suggests confidence that what’s planned can actually be achieved.  Since priorities in the short term should NOT drastically change, language around these features can reflect certainty.
• Items in the following quarter (Q+1) are thought through to a good level of detail, but they aren’t measured or sized.  Language around these items should reflect likelyhood, with the caveat that priorities may change.
• Finally, items beyond next quarter (Q+2 and beyond) are written with less clarity, and also not sized or measured. Here the language suggests these are under consideration, and prompts the internal consumer to probe into that area with the prospect or client.  Items beyond next quarter often ARE guesses which will become more confident with more input, so it makes sense to provoke that input earlier rather than later.

What do you think?  Can this kind of tool help to get product and sales working on the same page?  What would you add or remove?

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.