Roadmaps are dangerous with Martin Spinnangr (CPO at Munu)
👋 Hey there! I’m Afonso.
Every week, I either share an insightful story from brilliant product minds in Scandinavia or talk to some of the most influential thought leaders in our industry.
… always with a Scandinavian and European twist in those conversations.
I am on a mission to deeply research the beautifully messy world of building and growing products - and share it all with you.
Consider subscribing for free - and enjoy the ride.
My guest today is my good friend Martin Spinnangr.
Martin is currently the Chief Product Officer at Munu, one of the coolest tech scale-ups in Rogaland at the moment.
Martin and I met at Laerdal Medical, where Martin was a Lead Product Manager leading various digital and physical solutions. After that, he became a Product Director at Easee and - later on - started at Elekt as CPO.
With such a varied and impressive journey so far, Martin has collected so many valuable experiences and loves to share them with the community.
… Oh yeah, and not to mention that Martin is a former Olympic athlete!
This time, we sat down to discuss Martin’s views on roadmaps.
I recommend you pair this read with my episode with Phil Hornby, and most recently the episode with Janna Bastow - where we discussed all things roadmaps.
Martin, Phil and Janna agree on most things and slightly disagree on others.
Let’s dive in.
1. Why do you dislike roadmaps, Martin?
I've created plenty of product roadmaps in my life. A lot. And a lot of different types as well… everything from traditional Gantt chart-looking roadmaps to the Now / Next / Later outcome-based roadmaps.
And the truth is: so far, they haven't been particularly useful for me.
Like everything in the product world, context matters, of course. Other people’s situations and experiences might be very different from mine. So, just because it hasn't worked for me yet doesn't mean it doesn't have to work for you - or for me in the future! But that’s just my baseline from different experiences. Roadmaps never turn out to be the best artifact to fulfill their supposed purpose.
Let’s start there and explore the alternatives we have - that I think are more useful.
2. So what’s the purpose of a roadmap, and what have you found to be a better alternative?
The way I see it is that a roadmap has at least six main purposes:
1. Communicate Vision and Strategy
To me, traditional roadmaps totally miss the mark here. I’m talking about output-based roadmaps, visualizing the features you’re going to build.
This tells us nothing about vision and strategy, so it’s not helpful at all.
A much better way to communicate your product vision and strategy is actually just a written narrative where you describe the reality you want to create for your customers and also the problems you want to solve - based on customer insights, product data, business insights, and so on.
If you read Bruce McCarthy's book and, instead, describe the themes, bets, etc. then that’s fine.
But, unfortunately, this is not what most people think when you’re asked to create a roadmap.
People don’t associate a roadmap with something that will describe your path towards something better - where there's a high degree of uncertainty. They associate it with a plan of what you’re going to build and when.
2. Alignment and Collaboration
The second purpose of a roadmap is alignment and collaboration. The idea here is that showing what you’re working on and what you’ll be doing in the future with a roadmap, will drive alignment and foster collaboration.
But then again, I'm a much bigger advocate of leveraging team objectives. And sometimes, if needed, shared team objectives where teams come together and figure out the best way to solve problems.
I find this a much better approach to really rally the organization around top priorities than a roadmap.
3. Prioritization and Decision making
The third purpose is Prioritization and Decision making. And again, I feel like a typical roadmap falls short of trying to fulfill this purpose. Prioritization and decision-making should be made easier...
Having a vision, a strategy, and team objectives enables you to connect the dots and should be your filter for driving decision-making - not something that you put up on a visual illustration.
Strategic context combined with team objectives is more than enough to create an environment where teams can make decisions. If you have that, why do you still need a roadmap?
4. Planning and forecasting
The fourth purpose of a roadmap is to, in theory, help us plan and forecast.
It sounds great to be in a situation where you can confidently say that all the stuff you have on the roadmap will drive the impact toward your goals and how long it will take to get that stuff out. If that's the case, by all means, just keep that roadmap…
But when dealing with innovation, this is very seldom the case, at least not for longer periods.
It could be that you have done your homework, done proper product discovery, and you know this feature is going to be great and your engineers have made some prototypes - so they know a little bit of how much time it would take to build this stuff right.
However, again, this is seldom the case. Most teams don’t do this. The stuff that ends up being on these roadmaps is just guesses.
And here’s the thing: because it was put on a “roadmap” it creates this false promise that it will be delivered. It sends a message to the whole organization that we know we need to deliver this, and it cannot change.
The worst case is when the teams are not even involved in setting those commitments and dates. That “forecast” couldn’t be more artificial and - most of the time - proven to be wrong, sooner or later.
So, even if you’ve done your “homework” with proper product discovery and you know what you should build, you’re dealing with so much uncertainty when it comes to actually building it that it’s kinda useless to set a rigid deadline that we truly believe in.
Yes, sometimes we need high-intensity commitments. But in general, we as human beings are terrible at estimating deadlines. Ever for less “uncertain” environments and contexts… Things come up.
5. Tracking progress and performance
So, roadmaps can be a great way to illustrate or visualize progress, liking showing what’s been delivered and what we’re going to deliver next. But then again, is that the progress that truly matters? What’s more important: the time it will take to bring new stuff out or the time to make progress towards the outcomes that we’re pursuing?
So again, going back to if you have OKRs, you could showcase your progress as a percentage of progress towards something that actually matters for the business or for your customers - like using a percentage or a slider bar for example. That to me, sends a much stronger and clear signal of real progress towards something we all agreed is meaningful (the outcome).
And you can ask: Why not have both? Well, you can, but then you have to maintain both artifacts and so on.
6. Market and stakeholder communication
So communicating your roadmap externally can be both fantastic and bad, depending on your situation. An example, if you're dealing with an open platform where technology partners can build solutions on top of your solution it could be a good idea to showcase what you're up to.
It can aslo be a way for you to kinda test the waters in the market. Because, well, once you’re communicating that you will be working on X and Y - if you start validating that people are not interested after all, this can be great. However, if you're not confident and haven’t done your homework properly, showcasing it publicly will just backfire. People will expect it to come. Externally and internally. Sales will get excited. Marketing will start planning, and so on. And then you’re kinda locked.
In other words, by just having the roadmap, even when you try to have outcomes only and all that stuff - the natural tendency is to become features.
3. That’s a great point. The intentions are good, people want to focus on outcomes - but it’s easy to slide a feature or two in that roadmap after a while. And, all of a sudden, it’s a feature-based roadmap again where people are back to planning outputs and committing to stuff you don’t know you should build. It takes really strong product teams and leaders to avoid this situation.
Yeah, exactly. If you have, for example, a written narrative and OKRs - that’s enough and in my experience easier to stay on track with the right mindset!
That’s why roadmaps are dangerous. There are folks using them well - and by all means, if it’s working for them, they should keep using them. But it can be a trap, and I think there are better alternatives available in our arsenal to cover all the purposes roadmaps have - as we discussed :)
Thanks for reading!
If you want to hear more about roadmaps and how to use them well, check out these two episodes:
