Category Archives: Product Management

Nudging along the government (DDaT) product management career framework

For the record, no I’ve not actually finished all of these.

tl;dr: I’ve tried to write a more modern set of Product Manager roles and skills as my parting bit of value for other ProductFolk in government. At the end of this post there are links to read-only google docs of my straw-man proposals for new role descriptions, skill descriptions and skill levels at the end of this document, plus some other bits of guidance I drafted. They’re not perfect, but there were a lot of discussions leading to getting this far, and I REALLY want this to maintain momentum once I’m gone. The google-doc links are already public, to enable sharing across government, so it feels a small leap to be sharing here in case I’ve missed any important stakeholders. Please join in the process to improve the doc, and finally make something from the 2020s the standard we’re all aiming for.

One of the odd “loose ends” of my time in Cabinet Office was something of a favour. But it was a favour I cared about a lot. And one I really felt I had to find a way to squeeze in before I left government: fixing how we describe “what good looks like” for Product Managers across the public sector.

Background – the problem

The way our roles are defined in government, the skills that matter, and how someone is supposed to progress through their career is set out in the “Digital Data and Technology Profession Capability Framework”. Like all standards, it’s owned by the Central Digital and Data Office these days – setting and maintaining standards and policy were separated from GDS’ remit a few years ago.

The framework is an epic piece of work, and all credit to those involved in the original creation, but for Product Managers it’s looking a little long in the tooth. Which is a problem if you’re trying to use it to set pay, development and progression. You need to be able to encourage and reward the behaviours and skills that matter. It’s also a problem if you’re trying to recruit the right sorts of people into your profession, because you end up filling in a lot of extra gaps in the job descriptions.

At DIT we had a strong marketing and promotional aspect to our work, and weren’t a monopoly provider of advice, which gave us licence to add the sorts of Product skills we needed to the standard framework. DFID did much the same. But GDS and CDDO are still really closely entwined – it doesn’t look good for GDS to be “going it alone”. So when CDDO asked for some of my expertise in refreshing the framework back in late Spring, I jumped at the chance…only to realise this wasn’t strictly GDS work, I still had a day-job and this would have to remain strictly side-of-desk. Which is why it’s taken over six months – and the massive deadline of leaving government completely – to get anything out of the door.

CDDO’s initial concern was that the skill levels listed for “Lead Product Manager” and “Head of Product” were the same – and wondered if I could find a way to make a difference. However, nearly all the skill levels for both of roles were already “Expert” – and the only skill that wasn’t (Financial Ownership) didn’t make sense as the only element of progression.

I decided that the skill levels were right – but it was the *job* that changed and the skills were being used at higher levels of abstraction/scale. I wrote some draft guidance on this – aka “Expert is never ‘done'” – which has been used internally at GDS a bit, and got shared by other professions. This scrappy guidance is further down the document, after the other links. I hope you find it useful too.

But as I picked away at it, there were loads of other itches that needed scratching…

So what did I decide needed to change?

