Pretty much everything I do and say when it comes to product roadmaps was influenced/stolen from Jamie Arnold and this post/presentation is no different. If you want real insight into how to do these things well get him in to talk you through his ‘masterclass’. In the meantime you can enjoy this Aldi version.

===========================================

“The greatest trick the devil ever pulled was convincing the world there was no planning in agile.”

===========================================

There is this myth, initiated by agents of Big PRINCE2, that there is no planning in agile. That it is all Post-Its and prayer. A chaos cult with no governance that cannot be relied on by serious people.

This is, of course, nonsense.

In fact I don’t believe any other approach comes close to the amount of blood, sweat and tears that goes into planning in agile.

Visions, missions, roadmaps, project plans, release plans, sprint plans, backlogs, Kanban boards, scrum of scrums, comms plans…it is all planning.

That said, a hard lesson every Agile/Product purist learns in Government: There is no substitute for the PLAN.

You know the kind of PLAN. Tasks, dependencies and milestones. Give it a coat of GANTT and everyone breathes a sigh of relief. It is something engrained in the DNA of the Civil Service. 

I’m not going to pretend it doesn’t make me sad that this is the case but I have spent too much of my professional life arguing that the product roadmap should provide sufficient assurance and detail for the ‘powers that be’…and I can count the number of times I’ve succeeded on one hand…and I don’t need my thumb.

So this is my approach to balancing the two without it becoming an entire industry.

===========================================

“I love it when a plan comes together.” – Colonel John “Hannibal” Smith

===========================================

PROJECT PLAN VS PRODUCT ROADMAP

Project Plan (owned by the Delivery Manager):

– Prescriptive

– Outputs

– Document

– % Complete

Product Roadmap (owned by the Product Manager):

– Adaptive

– Outcomes

– Communication

– Benefit

Now to be clear when I say ‘owned’ I do not mean they go away to a dark room and emerge days/weeks later with the artefact – creating both is a collaborative effort and they should be closely aligned – but someone needs to be on the hook.

===========================================

“It takes two.” – Rob Base

===========================================

ROADMAPS

This is how Jamie describes the task of roadmapping and the principles of good ones.

Roadmapping (verb):

Having the right conversations, asking the right questions and communicating the strategy are more important than the format.

Good roadmaps:

• Are not a promise

• Promote conversations

• Prove things

• Link to detail

• Evolve

Roadmaps are about Outcomes and again Jamie explains what a good Outcome looks like best.

This is always the biggest challenge I find – getting teams to shift from an Outputs to Outcomes mentality. Once you unlock that then so much of this way of working opens up but until then it can feel like speaking a different language and frustrating for everyone involved.

Like everything in Agile/Digital/Product – roadmaps are a TEAM SPORT. The best teams collaborate and their roadmaps reflect the perspectives of all the participants – not the wish list of the Product Manager (or worse – the senior stakeholder).

These are the questions I like to ask in order to build out the roadmap;

• What are we trying to learn or prove (our Outcomes)?
• Who are our users?
• How does it happen now (if it does?)
• What assumptions are we making?
• Do we have the capability & capacity to succeed?

…and I ask them a lot. Start with the team but for it really to land you have to look at engaging with at least a couple of additional rings in Emily’s Team Onion. You don’t have to do what stakeholders want…but you need to know what they care about and have an explanation (with evidence) of why not.

Based on Seven Questions by Richard Pope and Jamie Arnold

===========================================

ROADMAP TOOLS

Product Managers get obsessed with the right tool/software. I’ve known teams delay finalising their roadmaps for months while they wait for the procurement of a new, magic SaaS product.

Seriously it does not matter a jot. Powerpoint is fine, so is Word, or even blooming Excel. Increasingly I see them in Mural/Miro, which makes me shudder a bit but is perfectly okay.

Just have the conversations and write it down somewhere that is easy for you to share and update in your own context. Roadmaps evolve and are primarily a communication tool so it is no use picking a tool that nobody outside the team can see and hardly anyone can update.

Examples of roadmaps in the wild

Ross has been collating open Roadmap examples from across public service from all over the world and it is definitely looking at the different approaches (I particular admire the NHS ones) – 

sites.google.com/view/public-back-roads/public-sector-backlogs-and-roadmaps

…and if you want to better understand the myriad of different formats then – again – ask Jamie to share his collection.

I am a bit basic though and stick to the Now/Next/Later approach.

===========================================

My NOW/NEXT/LATER expectations

NOW:

– Represents the next quarter of activity

– To all intents and purposes it is your OKRs if you are doing them

– Each entry links to the corresponding OKR with relevant details – if you aren’t doing OKRs I like to see some narrative about why this needs to be done now and what impact/learning it unlocks.

– NOW also has a corresponding Project Plan – just the NOW

NEXT:

– Represents the following six months of expected activity

– Will be less certain and some details will be sketchy

– Should reflect the strategic ambition and be rooted in evidence as much as possible

– Adding detail is encouraged but not mandatory

LATER:

– Should contain your hopes and dreams

– Where you document your ambitions

– The land of might – things will inevitably change when you learn more

– Where stakeholders will be most uncomfortable

– Heavy lifting in building trust has to be up front in NOW and NEXT

===========================================

PROJECT PLANS

(or Delivery Plans…or Release Plans)

I wish this wasn’t the case but like I said about…’Now’ needs a proper plan. Just ‘Now’ though. Try to avoid straying into massive MSP programme plans that include ‘Next’ and ‘Later’ – that will break you. Just provide enough detail, for enough time, to generate enough trust to get on with things.

This will mean tasks/outputs, dependencies and milestones but I would still avoid specific dates as much as possible –  my experience is that estimated sprints are usually fine.

The key point is to Avoid FALSE CERTAINTY…while providing assurance in a format native to stakeholders that they were raised to understand and trust.