How to create your first, simple roadmap
Compromise on best practice. Introducing starter roadmaps to your organisation will support conversation and foster a wider product mindset.
Product Management can be challenging at traditional companies. There’s often discord between the ‘best practice’ we learn and what’s possible on the ground. Lean, outcome-based processes seem a world away from the waterfall projects and annual budget cycles that surround us. But, tempting as it may be, there’s no point preaching the gospel without pragmatism. Successful leaders in mature organisations aren’t going to have a Damascene conversion to the Church of Cagan. Yet this doesn’t mean we can’t add real value today: things like roadmaps can make an immediate impact.
So let’s get meta. I’m going to talk about a roadmap to your Roadmap: the first, crucial step towards something Janna Bastow might recommend. Nothing perfect or pretty, but better than yesterday and a start.
So, if you work in an organisation accustomed to delays, disappointment and Gantt charts, what should your first roadmap look like?
1. Loosen timelines, but keep dates
Has there ever been an accurate Gantt chart? They are way too granular and inflexible - in fact, on projects where there is technical uncertainty, they are almost entirely performative: they give the illusion of control. On the other hand, ‘Now, Next, Later’ roadmaps, while a brilliant idea, are too ambiguous to fly with stakeholders whose first question is always, ‘When?’
So, use the basic framework of ‘Now, Next, Later’, but solidify around timeframes that fit your organisation’s planning process - such as quarters or months. This gives flexibility and introduces the concept of horizons in a light way, without giving your stakeholders whiplash.
2. Link outputs to outcomes
I believe that ‘Outcomes over outputs’ is the cornerstone of good product management and the key differentiator from ‘Project’. But most companies are used to commissioning their teams to build things, so the journey from feature factories to empowered teams has to be an evolution. So, don’t attempt to chuck out the ‘what’ entirely, but do explicitly attach the ‘why’.
What does this look like in practical terms? Well, a best practice roadmap might anchor around the goal, ‘Increase Customer Lifetime Value’ with ‘Improve Login journey’ a nested feature underneath it. But it’s more likely that you have a list of (hopefully useful) stuff to do, such as ‘Add image zoom on product pages’. Keep these features as the focus of your first roadmap, but tag items with a small number of outcomes, to show how things connect together. If features don’t ladder to something bigger, make this explicit, with a tag such as ‘Objective unknown’.
3. Add swimlanes
Further to this, your team might be working to deliver items for a number of projects. This can lead to a lack of focus and competing priorities - especially if funding comes from different areas. Don’t shy away from showing this. If your order list is unfocused, put each project in its own swimlane. This isn’t pure passive aggression. Visualising the workload will clarify your own understanding while demonstrating raw volume and context switching. This will trigger sensible discussions around sequencing and, even if the focus is delivery speed, rather than value, dialogue will have begun.
4. T-shirt size
To hammer home capacity issues, add relative size estimates. This helps articulate why timelines might be ambitious or, more realistically, drive conversations around prioritisation. Keep it simple: S, M, L and maybe XL.
Tip: Don’t be tempted to condense the representation of complex initiatives to keep your roadmap tidy. Go the other way. If you have lots to do, break the work down so that it takes up more real estate in your visuals.
5. Introduce the concept of problems and solutions
This is where you can move to something closer to ‘proper’ Product. For each item in your roadmap, articulate the problem you are looking to solve, the evidence you have to support your understanding of this problem, potential solutions and your chosen solution, plus some notes. If you don’t have evidence or something isn’t clear, flag it. For example:
Problem: Users are only purchasing through our app once. We believe this is because they are offered a discount on their first app order but there are no compelling reasons to repeat purchase through this channel.
Evidence: There is some suggestion that users are creating multiple accounts to access the offer, but no data cleansing or customer interviews conducted.
Solution: Create a loyalty scheme to offer financial incentives to return customers.
Other solutions considered: None.
Notes: Loyalty scheme idea discussed and agreed at Exco. Funded through 2023 budget cycle.
What is the value of this approach? Firstly, writing things down in such simple terms exposes assumptions and stretched logic. In the example above, it would be pretty easy to increase your knowledge of the problem. The chosen solution could turn out to be right or other, better options could be uncovered. But, even more importantly, you are sharing the gaps in your knowledge with stakeholders: you might even find they can help you fill in the blanks.
Tip: Don’t worry about leaving gaps in items ‘to the right’ of your roadmap. While this starter roadmap is not as ambiguous about delivery timescales or as linked to outcomes as a ‘Now, Next, Later’ model, it should help your stakeholders learn how uncertainty can be reduced through discovery. They will thank you for reducing risk. Eventually.
6. Expose dependencies
Another simple one. Projects and portfolios are often a web of dependencies - especially where legacy tech is involved. Shifting to roadmaps won’t alter this reality, so embrace it. Put big, DEPENDENCY flags on every item that could become blocked. Alongside your Problem and Solution statements, note the projects and teams you need to deliver before or in parallel with your efforts. Always look for workarounds, but be clear that your destiny is not completely in your own hands.
7. Provide relative value
One last - and very important - thing to add: Value.
If you work in an environment where impact on metrics is unclear, associate your roadmap items with internally-perceived value. Consider appropriating known terminology such as Moscow or High, Medium, Low ratings. As with many things on this list, the idea is to introduce the notion of value into the delivery process to provoke discussion.
…and one to avoid: linking to Jira
Please don’t attempt to connect your roadmap to your backlog. This creates an admin burden with no upside and psychologically connects your roadmap - which should edge stakeholders towards an outcome-focus - to delivery plans, which are output-oriented.
Note: I’m not saying that strong performance around delivery isn’t important. But it is only a means to an end.
You’re on your way
A roadmap isn’t a plan. It’s a framework for discussing problems and solutions, priorities and trade-offs in a clear, consistent and even-handed way. Use it to clarify your intentions with your team and wider stakeholder network. Let it be the subject of conversation. Ask, ‘How can we improve the logic of decision making?’ and ‘Does this ladder to business goals?’ regularly. You work with smart people, help them make better decisions by quietly introducing a product mindset into their day to day.