Oh, sooooo much, but here’s a list of key points:

  • The framework doesn’t truly say – to outside eyes – why you need Product Managers and why they’re different from other disciplines. At the height of GDS’s influence on changing government, and when everyone had given up on the shared myth of detailed project plans, this may have been Very Obvious. However, as a new generation of leaders have emerged we can see calls for Solution Architects, Business Architects etc re-emerging – so need to make the case for what we do AND WHY much clearer
  • There are critical skills where people suddenly jump from “awareness” to “practitioner” level when moving from Associate PM to PM. I wanted to set “working” as the goal for a few of the APM roles – even if it sometimes meant writing a new definition. The skills were too easy to achieve at ‘awareness’, and too vast a chasm to bridge at interview. How can a framework help enable useful conversations?
  • In the case of financial awareness, the framework missed out a valuable “working” step that helps highlight the importance of making value-for-money decisions about any given piece of work. Teams need to have better discussions with stakeholders about value released, and better conversations about the financial cost of effort. Even at associate level, a sense of benefits and burn rate is useful. I hope the revised skill is a useful lever for taking ROI more seriously – even if we have to just use estimates for team costs.
  • The “user focus” skill was just soooooo out of date, and hugely directive. It talked about user researchers as though they were just usability-testing drones, working at the bidding of the product manager using methods chosen by the product manager. Or, even worse, expensive frustrated researchers being used as BAs. I wanted to recognise the role of strategic research, and the skills needed to help that happen…as well as the skills needed to avoid six-month-long inconclusive discovery projects. There’s no mention of assumptions testion through bespoke prototypes. Folks, Teresa Torres has been a thing for ages now. Which means we also have frameworks for “interesting research we will need to park for now”.
  • The Product Ownership framework just talked vaguely about ‘tools, terms and techniques’ without saying what any of those were. It also didn’t highlight how the craft had become a vital blend of bringing together business, user and technology perspectives to make hard choices – or the importance of evidence-gathering in the face of uncertainty.
  • Although the Product Ownership skill overlaps slightly with Agile Working, neither really touch on skills from either of the disciplines many early Product folk emerged from – Project Management or Business Analysis. We’ve been so keen to emphasise the new, somehow these essential craft skills were left behind. Being able to map a system and process to find the core thread is essential to defining an MVP; knowing a set of likely delivery steps and how long they’re likely to take is essential to both spotting assumptions and building confidence with stakeholders. That ‘decomposing problems’ aspect starts at the feature level, and continues all the way to programmes – but we hardly mention it.
  • Strategic ownership didn’t tackle the idea of building long-term plans that catered for uncertainty, nor the skills needed to help stakeholders acknowledge risky assumptions within their plans.
  • We didn’t really talk about measuring success
  • The “DDaT Perspective” skill munged a whole pile of bits together that were really about team-working or standards – which could have been dealt with as part of agile working or constraints.
  • Problem Ownership/Working with Constraints/Operational Management all overlapped
  • Programme management and longer-term planning are a thing. Governance matters. We can’t just keep hiding behind startup talk of “now/next/later” roadmaps as though running late is someone else’s problem. OKRs need to get us somewhere. (See my post about roadmaps.) Otherwise SAFe will be embraced by our leaders through sheer desperation.
  • There are a lot of skills. Some professions get away with fewer. Can we meaningfully simplify without losing stuff that matters?

Standing on the shoulders of giants

I’m not the first person to have a go at this, and neither am I the first to run out of time before it can take effect. It’s also not a solo effort – although this is my personal take on where we should go.

I’m hugely indebted to the work of Michael Gordon’s informal cross-government network of Heads and Leads of Product for listening to me talk about this, and providing their own feedback.

Through this group, I also found out about a 2020 attempt to address some of these gaps, when Jonathan Forman was CDDO’s Head of Profession for Product Management. He worked closely with Scott Colfer, then of MOJ Digital, and they ran workshops to gather feedback for improvement. Jon shared those old documents with me and spent an hour talking through the conclusions they’d come to. Often this was just re-confirming my own suspicions – only the gaps are even more critical now.

Jon also created some valuable bloposts and docs that are still available on github.

I’ve also been lucky to have a group of other Heads of Profession around me at GDS to bounce ideas off – although not to the level I’d have liked.

I’ve had great conversations with folks at NHS, DBT, Deloitte and more about the problems this could help fix.

Finally, the three GDS Heads of Product have been great sounding boards for “what good should look like” in terms of recruitment and job descriptions – all of which feed into this.

Thank you all, for all your help.

But I should be clear that this document is mine, not theirs. Any mistakes lie with me, and I’m sure there are points where I’ve misinterpreted feedback. But I still think it’s a step forward.

The Actual Stuff

These documents are supposed to be read as a hierarchy.

We begin with the role descriptions – what a product manager even is, why they’re different from a project manager, and the sort of behaviours you’d expect from them generally. In short: an acceptance of uncertainty as far as human behaviour is concerned, and a range of techniques we use to try and gather evidence to minimise the risks that people simply won’t do what would be convenient for our business model. (In which case all our business benefits are utterly fictional.)

Then I describe how people are likely to progress through the roles, starting on simpler well-defined-problems where they can learn how to interact with a team, iterate based on usability testing, and maintain a backlog. This then builds all the way to Head of Product – where you’re trying to get insight to inform a whole programme’s strategy, while designing the work so it can be delivered through others.

Product Manager Role Descriptions – December 2023 straw-man draft. (This includes the current description from the standard, Jon and Scotts proposed revisions from 2020, and where I think we should be heading to.)

I’ve then tried to tie this back to the individual DDaT skills – removing a few, updating others, adding a new one Jon and Scott proposed around measurement. I’ve also suggested fixing a few gaps where progression is too sudden…or we forgot to mention something crucial from The Old World. This is the document that intersects with other professions, so may be slower going.

Product Manager Skill Descriptions – December 2023 straw-man draft. (Again, this includes Jon and Scott’s work for reference.)

The document also includes what level skills should apply from. I’ve always favoured presenting this as a map, but simply ran out of time.

The current framework, set out as a map – showing how skills mature across role levels.

Mea culpa: the documents are quite long and wordy. There’s a lot of detail. But I think it’s important for the wider community to decide what can be taken for granted.

There’s also a some-people-found-it-useful document about how to evaluate skill levels that span multiple job levels. Others have found ways to define an “Expert+” level to cater for skill development in G6 folk – but that’s not within the gift of GDS if they’re going to follow the CDDO standards.

What next?

The above are an informed guess, based on conversations around government and prior art – but they need the proper discussion I’ve not had time to do to the level I’d have liked. Any errors in here are mine and mine alone – but hopefully they start some useful debate.

Maite and Antony at CDDO have copies of this, along with links to a few discrete groups of people who’ve expressed an interest in the work – ranging from DWP/HMRC/NHSE through to a wide range of arms-length bodies.

I hope they’ll be gathering feedback on this draft, removing some duplication, and running workshops around any particularly gnarly areas – particularly where my suggestions may touch other professions, or where they might not work for all departments. And finally, Antony will be able to use his content design skills to remove some of the mess in my writing, to make it clearer and shorter for future users.

If you’re interested in how this progresses, talk to the head of profession for your area. If they don’t know how to get involved, then they should talk to the capability lead in their people team, who will be plugged into the work of the Capability framework Design Council. And if all else fails, drop me a line on LinkedIn – and I’ll try to fold you into the work.

I hope you find this useful, and best of luck to everyone who tries to take this work forward. Please leave comments or ping me – I’m really keen to hear what you think.

Marty Cagan’s “Transformed” workshop – some key takeaways

So last Monday I spent a fascinating day with about 50 other senior product folk, being taken throught the first version of a new workshop/book “Transformed” from Silicon Valley Product Group. It was the first time Marty Cagan had run this workshop, and there was definitely more to fit in than there was time for – but it was still all really great stuff.

The inspiration for the book seems to have come from a pretty universal mental rollercoaster after attending the “Empowered” workshop. It turns out former-boss Miranda and I were not remotely the only people to get on a video call with Marty afterwards to say “that all sounded great, and we’re a big organisation who are definitely doing ok at becoming more agile and product-centric, but we’re still miles away from that! How and where do we start?”

“Transformed” is not the complete answer, but it’s definitely enough to give hope. And, like so many of these events, being in a room full of other people going through the same new challenges and sharing their own practice gave me enormous heart. I definitely felt like I was no longer alone.

I don’t want to basically blab the whole day, but here are a few notes I’ve made and shared with internal folks at GDS.

The premise

Fundamentally he talks about changing how you build (move to continous delivery), how you solve problems (continuous discovery) and how you decide which problems to solve (product strategy). This needs organisations to make sure they’ve got competencies in product management (NOT product ownership the Scrum role), product design, product engineering, and some other supporting roles. It also means building proper product leadership to enable the teams through coaching, staffing and making sure the right strategic context is in place for teams to be truly empowered (but also have the right guardrails in place). He also talked quite a lot about creating Product culture and principles. The latter part of the day was “and now…how do you assess your current organisation, create a plan for getting where you want to be, and overcome the objections along the way”.

Interestingly he also said it was important to focus on principles, and not fall into a temptation he sees across Europe of turning those principles into a process – which can become an end in itself. He was quite anti telling us any process at all, in fact. So that’s us well and truly told!

For practitioners

