Here’s a summary of his talk.
The product manager should be the entrepreneur in the room in most businesses, says Phil, they should bring the business drive and hustle to carry things forward.
But he thinks that in most businesses the roadmap sucks and he lists seven elements that a roadmap should always contain.
1 Timing
Phil recommends the Product Roadmaps Relaunched book by Bruce Mcarthy and C Todd Lombardo, as it busts so many myths about bad roadmaps. He advocates Now Next Later roadmaps but says in the right context other forms of roadmap are fine.
Now Next Later is about timing. But most people mean they want to shift from features to outcomes when they talk about Now Next Later
2 Context
Context looks at “why are we doing this”, Phil says, in terms of competitors, vision and objectives. He asks: “If you can’t show that something on your roadmap aligns with your objectives then why is it there?”
He likes three points of contact on a roadmap - a strategic theme, an objective like an OKR, and a product principle. You then have a way of codifying decisions you make as an organisation, and don’t need a debate every time you make a decision. As an example, one of Ebays’ product principles is that they favour the buyer over the seller
3 Audience
You need to consider who looks at the roadmap -it might customers, execs, shareholders or investors. A roadmap is a team artefact, owned by the cross-functional team, but driven by the product manager - who doesn’t do anything one their own.
Every audience is different, so you should think about audience and how present the roadmap to them. Phil has developed a roadmap audience canvas that helps define the audience and their needs. He reminds us that communication is for the audience, not the sender.
4 Content
What do you put on the roadmap? It might be themes, outcomes, changing customer behaviour, and user outcomes or jobs to be done.
The roadmap changes constantly but the jobs to be done don’t change. Be ready to translate your language to fit your audience
5 Story
A roadmap fundamentally tells a story, you’re solving a problem for the customer and your customer is the hero of the story.
6 Justification
You must be able to explain why something is on your roadmap, and what problem it’s solving. This is more for internal than external use, says Phil, adding: “Let’s see where AI is in two years time. AI is a solution but what’s the problem I’m solving/”
7 Visualisation
Visualisation is very important and a strong tool in storytelling. Phil says a roadmap should be a single source of truth and provide multiple views. It’s an artefact and shouldn’t take lots of time to maintain.
Phil then provides examples of different types of roadmap and offers critiques of them. He mentions that John Cutler says the reason most roadmaps are bad is because we ask them to do too many jobs. Colours, rows, audience settings are all ways of adding another layer of information to a roadmap. It’s important to distinguish between a roadmap and a release plan.
He also gives some advice about what sort of roadmap might work for different organisations and industries. He likes to use a Now Next Later 3x3 matrix roadmap, with Explore Discover and Deliver on the other axis.
He offers 12 different visual styles of roadmap and concludes by saying: “As a product manager you are a risk manager. Discovery is about risk - should we build it, can we build it, can we make money from it, will people keep coming back. If you can’t answer those four questions your product will fail.”
Comments
Join the community
Sign up for free to share your thoughts