These days I am less and less involved on a day to day basis with delivery teams or even programmes but I do get wheeled in on occasion to offer advice or help with specific – often high level – activities that seem to touch on some element of the broad topic of product management.

None of what I do is rocket science and it is all massively influenced by other far smarter folks I have been lucky enough to encounter in my career. Not surprisingly I’ve been particularly inspired by a lot of what I learned in those early days of GDS when I was struggling to get a handle on the scale of the challenge at ONS (especially the work and words of Jamie Arnold seems to have resonated most with me over the years).

I recently did a bit of a brain dump for a potential client on some of the techniques I have used to get things started – to make sure the foundations are solid enough to launch something ambitious (and to set it up for success.) This is a tidied up version of that email.

It is also a bit of a companion piece to something Anna Shipman has recently written about some advice on ‘strategy’ she had received from Russell Davies all of which I agree with.


I believe strongly that you need to start with a clear, plain spoken VISION. This is what your people get behind and acts as the ‘North Star’ for all activity. It is important that it is ambitious but also understandable and real. This is no time for being vague – it should be something that people can remember and believe in.

Here is a good example of a workshop to help create this

Outcomes and Goals

Emerging from this vision you need OUTCOMES/GOALS that describe what needs to be achieved to make the vision a reality. These really need to be based on the outcome not the output. At this level nobody should be talking about solutions or technologies.


The increasingly common method for this Outcomes/Goals based approach is OKRs. Created by HP and popularised by Google it is now used by organisations from start-ups to the BBC, GDS and Fintech favourites. In my experience it is not done consistently well though and it is worth taking the time to get under the skin of it and do it properly.

Here is the Google guidance on creating them and an example of how they are used in the UK Government


Here is a key factor in OKRs or any other method you choose. You cannot do everything at once. There needs to be a process of prioritisation. Jim Collins famously said

“If you have more than three priorities, you don’t have any”

..and this holds true at organisation scale as well as for an individual. You need to narrow the focus to the core priorities and build out from there rather than trying a scatter gun approach. For this I tend to need four things;

  1. An understanding of what you want to achieve (your Outcomes/Goals)
  2. A clear picture of everything already happening (a register of projects of some kind)
  3. A good understanding of your capabilities – what are you able to delivery (whether in-house or with help)
  4. A methodology and process for the prioritisation of projects or teams

My preferred prioritisation method is RICE (although I do have a tendency to tweak it to fit the environment I’m in when using it) but there are many options the important thing is that one is selected and consistently used (though I really dislike MOSCOW – painful memories – so it isn’t really a part of my toolkit).


Once you have achieved all of this then you need to create a ROADMAP. For me this is the most important artefact in the entire operation and my favourite part of the work. This is what provides direction and reassurance throughout the initiative.

I follow a consistent approach to roadmap creation.

Bring together as representative a group of people involved in the initiative as possible (technical, legal, sales, leadership) and work through these seven questions;

  1. What are we trying to learn or prove?
  2. Who are the users?
  3. What are we operating?
  4. What are we saying?
  5. What are our assumptions?
  6. What are our dependencies?
  7. What capabilities do we need?

..and map the answers out in a loose order in seven ‘swim lanes’ based on a quarter by quarter timeline and sense checking at every stage against your vision, outcomes and priorities.

You can learn more about this technique here

I like to keep things relatively vague with roadmaps – avoiding specific dates or deadlines – but I do find framing things around quarters calms the nerves of some folk and the reality it there is always some kind of underlying order to these things and you do need to acknowledge that…there is also occasionally a bit of a magic dominoes moment when things line up perfectly and one success just sets off a chain reaction of wins…it is rare but it is worth striving for!

This roadmap can evolve and iterate but it should always be at the centre of all discussion.

If possible it should also be analogue and public. Roadmaps work best on walls where they can be seen and discussed.

For me you need to undertake all these tasks and a few others not mentioned here to do with arranging a Governance model – you can learn more here: to lay the foundations of any big ‘digital transformation’ (yes I said it!). With these artefacts and processes in place you can move forward to the delivery stage with confidence and coherence – without it then chaos reigns (though occasionally great things do emerge from that chaos, it is a risky strategy!).


Image of Roj Donald

Roj Donald

Posted on 17th July, 2019:

Jamie Arnold was also a real help to me at my time doing NHS Choices. Some excellent points about roadmaps and only scaling when you're ready.

Add a comment

Your comment will be revised by the site if needed.