(The latter part of this list contains familiar points from “Inspired” or “Empowered”, but they’re still worth repeating)

  • Probably don’t describe where you want to get to as “product-led”. That’s sounding like we know best and we’re here to take over – Marty prefers “the product operating model”
  • Lots of product writing is from the startup perspective, when you have little to lose. Enterprise organisations have lots to lose – be sensitive to this
  • Marty was really explicit about separating out mission and vision, when a lot of literature blurs them together. He used Trainline as an example: their mission was something like “enable people to make greener travel choices”. Their vision was a four-minute video showing the sort of experience they were hoping to create that would get them there. It didn’t get into specific features, but every team member who saw it would know the sort of thing they were headed for to realise that mission
  • Marty’s observed that remote working seems to be OK for delivery, but isn’t working so well for discovery – he thinks teams that get together f2f are more successful
  • Spotify say that 100% predictability means 0% innovation
  • There’s a HBR study that says that only 10-15% of our original ideas have the benefits we expected (i.e. “work”) so discovery to validate them is important
  • Every company has more opportunities and risks than they can fully address – it’s all about choosing. Spreading your teams super-thinly and trying to lightly please everyone is unlikely to have the impact you’d hope for
  • PMs have to show they know the customer, the data and the industry in order to be trusted by the organisation – it would be negligent for leaders to let you have free rein until you can show that. Do you?
  • Empowered software engineers are the most important thing you can get – your job is to give them all the context they need to be empowered.

For leaders

  • You need to change how you deliver software, how you solve problems and how you decide which problems get solved.
    • The first – continuous delivery – is probably easiest because it’s largely within the control of the technology organisation.
    • Changing the “how we solve problems” through continuous discovery is hard, but thinking about “time to money” rather than “time to market” is a good starting point. It’s not just about shipping that idea, but shipping an idea that’s valuable.
    • Creating better evidence-led product strategies, that contain their own work to validate assumptions and become smarter, is harder still.
  • CEO backing is the biggest factor in whether a move to product operating model will succeed
  • Keep coming back to the principles, don’t let process take over – relationships with finance and any PMO will change lots and their work will need to change lots as well, be transparent about that and don’t let process settle in before those changes have happened
  • Remember Steve Jobs’ takedown of John Sculley’s Apple – “the disease was thinking that having a good idea was the hard part, and the rest was just execution”. How will you share the evolution of ideas and the learning that shapes that?
  • You are only as good as your weakest PMs, so remember to keep coaching
  • Don’t tie performance management to OKRs, otherwise nobody will be prepared to work on anything risky or hard
  • He talked about the impact of generative AI, and thinks it will make prototyping – where risks can be managed – easier and faster, but production code will take a lot longer. He’s written an article called “preparing for the future” that goes into this in more depth.
  • This new culture and way of working is a product in itself – start small with pilot teams, learn and iterate, but keep telling the story of what’s working
  • The product operating model is fragile. A new senior manager who doesn’t buy the idea of empowered teams working on problems, and wants to be specific about what they’re going to get, can destroy years-worth of work on culture in just a few months. Finding ways to make this resilient and ensuring the story is easily told is hard. It’s also emergent practice, and the last chapter in the book.

What am I going to do next?

So what are my own next steps?

  • I’m working on a survey of my PM community anyway, and I’m going to ask them about trust, but also how they understand their responsibilities to leadership
  • I’m going to think about other ways to regularly temperature-check “trust” and “empowerment”.
  • I’m also going to ask about whether they feel they truly know the users, data and policy context – triangulation points on the trust and empowerment ideas
  • I’m also going to ask where people are on the missionaries/mercenaries scale and think about leading indicators of teams becoming more like the former
  • I want to delve into the collective responsibilities of trios and how well that’s working
  • I’m going to pick 2-3 teams I think I can helpfully influence them and their leadership without risking delivery, and where there’s going to be a story to tell, and see if we can build trust in this model
  • I might also borrow some of the ideas Which? use to support this – rotating engineers through the discovery part, and rotating who presents at the team checkin
  • I’m going to get myself copies of Anne Duke’s “Thinking in Bets” and Tony Fadell’s “Build” which are both long overdue. I need to reopen my old Steve Blank books and read up on him talking about principles over process.
  • Marty’s kindly shared a few other bits with me that I’ll be thinking about too.

All of which will keep me very busy.

Further reading/social whirl

