Nov 7 2018 - What does an agile product roadmap look like?

What does an agile product roadmap look like?

November 07, 2018

What does an agile product roadmap look like? 

Sense & Respond Press is on a roll! Last month we announced the release of two great new books on hiring. This month, we're excited to announce the launch of Lateral Leadership: A practical guide to managing agile teams by Tim Herbig. Tim is a veteran product manager and has shared his wisdom on how to manage and lead product teams when you're not the boss of these teams. You can pre-order Lateral Leadership now. 

One of the biggest challenges in product management is planning the work in a linear, visual way. Sure, we’ve had “roadmaps” for a long time but they betray the true nature of software development. Digital product development is not linear. It is iterative. We build some things. We ship them. We see how they impact customer behaviour. We iterate them and ship again. The traditional linear roadmap model, one where there is a starting point and clear, feature-specific endpoint (almost always with a fixed date) is outdated. It reflects an output-focused mode of operating a digital business. Instead, today, successful product-led organisations focus on outcomes. Outcomes, as I’ve mentioned here time and again, are the changes in customer behaviour that affect our business success. They are the true measure of the efficacy of our work and how well we’re meeting the needs of our customers and users. However, managing to outcomes is much more difficult as it dispenses with the pretence that we can predict the future, know exactly how our software will look and function and what our customers will do with it when they finally get to use it. How then do we build product roadmaps in a world of continuous improvement, learning and agility? Here is what an agile product roadmap should look like:You’ll notice a few key components in this diagram:

  1. Strategic themes — these are the organisational product strategies set by executive leaders pointing the teams in a specific direction. These can be things like, “Expand our market share in Europe” or “Leverage the under-utilised time our fleet isn’t ferrying passengers to deliver other goods and food.” There can be multiple themes running in parallel for a larger organisation. 

  2. Quarterly OKR goals — we’ve spoken here about Objectives and Key Results in the past but it’s worth reiterating that OKR, when done well, use customer behaviour as the metrics in the “key results” part of the equation. These quarterly outcome goals are where each team is going to focus in an effort to help achieve the strategic theme. This is the goal teams strive to achieve. It is their definition of success and their definition of done. They should work together with leadership to ensure these are aligned and properly levelled. 

  3. Feature/product hypotheses — These are the team’s best guesses as to how they will achieve this quarter’s OKR goals. Looking out one quarter in advance a team can make strong, educated guesses about what product or feature ideas they think will achieve their quarterly goals. Looking out two quarters ahead, those guesses become less confident so the team makes less of them. Three and four quarters out, the teams really have no idea what they’ll be working on so these guesses become fewer and fewer. This is exactly the way it should be. Teams will learn in the next quarter or two how well their ideas worked, what moves the needles forward and what their next guesses should be. The boxes for Q3 and Q4 will fill up as learning from Q1 and Q2 gets synthesised and acted on. 

Frequency of review:Each team should present this type of outcome-based roadmap for review at the beginning of an annual cycle. It should align with the strategic goals leadership has set and ensure their OKR’s use metrics that ladder up to these goals (Want to learn how to do this? Start here.) While it’s incumbent on the team to continually expose what they are doing, learning and deciding, official check-ins can happen on a quarterly basis. Teams meet with leaders to determine how well they’ve tracked towards their OKR’s, what they’ve learned during the last quarter and what they plan on doing in the next quarter. This is a perfect opportunity to reaffirm the validity of the team’s OKR’s going forward and to make any adjustments based on new learnings, market conditions or any other factor that may have affected the direction of the company. Measuring progress:Progress on this type of roadmap is not measured in how many features have been delivered or whether they’ve been delivered on time. Instead, progress is measured on how well we’ve changed customer behaviour for the better. If our ideas didn’t drive customer success, we kill those ideas and move on to new ones. The learning drives ideas for future quarterly backlogs. These are living documents. We don’t fix these at the beginning of an annual cycle and leave them as if they were etched in stone. There is too much uncertainty and complexity in delivering digital products and services. Product-led organizations — those focused on customer success with empowered teams — ensure that they’re always pointed in the right direction. Outcome-based roadmaps ensure that leaders and teams are being transparent with each other, realistic about their goals and targets and most importantly about how they measure success. What have you tried when it comes to product roadmaps? Has this model worked for you? 

As always, if you want me to work directly with your company on training, coaching or workshops on the topics of organizational agility, digital transformation, product discovery and agile leadership, don’t hesitate to reach out.Like this newsletter? Forward it to a friend. 

Reply

or to participate.