Wouldn't it be great if no one could argue with your roadmap? Wouldn't it just rock if you could cut through the endless debates and circular arguments, get to consensus, and just execute?
I'm Bruce McCarthy, Founder and Chief Product Person at UpUp Labs. In 20 years as a product person, I've built a roadmapping methodology on 7 pillars:
* Strategic Goals
* Generate Ideas
* Objective Prioritization
* Shuttle Diplomacy
* Benefit-oriented Themes
* Appropriate Format & Cadence
* Punctuated Equilibrium
At last year's ProductCamp, my standing-room-only session on prioritization was a huge hit with product people. This year I've focused on translating your priorities into a roadmap that will inspire your whole team to buy-in, stick with it, and over-deliver.
5. It keeps you on
course when
storm clouds
threaten
6. “Is this more important than what’s
already on the roadmap?”
7.
8.
9.
10.
11. The Dirty Dozen
1. Being Too Agile
2. Prioritizing on Gut
3. Over- or Underestimating
4. No Strategic Goals
5. Inside-out Thinking
6. Trying Too Hard to Please
7. Focusing on Features
8. No Buffer
9. Playing Catch-up
10. Not Getting Buy-in
11. Being Too Secretive
12. One Size Fits All
19. Deriving Product Goals from
Company Goals
Improve
Student
Outcomes
Serve
Sm-Md
Districts
Improve
Customer
Satisfaction
Increase
New Wins
Improve
Engagemen
t
X X X
Measure
Usage
X X
Show
Results
X X X X
38. Your roadmap
should tell the
story of how you
will make people
(and yourself)
successful
39. The Dirty Dozen
13. No story
1. Being Too Agile
2. Prioritizing on Gut
3. Over- or Underestimating
4. No Strategic Goals
5. Inside-out Thinking
6. Trying Too Hard to Please
7. Focusing on Features
8. No Buffer
9. Playing Catch-up
10. Not Getting Buy-in
11. Being Too Secretive
12. One Size Fits All
40. Product X is focused on solving
problem Y best for market Z
H1‘14 H2’14 2015 2016
Benefit A
Likely Feature 1
Likely Feature 2
Likely Feature 3
Benefit B Benefit D
Benefit E,
Phase II
Benefit C
Benefit E,
Phase I
Benefit F
Weaselly Safe Harbor Statement
41. The Wombat Garden Hose is focused
on perfecting the landscapes of
affluent Americans
H1‘14 H2’14 2015 2016
Indestruct-ible
hose
20’ length
Easy connections
No-kink armor
Delicate
Flower
Management
Putting Green
Evenness for
Lawns
Infinite
Extensibility
Severe
Weather
Handling
Extended
Reach
Permanent
Installations
Weaselly Safe Harbor Statement
43. I Help Product People
Team coaching via UpUp Labs
Tools: Reqqs - the smart roadmap tool
for product people
Blog: ProductPowers.com
Slideshare.net/bmmccarthy
Twitter: @d8a_driven
Email: bruce@reqqs.com
Want to chat?:
sohelpful.me/brucemccarthy
Notes de l'éditeur
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.
Hi, I’m Bruce McCarthy. I’ve started 3 companies, raised money, and been through 3 acquisitions (on both sides of the table). I’ve got 20 years product management experience in roles from PM to Business Development to VP of Product to Chief Product Person at companies from just me to 100k+, including Oracle, ATG, D&B, NetProspex, and now UpUp Labs, where I work with product development teams to provide coaching and tools to help them ship the right products faster.
A product 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.
A good roadmap inspires.
Buy-in from execs
Confidence from salespeople
Loyalty from customers
Stick-to-itiveness & over-delivery from your team
It’s a shield, used to deflect ideas that may be good, but will divert you from your goals
A roadmap is not a project plan with resources, development schedules, dependencies, and ship dates. It should not be in a Gantt chart format. It’s a different sort of document for a different purpose.
Even the agile version seems more focused on the work being done than on what sort of value is being delivered to market.
As a communications vehicle, this public roadmap for Intel completely fails. It shows only code numbers with no notion of why I would want any particular one.
This (also found on the internet) is getting close to something like a useful product roadmap
It skips the details of the development project
It summarizes the key deliverable for each release in a way that I understand the value immediately
It gradually reduces the level of detail as we get further out into the future
In my experience, 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."
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 and get everyone moving in that diretion.
Once you’ve accepted the necessity to have a plan, the next most frequent trap is to prioritize your actions based on your CEO’s gut instinct. This, of course, leads directly to what product manager’s call “shiny object syndrome.”
The truth is that execs hire product people to provide a little more rigor to planning than that. They expect is to validate or “refine” their gut instincts with market data and a bit of math.
A simple equation. It’s really the familiar ROI calculation. Effort is the investment you make to generate value in return. The items in your backlog that have the highest ROI are the ones you should do first, right?
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?
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. A surprising number of exes can’t tell you what they are actually shooting for other than “grow revenue.”
That’s great, but it pays to be both a little more strategic, and a little bit more specific.
What is the goal of having this product? For the company? For the customer?
This format comes from my friend Shardul Mehta, who is a product manager at DiamondMind, a leading provider of e-payment processing services for K-12 independent schools, in VA.
I borrowed and re-jiggered the specific product goals from a company I am familiar with in the edtech business.
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.
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.
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.
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?
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.
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.
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.
The best way I’ve found to develop this buy-in with your key stakeholders is via “shuttle diplomacy.” The idea is to speak with each major stakeholder individually, one on one, to understand what’s important to them before you finalize your plans. That way, they will feel they helped develop their plans and that you listened to their concerns, even if you have to disappoint them in some details.
Henry Kissenger had tougher people to negotiate with in 1967, but these are some of the stakeholders you need to consider.
When I showed this slide to my wife, she said: “Why you still you still do this job I don’t know, but it does explain all the beer.”
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.
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.
If you serve more than one target market, you should develop a separate vision roadmap document (or at least a slide) for each. Notice I didn’t say a separate roadmap for each product; I said a separate one for each market. Unless your products are strictly vertical with no overlap, your roadmap for a given market should include any and all products that you sell or intend to sell in that market.
If the same features of the same product would be viewed by individual markets differently, sell those benefits differently in each. Let’s say you have a new version of your tablet coming out next spring which will feature much greater graphics processing capabilities. You have two core markets that will care about this: gamers and architects. When you show your roadmap at E3, the main theme you’ll want to hit is “stunningly realistic explosions.” When you visit the annual AIA convention, though, you’ll emphasize “dramatically reduced rendering times.”
And if you’ve got a third vertical, say delivery services, for whom graphics power is unimportant, leave that theme out entirely. Focus instead on the lighter weight or the adjustable brightness for outdoor use that will come out in the follow-on model.
Ok, so it’s a baker’s dozen.
A roadmap should tell a story
It needs an honest assessment of reality (a beginning),
plans for moving things toward your goals (a middle)
and a clear vision for where you will end up that makes your customers and your company successful (a happy ending).
A simple, strategic product roadmap template
An example roadmap for a made-up product
Please feel free to contact me about help for your product team or just for yourself.