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, VP of Product at NetProspex and Chief Product Person at UpUp Labs. In 17 years as a product person, I've built a roadmapping methodology on 5 pillars:
* Strategic goals
* Objective prioritization
* Shuttle diplomacy
* Transparent themes
* Punctuated equilibrium
At last year's ProductCamp, my standing-room-only session on prioritization was a huge hit with product people. This year I will focus on translating your priorities into a roadmap that will inspire your whole team to buy-in, stick with it, and over-deliver.
This presentation was delivered at ProductCamp Boston, May 4, 2013 by Bruce McCarthy
How to Build Roadmaps that Stick - Roadmapping 301 (Bruce McCarthy) ProductCamp Boston may 2013
1. Roadmapping 301
Advanced Roadmapping Class
Bruce McCarthy
Chief Product Person, Reqqs
bruce@reqqs.com
www.reqqs.com
@d8a_driven
1
I’m Bruce McCarthy, Founder and CPP of Reqqs - the smart roadmap tool for product people. I’ve been in product
management for 17 years at companies like iMarket (bought by Dun & Bradstreet) and ATG (bought by Oracle). My
day job currently is VP of Product at NetProspex in Waltham.
I’m here to talk about how to develop roadmaps that stick. This is the advanced class because you guys are well
beyond the basics of H-M-L.
I developed this methodology over time in various jobs. I’ve seen it work over and over again where gut instinct or
endless meetings fail. In talking with other product people, I’ve found the good ones usually develop something
similar. I’ve really just tried to standardize it and genericize it a bit so everyone can benefit.
2. Do roadmaps still
matter?
2
In today’s agile world, do roadmaps still matter? Aren’t we allowed to change direction after each sprint? Actually,
I think roadmaps are needed even more in an agile world. Yes, you can correct course after each sprint, but you
should be correcting course toward something - toward a vision of where you want your product or your company
to be in a year or 2 or 3. You need to stake out that vision and then you need to work out what you think is the
best path to get there. That’s your roadmap.
3. R
3
Your roadmap is also a shield against the constant onslaught of potentially diverting requests from all quarters.
4. “Did [Previous PM] send you his
spreadsheet of [5 trillion un-
prioritized] feature requests?”
- VP Product Management
4
In my experience, large spreadsheets of past feature requests are not usually worth the time to review. Anything
really important will come out in customer or other stakeholder conversations
5. “We need this to close
[big deal] this quarter!”
- Key Sales Person
5
I know a VP of Product who reserves about 5% of his dev team’s capacity just for these things.
6. “37% of our Support calls are about
[oldest, hairiest part of the code].
Can’t we fix it?”
- Support Manager
6
This is a tough one because it’s so reasonable. Look at the ROI on these requests carefully, though, as they won’t
help with new customer acquisition and they will suck up your most senior resources for an extended period.
7. “[Shiny tech thing] will make
[your top priority] much easier!”
- Tech Lead
7
Make them prove it with a schedule for your top priority with and without the shiny tech thing.
8. “[Previously irrelevant competitor]
just shipped [shiny feature]. How are
we going to leapfrog them?”
- VP Marketing
8
I’ve always preferred to solve market problems before marketING problems. Your prospects may not pay nearly as
much attention to your competition as you do.
9. “We gotta drop everything and work
on [meaningless buzzword]. It’s
gonna be huge!”
- VP Sales
9
I’ll talk in a little while about how to roadmap around “transformational items”
10. “If you don’t support [obscure
platform] I can’t buy your stuff.”
- Key Customer CTO
10
Just say no. I used to have the job of determining which 3rd parties to support. It’s really a very simple job. I
figured out that it cost about $1 million per year to add a new supported platform to our testing matrix. That
made the ROI decision really easy. We only ever made an exception once for a multi-million dollar deal.
11. “You can’t add [my pet idea] without
dropping something else? What, is
your whole team lazy?”
- CEO
11
This is my favorite - actually heard - CEO quote. And *proof* that CEOs are bad at math.
12. Roadmaps Inspire
Buy-in from execs
Stick-to-itiveness and over-
delivery from your team
Confidence from Salespeople &
customers
12
A lot of that confidence is about your company and your product, but a lot is also confidence that *you* know
what you’re doing
14. Strategic Goals
“A strategic goal is used
to define the desired
end-state of a war or a
campaign.”
From Wikipedia, the free encyclopedia
14
15. SMART Goals
Specific
Measurable
Attainable
Relevant
Time-bound
15
Your goals usually come from your CEO or your executive team. Strategic goals help you prioritize projects. More
tactical goals are what gets your projects approved. Revenue is nearly always on the list. It’s your job to take what
they give you and translate them into “SMART” goals.
SMART goals are: Specific, Measurable, Attainable, Relevant, Time-bound
16. Typical Goals
Grow the user base
Increase customer satisfaction
Improve performance
Increase referrals
Validated learning
Increase revenue this year
Transformation (revenue in future years)
Generate buzz
16
A tip for when your CEO asks what you are doing that’s “transformative” or “paradigm-shifting” is to think of it as
things that won’t generate significant revenue this year but have a chance to grow it a lot in future years by
entering new markets or serving new needs.
I’ve never been able to get away without including some kind of “coolness” or “buzz factor” goal for anything but
internal projects. If you skip that, someone always complains that we’re not taking into account that we need to
generate excitement in the market to be successful.
17. Pick 2-4 goals
17
If you try to pick one goal, there will always be people (including you) wanting to cram in “just one or two other
little things.” If you pick too many, there is no focus to your project and it’s really hard to prioritize.
But if you pick somewhere around 3 goals, you get a more balanced view and it’s easier to prioritize.
19. Popularity
Your CEO’s Gut
Sales Requests
Analyst Opinions
Most of your customers are
small
He’s no longer in touch with
the market
These change every week
These are mostly backward-
looking
Objective
Prioritization is NOT
19
21. Value / Effort = Priority
21
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?
22. Value / Effort = Priority
Value = Estimated
Contribution to Defined
Goals
22
23. Feature G1 G2 E P
A 1 1 2 1
B 1 0 2 0.5
C 2 -1 1 1
(Goal1+Goal2)/Effort = Priority
23
Removing the QA step to ship early means negative numbers for quality (G2)
There is a lot more detail on this prioritization methodology in my Prioritization 301 presentation on SlideShare
and at www.reqqs.com/resources
25. 25
Henry Kissinger was Nixon’s Secretary of State and famously settled things down in the Middle East after the 1967
war using shuttle diplomacy.
26. Shuttle Diplomacy
“Serving as an
intermediary among
principals in a dispute,
without direct principal-to-
principal contact.”
From Wikipedia, the free encyclopedia
26
This is probably THE most important part of the process. You need to get buy-in from your key stakeholders for
your roadmap to be approved and to stick over time. The best way I have found to do this is to meet with them
individually.
28. “I’ve got a draft set of
priorities. Would you
help me refine it?”
28
Don’t go to them with a finished set of goals and priorities, but ask for their HELP and INPUT in the process. Make
the process transparent to them, invite them into it and you’ll get a much better reaction.
30. “I’ll present our
priorities to the executive
team on Friday”
Collaboration
30
When you collaborate on the development of your plan with your key stakeholders, a magical thing happens.
“Your” plan becomes their plan, too. This makes the big review meeting with the execs to approve your roadmap
more of a formality because everyone around the table had a hand in putting together the plan.
32. Transparent Themes
“A group of features tied
together by a simple, clear
benefit, usually to the user”
From Bruce’s Product Person Dictionary
32
You’ll see in a minute what I mean by
“usually”
33. Themes Are Vague
High-level, few words
Make the benefit obvious
Many details rolled up
Cut features & still declare
victory!
33
Yes, they are vague on purpose. Clear in benefit - but vague in implementation.
You can decide to cut specific features within a theme without dropping the theme itself. This helps you manage
expectations and preserve the roadmap in the face of shrinking budgets, shifting resources and slipping
schedules. It allows you to publish a roadmap months out that you can show to execs and even to customers and
still feel confident you can deliver.
If someone asks about a specific feature within a theme (does Easier Scheduling include popup calendars?), your
answer should be: “We’re looking at the best way to make scheduling easier as soon as we can. Popup calendars is
something we’re looking at but I don’t want to pre-judge exactly how it will come out.” It’s like the President
saying “all options are on the table” about Iran.
34. Typical Themes
Simpler Workflow
Faster Checkout
Better Scheduling
Social Connections
Referral Program
New Platform
34
Benefits to customers are things like the first three. Many individual features or tweaks to the UI would roll up into
these themes.
The next two are more like epics, large features with lots of parts you might keep or cut depending on how the
schedule goes. These are valid for the roadmap, too, as long as your stakeholders see the value in them.
Something infrastructure or engineering-oriented like a new platform, API or refactoring can appear on your
roadmap. My bias for customer benefit would argue against it, but if it’s going to leave a large hole in your
roadmap because it’s necessary and it eats up a lot of time, then you should include it on an internal roadmap
(never an external one). At worst, it will prompt a healthy discussion of whether the work is worth the investment.
35. Cutting a theme
needs an explanation
35
The essential difference between a feature and a theme is that you can usually cut a feature without drama, but
cutting a theme requires an explanation at the executive or customer level. A theme is what’s visible on your
roadmap, so publish that with caution.
36. Q1 Q2 Q3 Q4
Theme A Theme C Theme D
Theme E,
Phase II
Theme B
Theme E,
Phase I
Theme F
Theme G
Weaselly Safe Harbor Statement
36
38. Punctuated Equilibrium
“A theory that evolution
proceeds with long periods of
relative stability interspersed
with rapid change.”
Webster's College Dictionary
38
40. Roadmap Change
People expect it
You probably didn’t ship
everything you wanted to
The market situation has changed
You have more information
Execs have ADD
40
42. 5 Roadmap Pillars
1. Strategic goals
2. Objective prioritization
3. Shuttle diplomacy
4. Transparent themes
5. Punctuated equilibrium
PPPPP
42
Ask if your strategic goals are still correct then re-prioritize the things you haven’t yet done, get buy-in, roll up to
themes... and you’ve got a revised roadmap to publish.