So that’s my own personal take. There are also other good summary posts on LinkedIn from:

  • Nick Jemetta – ex-Argos, now a Product Coach
  • Paulo Gaudencio – Product Ops lead at Cofidis
  • Tobias Freundenrich – ex-Xing, now also a Product Coach, who knows a couple of people from my Cimex days
  • Marty himself – where you can see a lovely photo of the back of my and Rico’s head, captured beautifully by either Chris Jones or Jonathon Moore.

I got to meet some fabulous other people too – Monica Viggars, some lovely long-suffering folks from MOD that I’ve met before, and the Crisp gang (Mattias Skarin, Marcus Castenfors, Matthias Holmgren, Jan Grape). I’d never heard of Crisp before, but they were product coaches to Spotify! Marcus also co-wrote a book called “Holistic Product Discovery” that looks worth a read.

Nick Jemetta also put me onto Graham Reed who runs an interesting-looking community called “Product Mind“, looking at the mental health of our practitioners. We do a stressful job, and often feel quite isolated or caught between impossible choices, so anything I can do to help people as part of that feels like a good thing.

All in all, a brilliant day. Different from what I expected, but definitely one that opened a new chapter in what I do.

The trap of ‘the 18 month roadmap’

Yes, I know what some of you product purists will be thinking. But this isn’t a snarky post about how stakeholders want Gantt charts really. It’s more about how easy it is to become accidentally stupid and switch into ‘feature team’ mode, even if you’ve been doing this for a really long time.

As mentioned two posts ago, I’ve largely handed over my Head of Product role to my Civil Servant successor. They’re doing a great job, and I need to give them the space to do it without feeling overlooked – and to do it the way they need to. I didn’t get everything right, because I was setting up a profession at scale for the first time, and in some places it’s a good opportunity to fix some lumpy corners. Meanwhile, I’m being kept on until the end of December doing what was referred to in the 90s as “special projects” – keeping me busy and around until the end of my contract in case something crops up that needs my memory.

The thing that’s keeping me busy is setting up a new multidisciplinary leadership team that sits across several of our products which were previously a bit siloed.

