Quantcast

Bruce McCarthy is Founder and Chief Product Person at UpUp Labs, where he and his team are at work on Reqqs - the smart roadmap tool for product people.

Need Product Advice? Pick a time to chat.

« Reqqs Appears in Product Management Journal | Main | Court Scribe or Hand of the King? »
Sunday
Oct062013

Roadmaps Focus on Vision & Benefits -- Not Features

This is the third article in a series called The Dirty Dozen Roadmap Roadblocks. In the first entry, I stated:

"A lot of roadmaps are just a list of features in upcoming releases. This is meaningless to most people outside of the development team."

This next article is about building your roadmap around high-level benefit-oriented themes for both internal and external audiences, and about what to say when asked for commitments on specific features.

Is This a Committed Relationship?

If I'm your customer or a new prospect and I've asked to see your product roadmap, what is it I want to see? I might want to see specific features I have requested and when they are scheduled for release, but you probably can't commit to things in that much detail.

I might also be interested in what breakthrough solutions you have planned for the future, but you'd be foolish to tip your hand to the market too early there as well.

The real question I am asking when I ask to see your roadmap is: "How committed are you to me?" I want to see myself and my issues reflected in your priorities. Much as I might like it, I know that you can't promise specific features on specific dates, but I do want to see that there are ongoing benefits to me and others like me in your vision of the future.

If Not Features, Then What?

Seeing features I might like on your roadmap is certainly one way for me to infer that you have my interests in mind, but it's even better if you can come right out and say what problems you are trying to solve for me. Roadmaps, like any other sales document, should focus on benefits.

Now you probably do have a lot of features in mind for specific releases, but rather than list them all (which wouldn't fit on a slide anyway), there's a better way. What I recommend, instead, is rolling features up into themes.

As I explained in my ProductCamp presentation on roadmapping, a theme is "a group of features tied together by a simple, clear benefit, usually to the user." A theme should:

  • Be high-level and consist of few words. "Streamlined workflow" is much better than "fewer steps in the check-in, check-out process."
  • Make the benefit obvious. "Match your branding" is better than "Support millions of colors."
  • Roll up many details. "Quicker access to your data" is much better than a list of access points with time reduction stats.

Themes Provide Focus and Flexibility

Focusing a release on a small number of themes (1-3) gives your development team goals to strive for and motivates them to deliver on the promised benefits. Given a goal rather than just a list of features, they may even come up with better ways to deliver the value promised by your theme.

This focus also spills over to the marketing and sales teams, which can speak to the specific benefits of particular new releases. Press releases and CEO quotes practically write themselves.

Also, because themes mask detail, they provide you the flexibility to cut individual features without cutting the theme itself. You may have 10 features planned for the "efficiency" theme, but if the work takes longer than planned and you can only deliver on 5, you can still claim you've improved efficiency. (And then start planning for "Efficiency Phase II" or decide there are higher priorities.)

Your Board is Just Another Customer Segment

The roadmap you show your Board of Directors is just a special case of a customer roadmap. The Board wants to see that you are investing wisely to grow your business and reward their investment of time and/or money in the company.

The themes the Board wants to see are even higher level than those most customers care about, though. Typical Board themes might include:

  • Introduce flagship product to China
  • Expand add-on portfolio for core market
  • Enhance competitiveness with investment in analytics

I will cover different roadmaps for different audiences in more detail when I get to Roadmap Roadblock #4: One Size Fits All.

If Asked About Features

When asked (and you will be), avoid committing to specific features on specific dates. Every once in a great while, for a very large or strategic deal, it can make business sense to commit to a feature, even in writing. But this is a very rare situation. Giving in to this often will wreck your credibility, divert your roadmap, and make achieving your vision near impossible. (It can also cause the revenue from the deal to not be recognized until you deliver the feature.)

If someone asks if a given theme includes some pet feature of theirs, your answer should be something like "We’re looking at the best ways to [provide the benefit promised in the theme]. [Feature] is something we’re looking at, but I don’t want to tie my team's hands.

This answer focuses on the benefit you want to provide and reassures the customer you are looking out for them without promising a specific outcome.

Focusing Too Much on Features Rather Than Benefits?

If your organization’s roadmap is bogged down by specific features and commitments, feel free to set up a time to chat with me during my free office hours. You may also be interested my popular roadmapping presentation from ProductCamp Boston, or in Reqqs, the smart roadmap tool for product people.

Use your product powers for good.

Reader Comments (1)

I stumbled across your blog 2 hours ago and I've been reading through your articles since. As someone who is looking to officially make the transition from startup generalist to Product Manager, I'm finding the lessons on this site very valuable. Thanks so much for sharing such insightful information!

October 22, 2013 | Unregistered CommenterAli

PostPost a New Comment

Enter your information below to add a new comment.

My response is on my own website »
Author Email (optional):
Author URL (optional):
Post:
 
Some HTML allowed: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <code> <em> <i> <strike> <strong>