PM4UX
Published in

PM4UX

10. Roadmaps and How to Say “No”

  • “Where is the roadmap?”
  • “Is the roadmap up to date?” and
  • “Where are we on the roadmap?”

Defining the Roadmap

What is a roadmap?

A roadmap is not a launch plan

Figure 10.1: If your stakeholders need a release plan, give them one, as shown in this Smartsheet template, but at the same time clarify that this is not a product roadmap.

Feasible horizons: Now, Next, Later

Figure 10.2: This empty product roadmap template (using ProdPad) has three main columns, one for each timeframe.

Now

Next

Later

Product strategy

Outcomes

  • Double retention
  • Increase customer satisfaction by 50%
  • Support user requests for more ways to collaborate with each other
  • Improve performance
  • Reengage with formerly active users

Organized into themes

Laddering up to company objectives

  • articulating clear objectives (basically the same as goals or outcomes) and
  • identifying key results that are measurable and can either confirm or falsify whether the goal was achieved, or in the case of goals that can be achieved in whole or in part, measure to what extent the goal was achieved
  • aligning OKRs up and down an organization so that the objectives of any given team fulfill the key results of the team or leader they report to, all the way up (and down) the chain

Owning the roadmap, or part of it

  • A product portfolio consisting of several lines of products, owned by a Chief Product Officer
  • A line of products, owned by a VP of Product
  • A specific product in a line of products owned by a Product Director
  • A major piece of functionality (onboarding, administration, core experience, etc.) owned by a Group Product Manager
  • A feature owned by a Product Manager
  • A backlog owned by a Product Owner

Prioritization

Prioritization methods

Impact vs Effort

Important vs Urgent

Figure 10.3: The famous Eisenhower Matrix helps you plan ahead for important things that are not literally on fire at right this exact moment.

OK, so back to Impact vs Effort

  • How much value are you likely to derive from doing this thing?
  • How much work will it take for the team to pull it off.
  • What are the opportunity costs of doing this thing and therefore not having time to do that thing?
Figure 10.4: If you need a lot of granularity, put a big cartesian plot on your white board and place stickies in locations that correspond to degree of effort and potential impact,
Figure 10.5: Sorting ideas into these four buckets helps prioritize them at a high level.
Figure 10.6: Drop everything and do those high-impact low-effort ideas!
  1. Definitely do high-impact, low-effort things. They should be the “no brainers” at the top of your list.
  2. Meanwhile, review the ideas that would be high impact but would require much effort. You can’t do all of these things but you should invest effort in some of them (as with the non-urgent but still important items in the Eisenhower matrix).
  3. Just maintain basic quality control through housekeeping, fixing and tackling low-effort low-impact items when convenient.
  4. Immediately delete and spend no more brainpower or cycles on things that would require high effort without promising anything more thaa low impact.
Figure 10.7: Without being too obsessed with positioning, the stickies are placed in the squares roughly relative to each other (with higher impact going higher up vertically and higher effort items going further to the right) in each square