We’ve got a companies/contacts/interactions/events database platform thing; we’ve got a data analysis/visualisation platform; we’ve got some quite specific workflows around particular types of triage; we’ve got ticketing systems; we’ve got a public-facing platform ( that does data capture; we’ve got bulk email tools; we’ve got a SaaS event management platform; there’s a suite of marketing tools etc etc. All of these things are part of what you might call “CRM”, but they’re not necessarily seamlessly integrated for our users – and we probably send staff around the houses between teams a bit more than we should when they’re asking us how to get something done. And so sometimes stakeholder say “perhaps we should just go and buy [insert any major CRM vendor here]”.

So we’re creating (for a while) a CRM Leadership function, that’s taking a holistic look at all these journeys – through the lenses of data, design, business, product, architecture etc. We’ve also got a CRM subject matter expert on the team, who’s worked with all the big off-the-shelf tools, to make sure we’re not doubling down on our in-house builds unnecessarily.

The team was formed about six weeks ago, and I spent the first while trying to define and refine and priorities our OKRs.

  • We’re having to define what CRM means at DIT.
  • We’re having to build a roadmap that sits across all those products
  • We need to help shape each team’s missions for Q4
  • We might get into defining what we most need to learn from trialling any COTS solution
  • We also hope we can do a bit of “showing what good looks like” when working on complicated cross-portfolio and cross-product work.

We need to do the roadmapping work in consultation with the individual teams of course. We want them to truly own their problems, and feel empowered to solve them in the best way possible. They’ve also got people on their teams who know what’s possible these days – whereas I still really only think in old-skool relational databases. So that means trying to follow the Netflix model of “leading by context”. Not defining the solution, but making sure teams know enough about what matters that they can’t do something completely leftfield.

The teams also truly know their users and working patterns, fragmented as they are across the UK and the globe, so are best placed to know whether any new process ideas are likely to land…as well as being able to quickly and cheaply test the ideas behind them.

And, of course, they already have their own roadmaps – for the next quarter or two. Some of which was based on really good user insight.

But the catch in the second of my key results was something quite specific. It wasn’t just “a roadmap”. It was “an eighteen month roadmap”. As I mentioned in the title of this post.

So why do they want that? Isn’t that just a Gantt chart?

Well, yes and no.

You see, there are some understandable worries about the way I’d normally be doing this – which is how I regularly advocate for people to do it when training. I love the “now, next, later” roadmap format. I love Roman Pichler’s goal-oriented roadmap. But I can also understand the concerns of people who’ve previously been burned by MoSCoW prioritisation when working with traditional IT suppliers – that you might as well assume anything that isn’t in your Must list just isn’t going to happen, so you put everything in Must. Similarly, I can see how a roadmap like this can be read as “now, probably next, never”. Particularly when priorities change and there are a lot of stakeholders you had to tell about it – some people might miss the memo and that erodes trust.

So the challenge is to create a roadmap that’s more of an 18-month-long worked example – given that things will undoubtedly change, and teams will be making decisions about this long after I’m gone. They’ll also be finding out some of my assumptions were wrong or based on sketchy inputs, long after I’m gone, and that has to be an integral part of the process. But that also needs to be part of the playback to our stakeholders as well – this is not a commitment, this is the first iteration of a joint process.

But a roadmap like this involves hard choices. There are some vocal user groups who have problems – but fixing those isn’t necessarily the most urgently valuable thing to be doing now. There are software changes we could make that *we* think would be hugely impactful, but there’s nobody in the wider organisation that can do the process change needed. There are also things we could do which would be hugely valuable (and which both our users and stakeholders ask for), but because a set of suppliers all did things differently before they were inhoused, and key decisions about a converged process haven’t been made yet, sow were are blocked. And of course, there are features we’ve built that sit underused/misunderstood, or where we find out during research that people are using the same word to mean different things – or represent completely different mental concepts.

So the roadmap we create today is a symptom of that context.

I’ve spent a lot of the last week looking at the things we could be working on, and documenting two things:

  • what I think the value/priority is, and the questions I think we need to be asking next to be more sure
  • writing down the underlying principles that led me to those decisions, so that we can update the roadmap if they change.

I’m due to present this roadmap to our SMT in a few days time, and the introduction is going to be quite a few slides of “the context as I see it, and therefore the underlying principles that emerge”. I’ll be talking about the readiness of various transformation programmes, the levels of business ownership around known pain points, capacity constraints around must-do technical tasks like migrations etc. This is also going to lead into some prioritisation principles like:

  • Build things for people who can make change happen
  • Developers are expensive, so if users are complaining about a missing feature that already exists, then comms about intended use should be tried first
  • Backoffice staff having to retype things *is* annoying and wasteful, but given development constraints and the bigger goal of economic prosperity we should concentrate on making sure our staff working face-to-face have everything they need to to focus their work…unless the backoffice processes are blocking that.

As I seek feedback, I’ll find out that some of the landscape is wrong and I’ll have to replan. As I talk through the principles I’ll realise that they need to change.

But late last night, as I was thinking about all these artefacts I’ve created to support my first draft of an eighteen month roadmap (slightly against my will), the penny dropped.

I’ve written a product strategy.

How long have I been doing this job? How did I not spot this?

But someone asked me for an 18 month roadmap, and I blindly got on with it, and didn’t spot that actually we needed a product strategy, with a candidate roadmap to come out of it.

Be careful about the words your stakeholders use. They can lead you into all sorts of traps, and approaching problems from completely the wrong end.

(Of course it may be that I’d still have had to do all this work anyway, and I would have been Totally Making Up my product principles if I hadn’t been staring at those really specific prioritisation tradeoffs, but anyway.)


I realised that some of the choices the teams and I were trying to make were hard because we weren’t aligned around the overall context. I could see the value in solving the problems they saw their users dealing with. There was a lot of junior people doing quite a lot of retyping. But, given some of the big strategy documents I’d been reading, that didn’t feel urgent. That fixing this user problem, but delaying a bigger goal, might not be seen as the right tradeoff.

To fix this, I created a set of ‘even over’ statements to discuss with the team. Things like:

  • We will support our workforce to make the most of their face-to-face contact with companies because that is what will have the most economic impact, even over reducing the back-office admin that we know feels unnecessary for a few more months.

The team might tell me I’m wrong about some of these. The wider stakeholders might say “no, actually, efficiency savings are key”. But at least we’ll get clarity.

I’m also trying to make sure we live by Janna Bastow’s maxim that “your roadmap is a prototype of your product strategy”. We’ll find out how right the strategy is by looking at the roadmap, and vice versa. And we’ll user test the product strategy with everyone from end users to senior stakeholders. Whenever something doesn’t look right, either in a goal or feature people were/weren’t expecting, or in one of our principles – we’ll then work out as a team which thing we need to go back and change. It’s a great way to make the thinking explicit – and fallible.

An Approach to People and Succession Planning

Vacancies are weird things. They sit their on your org chart, and you keep trying to find the right people to go into them, but recruitment remains hard and so you tend to prioritise the (thankfully few) leavers you’ve got and the key initiatives that really need a dedicated person.

Of course, your profession is not alone in this. If you were to hire a product person, you know there probably wouldn’t be enough developers for them to have a meaningful team. Maybe there aren’t quite enough designers or user researchers either. And so, over time, your aspirations for the work you’re trying to do kind of shrink to fit what’s in front of you right now and who you’ve got. You organically manage to start new things, but it’s a bit of a squeeze, and sometimes feels like you’re artificially splitting an existing team in order to enable the new initative.

Where I work we’ve got a lot of people in ‘Senior Product Manager’ roles. They’re all on their own career journeys of course, and developing in different areas – and working on a wide variety of projects. But it’s always felt a little fragile that we only had senior staff – and weren’t developing a pipeline of new, more junior, product managers. However, this does mean you have to have problems that are right for more junior staff to work on – the right sorts of stakeholders, the right level of risk, the right balance of strategic and tactical user research needed. And for a long time I didn’t think we had those ‘to hand’. Which meant the problem slightly persisted: our senior folks were busy on big problems, in a fast moving environment, and scoping out something nicely doable by a more junior PM felt kept slipping down the to-do list.

It takes something of a crisis to make you rethink a situation like this. To say “we need to take a bigger look”. And in my case, the crisis was that – over the course of about a week – I realised I was looking at the arrival of potentially four new Senior Product Managers within the next few months, who’d all need something meaningful to do. Especially as they were proper civil servants, not contractors.

That was going to take some pretty radical thinking. I couldn’t just reorganise a few contractors. After all, some of them had very specific domain knowledge , or the products they were working on would be out of active development by time the civil servant got up to speed.

So I created two tools to help with this:

  • A map
  • A gameboard

Sadly, showing you any of this is going to be really tricky, but hopefully I can walk you through what I did.

The Map

I started by thinking about all the things people had ever asked us to work on. Initially I mapped them out as tiny yellow postits on my desk. And then I tried to connect them to what the problem was that we were trying to solve. I also started adding in any looming crises, migrations, technology issues, or known pain points. This enabled me to start forming some interesting clusters: for example “how do we better triage clients” and “how do we determine eligibility” and “we need to replace our ticketing platform” all felt like very related problems – probably one person’s job.

But now I’d said that this was probably one person’s job, I had to decide what sort of person.

I realised my map needed a vertical axis – how senior the person needed to be in order to solve the problem.

Fixing the way we take inbound queries, deciding if they get digital or personal support, and routing that to the right person – that’s definitely something for one of our most senior Senior Product Managers. A proper gnarly problem, technical and policy issues, stakeholders in different directorates etc. Job done, yes? Sadly not.

The only catch was that they couldn’t start on it yet. Some of that work is blocked by a higher-up problem: getting standardisation on the business processes in this area. And the initial mustering of stakeholders and leading them to agreement around the need for change is something only a Lead PM really has the skills to organise.

Meanwhile, if we want to divert some of those users to more online support – keeping face-to-face contact focused on the most valuable businesses – then someone needs to be creating the content journeys for that. Which is definitely something a normal PM could be doing – assuming a different Senior PM had engaged with their stakeholders and set out what that content was. And that might in turn unblock some opportunities for an Associate PM to look at optimising content or discovery features. So I could also look at all the other things we might meaningfully get junior people to learn from – if only someone was empowered to shape that work.

And all this is full of moving targets. There are platforms we suspect we’ll have to migrate from in about a year’s time, including changing our hosting provider away from GOV.UK PaaS. Some of those might mean thinking about ‘how we design and measure campaigns to make them more effective at driving online traffic to a wider variety of our services’ – which would allow a more junior person to look at ‘executing a specific campaign well’, but also depends on ‘defining our offer and candidate journey for each user groups’.

I realised three things at this point:

  1. I was building a vast network of problems and problem clusters, with a vertical axis based on seniority – covering things we were doing, might have to do, and couldn’t do yet.
  2. How I chose to cluster the problems was a pretty key decision, with implications on a lot of other team topologies
  3. I was going to need something more than postits on a sheet of A3 if I was going to keep track of all this

So I started building this network in Invision, using the connection tools to keep track of links between my postits as I moved around the clusters, and decided how senior those clusters were.

I can’t show you the detailed diagram (although I plan to ask) but you can see the overall shape of it here:

Yeah, sorry, it’s super fuzzy.

The grey boxes are “nouns” or tasks. We do have some ‘just do it’ things, or where we’re pretty sure that we know the most likely approach, and that’s part of the setup. But we can give them context by tying them back to the overall problem a product person can ask – the white boxes.

You can also see the dependencies mapped between them in the arrows. Sometimes I even found circular loops that I had to break.

And you can see the vertical hierarchy of where I thought we might have work for PMs or APMs…if we had the time to unblock it.

There are also annotations around whether things are product problems or service owner problems, opportunities to empower junior staff, where things are critical, or where we might have skills gaps/other blockers.

I showed this to someone the other day and they described it as “the org chart”. But it’s not. It’s a map of all the org charts we could potentially ever have – if we had all the people we could ever need. But we don’t have all those people – so we have to be strategic about where we focus. We need to make sure that our leads know where seniors will depend on them to create clarity once they arrive, and seniors need to know the questions that matter if we’re imminently going to be bringing in PMs to work on smaller product problems. So having created this map of all the possible options, we need step 2.

The ‘game board’

I don’t mean that this is a game. It’s deadly serious. But having worked in interactive entertainment, I know that shaping the way you explore the problem is critical. You need a toolkit that shows you the moves you’re able to make, and which ones you can’t. You need to simplify the map to make tangible and meaningful choices. So thinking about these things like you were designing a boardgame is a useful approach.

Going back to my original problem: I potentially have four new senior product managers starting, and I need to work out what they’re going to do.

Based on my bigger map, I can now pick a subset of ‘senior PM’ problems that are either in progress, ready, or (with the correct Lead PM focus) could become ready within the next two months. I can lay those out in powerpoint slide as a similar but simplified map – and save it as a template. (I’m paranoid, I’m even going to duplicate it and turn on “hide slide” to stop me breaking it by accident)

I can then look at all the people I’ve got available – their strengths and interests – and put them on the side of that map against their grade. I can now try out all sorts of combinations, just cloning the slide each time. The title of the slide says what factors I’m considering.

I can look at future options – where do we need person x to be developing, and what problems could we have ready for them in a year? Again, it’s just a cloned slide and some comments to say what I’m thinking. Possible long-term flight risks if we’re not able to keep challenging them? The same.

I can then sift the most useful options for how the ‘game board’ plays out to work for our people and the problems – and start talking to others about it. Could the Leads get these things ready in time? What happens if that contract gets extended? Would that allow us to focus key staff on something more valuable?

Net result

By mapping out all your problem spaces, seeing how they cluster together, what blocks them, what they unblock, and what level of seniority each problem cluster needs, you’re in a position to start looking at possible futures for your product function and team topologies. You can choose the areas of focus from within this set of options, and match them to the work you think would be most valuable for your people to be doing next.

The editorial temptation to add “quickly” into that previous paragraph was quite strong. It’s not quick. This is quite hard work, you’ll need to block out time for it, and come back to it repeatedly – both to validate it when you make your first plans, and when you come back to check how the landscape has moved.

But I found this such a useful approach that I thought these initial steps – and particlarly hat it’s a two-stage process brought on by a crisis I hope none of you face – might help kickstart your own ways of thinking about it.

Do please let me know what you think in the comments!