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 https://www.annashipman.co.uk/jfdi/russells-strategy-advice 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 https://www.cxpartners.co.uk/our-thinking/a-simple-workshop-format-to-help-you-define-an-effective
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 https://rework.withgoogle.com/guides/set-goals-with-okrs/steps/introduction/ and an example of how they are used in the UK Government https://visitmy.website/2019/02/21/how-we-use-okrs-gov-uk/
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;
- An understanding of what you want to achieve (your Outcomes/Goals)
- A clear picture of everything already happening (a register of projects of some kind)
- A good understanding of your capabilities – what are you able to delivery (whether in-house or with help)
- A methodology and process for the prioritisation of projects or teams
My preferred prioritisation method is RICE https://www.intercom.com/blog/rice-simple-prioritization-for-product-managers/ (although I do have a tendency to tweak it to fit the environment I’m in when using it) but there are many options https://foldingburritos.com/product-prioritization-techniques 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;
- What are we trying to learn or prove?
- Who are the users?
- What are we operating?
- What are we saying?
- What are our assumptions?
- What are our dependencies?
- 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 https://www.jamiearnold.com/blog/2014/07/22/seven-questions-to-build-a-roadmap
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: https://medium.com/@mcleanonline/we-all-need-governance 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!).
Esko Reinikainen summed up the Unconference experience perfectly when he welcomed everyone to GovCamp Cymru – people need to get involved, talk-up, be mindful of all the people in the room and listen, and when you do ‘it just works'.
Are the Big 3 an Oligoply? Some thoughts....
I have seen cloud platforms develop for good and bad over the last decade or so. They are what they are. I hope, as a nation, we can be more intelligent in how we use them in the next ten years than we have been in the last ten.
Introducing Paul Murray our new Senior Delivery Manager
Paul has had a career running public service digital programmes in the UK and New Zealand. He built several key services for the New Zealand government, including their Common Web Platform, Digital Marketplace and most recently he has been running GOVT.NZ. Paul previously worked for the Environment Agency in the UK.