So. Many. Frameworks

  • Reach means the potential audience impact of the idea (similar to the traffic dimension of the experimental pipeline prioritization engine discussed in Chapter 6. Considering this can help you calibrate ideas against each other (since big impact with a smaller audience may not actually be bigger than a smaller impact with a bigger audience).
  • Confidence is a percentage used to challenge how sure you are about your assessments of the potential reach, impact, and effort. It gives more credit to ideas supported by evidence.

Populating and maintaining the roadmap

Figure 10.8: The ideas sorted by our imaginary product team placed on a thematic roadmap with relative time horizons.

When there is no roadmap

Keep a roadmap fresh

  • On a monthly basis (if not each sprint) review the current workload of your team against the roadmap and make sure that the top commitments are getting attention. If the team is getting pulled into things that are not in the plan, escalate this to the attention of your boss. This does not mean refusing to do unplanned work (which would hardly be “agile”) but making sure that the roadmap doesn’t drift away from reality and become useless. Instead, any gap between planned work and actual is new information to be fed back in to the discussion and used to reset expectations and make intentional choices about new tradeoffs.
  • Each quarter revisit the roadmap with all stakeholders, review what got done, what has moved from Next to Now, what has moved from Later to Next, and what new ideas need to be tracked for Later.

Managing Expectations

  • Now is this quarter, a roughly 1–3 month period depending on where we are in the quarter.
  • Next is the six month period following the current quarter. The items in that bucket will likely come to fruition in that period but it’s impossible to be more specific. (So at this point the plan covers roughly 7–9 months).
  • Later is the nine month period that takes us out to about a year and a half from the start of the current quarter. It’s pretty much impossible to make plans further out than 18 months, and the items you’ve parked in the second half of that timeframe are necessarily broad and subject to revision every time you reevaluate your roadmap.

Epilogue to the Break Even story

  1. Where we’re going there are no roads: break even business as a platform for experimentation
  2. The band is just fantastic: doubling down on the value in the core service and paid version of it
  3. Go for broke: looking for breakthrough, game-changing, market-making opportunities

The art of saying No

Who will you have to say No to?

  • Customers
  • Partners
  • Advisors
  • Sales, Business Development, Partners, and Customer Success
  • Marketing
  • Engineers
  • UX Designers (sorry!)
  • and, of course the CEO

Who does have a say?

  1. The product vision
  2. Feedback from users
  3. What the data is telling you
  4. Ideas that come from the rest of the team (bandwidth permitting)
  1. Thank the stakeholder for offering their advice.
  2. Ask questions about the suggestion: what problem is it intended to solve or opportunity is it intended to exploit? what is the expected outcome of delivering this feature or ideas? What are the risk of not doing it? Were other ways to address this situation considered?
  3. Offer to research and explore the problem space further
  4. Review the current top priorities in the Now bucket and how they connect to company strategy, objective, and key results.
  5. Ask which of the commitments that have already been presented, argued for, and which have obtained buy-in should be set aside to pursue this new potential priority. Remind that these changes will need to be reviewed and reevaluated by all stakeholders.
  6. Ask for data to justify this priority and have your own data ready to make the case for the priorities you already fought for and won.
  7. And, finally, if overpowered and forced to elevate an unwanted priority, be sure to define success metrics, measure the impact, and report back eventually both on the eventual outcome of the novel idea as well as the impact of dropping the priorities that had to be cut to make room.

When the Brass Wants Aha!

Figure 10.9: If you have a complex roadmap and need to communicate it in multiple ways, a tool like Aha can help (but it may drag you back into the “release plan vs. roadmap” battle all over again).

Key Insights

  • A roadmap communicates what goals the product team is working on now and planning to work on in the future.
  • A roadmap is not a launch plan
  • Roadmaps are best managed in three time horizons: Now, Next, and Later
  • Roadmaps should focus on desired outcomes organized by themes, and not laundry lists of wishlist features and pet peeves
  • A product roadmap communicates the product strategy, which is itself an expression of the organization’s larger strategy.
  • You may own an entire roadmap or just a tiny part of one
  • Roadmap planning requires rigorous, systematic prioritization of ideas that may come from vision, users, data, and colleagues.
  • You’ll need to make a case for your priorities and obtain buy-in for your roadmap.
  • Roadmaps require constant care and feeding, and you need to keep stakeholders abreast of updates and changes as priorities evolve and external circumstances change.
  • Practice saying No.
  • The boss may still overrule you.
  • It can be useful at times to be able to show your roadmap in multiple ways depending on who’s asking.

--

--

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
christian crumlish

christian crumlish

2.5K Followers

Product leader @dinp.xyz, writing Product Management for UX Designers (Rosenfeld Media) and Growing Product People (Sense and Respond) — more xian @crumlish.me.