Published: Jun 18, 2014
This article was originally published in Sept 2013 on Bruce’s blog, Product Powers. The original post also offers more in-depth information on the roadblocks.
A good product roadmap is one of the most important and influential documents an organization can develop, publish and continuously update. It’s the one document that steers the entire organization in delivering on the company strategy.
It’s key to success, and yet many organizations struggle to produce effective roadmaps. In fact, many organizations don’t create one, even to publish internally. Or they do, but it is simply a collection of unrelated features and dates.
A roadmap is your vision for how a product (or product line) will help achieve your organization’s strategic goals. In that sense, it is literally a map of the steps involved in getting your business where you want it to go. To make it even more concrete, I also like to think of a product roadmap as a timeline view of your priorities.
A good roadmap inspires. It inspires buy-in from executives, inspires confidence from customers and salespeople, and inspires development teams to produce the groundbreaking products that drive significant growth.
A good roadmap keeps your organization on course toward its destination. Stating what you will do and when makes it easy to judge when you fall behind schedule or get detoured by good ideas that just don’t fit your strategic vision.
In my experience, though, there are some specific areas where companies commonly break down in developing roadmaps, hitting roadblocks that often keep them from getting where they want to go. I call these roadmap roadblocks the “Dirty Dozen.”
If a roadmap is the path toward your goals, you obviously need to set those goals before you start. Yet many companies fail to sit down and explicitly describe the destination they are driving toward.
Is your product roadmap aligned with your strategic goals? Have a conversation with your CEO or another exec in the know. It may clarify a lot of your prioritization dilemmas.
A lot of roadmaps are just a list of features in upcoming releases. This is meaningless to most people outside of the development team. A roadmap should make it obvious how things will improve for your customers, organization or shareholders. Like any good sales pitch, it should focus on delivering value.
Look at your roadmap from the point of view of a board member or a customer. Would they see their interests reflected?
Focusing on features can be a symptom of failing to understand your market. Yes, priorities should be driven by internal goals, but those goals must also respond to market reality.
Ask yourself whether your roadmap priorities are driven by the needs of the people and organizations you intend to serve. Strive to bring that message from the outside in.
You probably serve more than one market segment. When you are talking to customers or partners in one segment, the roadmap you show should focus on how you will address their needs.
Make sure your roadmap is not one-size-fits-all. If a customer sees their interests in only 1 of the next 6 releases, they’ll get the message that you are not focused on them.
That said, many roadmaps are simply lists of customer requests prioritized by number (or size) of customers requesting or voting for the feature. This may help with retention for a while, but will not drive your company into new markets or to invent anything new.
Rather than just taking requests, listening for unsolved problems in your market (and doing something about them) is the best way to avoid a roadmap that’s really just a popularity contest.
It’s often a mistake to focus on matching your competition feature-for-feature. All this does is commoditize your market. Instead, focus on creating unique value by developing solutions your competition can’t easily duplicate.
How many items on your roadmap are “me too” features designed to close perceived competitive gaps? How many of those have actually lost you business?
The best-conceived roadmap won’t get you where you need to go if you can’t get anyone else to come along for the ride. You’ve got to get your development, sales, marketing, finance and other stakeholders involved early so it becomes their plan, not just yours.
If people use words like “intellectual,” “cerebral,” “theoretical,” or “ivory tower” to describe you or your work, this is code for lack of buy-in.
Good product people develop good instincts for their market. As a company grows, though, it’s hard to get the buy-in you need from all players based just on your instincts.
Can you tie everything on your roadmap back to your strategic goals? Can you show the ROI calculations that put priority 1 ahead of priority 2? A little data settles a lot of arguments.
Agile was developed as a response to lack of consistent direction from business execs. That doesn’t mean it’s incompatible with good direction. Yet many companies fear to map out a course thinking it’s not allowed in Agile.
Don’t let being agile become an excuse for indecision. You may choose to adjust course down the road, but you’ll move a lot faster if you first take your best guess at a destination.
Some organizations have a roadmap but shy away from sharing it with anyone. It might be fear of revenue recognition issues, lack of confidence in the company’s direction, or just not wanting to look foolish if things change.
A good roadmap is not a contract. It can and should be designed as a statement of direction and intent, but customers and investors expect you to accept and act on feedback from the market. They expect your roadmap to change, so stop worrying.
One reason an organization might be reluctant to share is if their roadmap is too detailed. A roadmap consisting of 40 bulleted features in each of 10 precisely-dated releases is impossible to read, and can really constrain your options for adjusting course down the road.
Your roadmap should consist of problem-solving themes and broad time-frames. This gives you the leeway to cut or defer a specific feature without risking on-time arrival at your destination.
ROI is a critical consideration in prioritization, yet many product teams make the mistake of setting business priorities without considering development costs. Conversely, some teams spend months estimating every possible product initiative without first considering which are likely to be worth the time.
Approach your technical partner for a quick, high-level estimate of the work involved in your 10 most wanted. What if #4 turns out to be trivially easy compared to the 3 ahead of it? Wouldn’t you like to know that up front?
Check out his virtual seminar, Lean Roadmapping: Where Product Management & UX Meet.
Bruce McCarthy is a founder of three startups. He’s invested in helping product managers and UX designers work smarter. You can get a taste of his fun, teaching style at his blog, Product Powers. You can follow Bruce on Twitter @d8a_driven.
What roadblocks have challenged your organization in creating product roadmaps? Tell us about it at the UIE blog.
Read related articles: