PRODUCTHEAD: Choose your own adventure
PRODUCTHEAD is a regular newsletter of product management goodness,
curated by Jock Busuttil.
these are my twisted products #
A good product roadmap needs good leaders and clearly articulated goals
Make every roadmap goal specific and measurable
Ensure your team owns your roadmap as much as you
a favour: please share this with other product people
every PRODUCTHEAD edition is online for you to refer back to
Depending on your vintage, you may have encountered something called a “Choose Your Own Adventure” book. For the uninitiated, these are a successful series of books that feature non-linear and branched story paths.
More simply, you read forward to a certain page, then that page asks you to make a choice. Depending on that choice you then flip to a different page in the book and continue reading forward from there until you reach another decision point. To be slightly meta for a moment, you might be more familiar with Netflix’s “Black Mirror: Bandersnatch”. The Choose Your Own Adventure books of the 1980s are the inspiration for both the plot and interactive narrative structure of the film.
You’re probably wondering where I’m going with this.
Product roadmaps tend to be linear #
If you were to ask someone what a product manager does, I would place a reasonably safe bet on “responsibility for the product roadmap” being high up their list. It’s the equivalent of the surgeon’s scalpel, the tool of the trade most closely associated with the role.
The thing is, product roadmaps are almost always represented as a linear journey. Whether time is quantified into specific ranges (0-3, 3-6, 6-12 months) or now / next / later, the constant factor is the timeline along the horizontal axis enforcing the sequencing of items.
Real life is branched, not linear #
What I think the most commonly-used roadmaps fail to portray are the choices and branching that happen in real life. I want my roadmap to reflect the discarded choices and failed experiments I learned from that led me to this point, as much as my desired future path.
“Why is it taking so long to improve our conversion rate this quarter?” a passing stakeholder might ask. A traditional roadmap won’t help me to explain the many approaches the team has already tried and discarded on their quest to reach the desired outcome. It’s hard to show my stakeholder where all the time has gone.
A product roadmap isn’t like a collection of fixed checkpoints along a route to a particular destination. It’s more like you and your team are stuck in an maze that gradually reveals itself to you. There are multiple endpoints within that maze and only some of them (if you’re lucky) lead to rewards. Some loop you back to an earlier point. Like the Choose Your Own Adventure books, many of the endings are catastrophic, or at best mediocre. The journey just isn’t that linear.
We try to account for this uncertainty on our product roadmaps by changing the items and their order as we learn new things. Items further out in time are less certain and more likely to change or be replaced entirely as we get closer to them. But all of those historical changes vanish.
Traditional roadmaps are snapshots in time, like frames in a reel of film. They only show us what our roadmap looks like right now. Only by looking frame-by-frame can we see how our product’s journey has been affected by the decisions we’ve taken and what we’ve learned along the way.
What does a non-linear roadmap look like? #
Some visualisation might help. These first is a map of the choice paths of Space and Beyond from Chooseco, the company behind the Choose Your Own Adventure books. The second is a different visualisation of the structure of the same book from a labour of love by Christian Swinehart.
I think product roadmaps look more like this in reality:
In these visualisations, time doesn’t run along a neat, horizontal axis. Time is however long it takes you to reach an outcome along the route you choose. You’re unlikely to choose the perfect path to the most valuable outcome first time. You’re going to hit dead-ends and have to back-track, and that’s going to take time also.
Final thoughts #
Should we all start visualising our roadmaps like this? Probably not. But we should stop fooling ourselves into thinking that our roadmap is a clear and fixed route just because we happen to visualise it that way.
Let’s stop glossing over the options we’ve discarded. Instead, let’s start thinking more about the decision points we reach along the way and how our choices could affect our product’s future path.
Speak to you soon,
what to think about this week
In my last post I wrote about why roadmaps are for everyone. This post is about techniques for building one and how the use of language can help align your pure agile or mixed methodology programmes.
A product roadmap is a powerful tool to describe how a product is likely to grow, to align the stakeholders, and to acquire a budget for developing the product. But creating an effective roadmap is not easy, particularly in an agile context where changes occur frequently and unexpectedly. This post shares ten practical tips to helps you create an actionable agile product roadmap.
[Roman Pichler / Pichler Consulting]
I’ve recently been reading some Christopher Alexander and I’ve found that so much of his theory of Organic Order applies to how software projects grow and get planned.
The “Master Plan” approach typically taken by community administrators is analogous to software roadmaps, and so are the problems that come with it.
Not all roadmaps will suffer from all of the problems at the same time, but they’re all ones to watch out for if you’re using roadmaps in your project.
Reading a “Choose Your Own Adventure” book can feel like being lost in a maze and running through twists and turns only to find dead ends, switchbacks, and disappointment. In the books—for those not familiar with them—you read until you come to a decision point, which prompts you to flip to another page, backward or forward.
[Sarah Laskow / Atlas Obscura]
I would love to pick your brain about product roadmaps.
To give more clarity to my team (which is working on two mandates/sub-projects), I would like to empower them with a roadmap/timeline of the project. We already have one, on Confluence that I’ve printed next to our whiteboard. But it’s not “ours”.
Any recommendation in terms of shape/content?
[I Manage Products]
Product managers of software and hardware platforms face unique challenges that PMs of ‘regular’ products do not.
In this panel discussion, Hans-Bernd Kittlaus discusses platform product management with Samira Negm, Peter Stadlinger and Jock Busuttil.
[I Manage Products]
“There’s plenty that needs doing with the products. I could focus on the hiring process, but the only product manager on my team has their hands full, so I can’t delegate any more to them. I could get stuck in with the products myself as a player-manager, but this means I won’t have time to hire.”
[I Manage Products]
can we help you?
Product People is a product management services company. We can help you through consultancy, training and coaching. Just contact us if you need our help!
Helping people build better products, more successfully, since 2012.
PRODUCTHEAD is a newsletter for product people of all varieties, and is lovingly crafted from a couple of spare tyres.
Read more from Jock
The Practitioner's Guide To Product Management
by Jock Busuttil
“This is a great book for Product Managers or those considering a career in Product Management.”— Lyndsay Denton