Product Roadmaps in Five Easy Pieces [Mind the Product]

. . . so my investor said that I need a product manager to do our product roadmap?”

When I worked as a product management consultant clients would often talk about “needing a product roadmap ASAP”.  So I’d dig a little deeper to find out what they really needed, and it was often a return to the first principles of their value proposition and business model. In reality, asking for a product roadmap was shorthand for “please help me with my strategy”.

Product roadmaps are overloaded with significance and are a source of uncertainty among product managers. I now lead a team of over 40 product managers working on public-facing software, staff-facing software, core technology, and agile consultancy: product roadmaps have been the most consistent topic for support and professional development over the last two years. Roadmaps are often the aspect of our practice that receives the most scrutiny and attention, for better or for worse.

The above examples draw out two assumptions I hold about roadmaps:

• Roadmaps are a shorthand for “product management” that workmates outside our profession feel confident in requesting, and provide a great opportunity for us to explain the core concepts of product management
• We (product managers) can feel anxious about creating product roadmaps because they take on such significance for our teams, for our workmates, and for our sense of self worth. We need a safe space to admit this, to share our problems, and to learn from each other.

I’ve created a diagram to help explain, simply, what makes a good roadmap in government but I think it helps in any context. It can also act as a jumping-off point to talk about the core concepts of product management with our workmates.

Let’s take it from the top and look at the five things that make a good roadmap.

1. Context

It’s important to set the context for your product, considering things like product lifecycle stage, organisational needs, and audience. My product roadmaps often sit in several contexts:

Strategic context: A product roadmap is useful when you understand the value of your product today, and your goal for the value of your product in the future – your roadmap connects the two, acting as a strategic tool to plan how you get from your current business model to your vision for a future model, one incremental, prioritised, step at a time.

Product lifecycle context: During development and introduction you’ll likely be focused on prioritising core features. During growth you’ll need to consider sales, marketing, onboarding, and resilience while trying to achieve product/market fit. During maturity you’ll be optimising your business model to increase return on investment. During retirement you’ll be balancing the closure of your product with the needs of remaining users.

Team context: You and your team will use the product roadmap as one of the tools to help you figure out your long-term strategy. It’s also a communication and motivation tool for you and your team. I once ran an infrastructure platform that needed six to nine months of paying down technical debt, and let me tell you: seeing those goals get crossed off, one at a time, was what kept us going during the dark days.

Organisational context: You and your team will use the product roadmap as a communication tool for your workmates and/or your clients. Sometimes you might need versions that hide some of the strategic aspects of the roadmap and instead ‘sell’ your team’s work by giving people what they want. That’s OK. You might need a specific version of your roadmap that’s focused on features – as long as that’s not your only roadmap, you’re OK – think of it as PR.

You might want to acknowledge your product’s context by adding things like your vision, business goals, product name, and logo – as a minimum. But the more general point is: context is important – and changes a lot – so one size does not fit all. I’ve shared a diagram and not a template, you should figure out what works best for your own context.

2. Value

Product management makes promises to solve problems over commitments to specific solutions. We take the human tendency to specify the means of doing something, rather than the result that is wanted, and redirect it by specifying what is to be achieved, rather than how to achieve it. Product managers are usefully agnostic about solutions – we help teams to prioritise the most valuable problems to solve and then help them to prioritise the solution that requires the least work for the most value – and we’re happy when we learn something that helps us to refine and simplify our solution.

Value (expressed in term of outcomes for our users and our organisation) is the beating heart of a good product roadmap, and the heart of product management itself. Your roadmap is driven by a set of hypotheses for improving the value of our product:

• we believe that [this action for these people with this investment]
• will achieve [this outcome]
• we will know that we are successful when we see [this signal].

3. Delivery

Focusing exclusively on features, cost schedules, and deadlines is one of the biggest product roadmap anti-patterns. A document that lists solutions by their deadline is not a product roadmap, it is a delivery schedule or project plan – these are useful in situations of high certainty and slow change, but not for many product development teams. This approach feeds the delivery fallacy: the delivering of features without the creation of value to our users or our organisation.

However, delivery is an important part of the overall strategy for a product so there’s a strong case that it should figure on our roadmap:

• If you’ve got a fixed deadline for a current contract expiring, lots of the team on holiday, or a narrow window of opportunity to reach a user segment for research, then you may need to re-jig your value strategy to fit in with real life
• While you don’t want your roadmap to be a space for committing to features, there may be use cases for talking about technical details on a roadmap. As an example, a couple of years ago my team used this approach to figure out critical paths for options analysis of infrastructure tools, timeboxing the total time for analysis and using the roadmap to help us understand different scenarios we might hit, and the subsequent impact it might have.

Delivery details featuring on a roadmap has a further implication: that the roadmap can be a shared strategic space for multiple professions (not just product managers). In the infrastructure scenario above, the roadmap was shared between me (product/value), delivery manager (workflow), and the WebOps lead (technical options). The roadmap was a shared strategic space to bring several perspectives to an overall strategy.

4. Confidence

Confidence measures are a powerful tool for discussing options while managing expectations. Any roadmap and any team should be mature enough to acknowledge and discuss timeboxes, financial constraints, and results – and any management team should be mature enough to acknowledge and discuss confidence in plans and the need to change as we learn.

Confidence also helps to answer the question of “how far in advance should I project my roadmap?”. If you set a confidence threshold below which your plans cease to have value, then you know that there’s little value in your roadmap extending beyond this point.

Confidence will be influenced by a huge range of factors and is extremely context specific but can be represented simply – in this diagram it is a simple figure at the bottom of the roadmap but I’ve recently seen colleagues using the standard red/amber/green ratings to help manage expectations.

5. Age

One of the most simple and useful additions I started making to my roadmaps after reading Product Roadmaps Relaunched is the “last updated” section, as it sets expectations around the frequency with which we need to review our strategy (and therefore our roadmap). If your roadmap shows 20% confidence in its information after three months and it hasn’t been reviewed and updated in four months then it is probably useless. Personally, I aim to review my roadmaps every month (even if it’s to gain confidence that it’s still fine), and to give a more considered review every quarter.

Further Reading

• If you’re only going to read one thing: Product Roadmaps Relaunched
• If you want examples of set and measuring value goals: Google re:Work Guide: Set Goals with Objectives and Key Results
• If you consider your roadmap connecting your as is value proposition and business model, to your future vision:
  • Strategyzer value proposition canvas
  • Strategyzer business model canvas & Ash Maurya’s lean canvas
  • Roman Pichler’s product vision board
• If you want to read about strategy with value at its heart: Lean Enterprise
• If you’re interested in workflow: Explaining the Role of a Delivery Manager.

The post Product Roadmaps in Five Easy Pieces appeared first on Mind the Product.

Source: Mind the Product http://www.mindtheproduct.com/2018/09/product-roadmaps-in-five-easy-pieces/