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.

6 thoughts on “Nudging along the government (DDaT) product management career framework

  1. Pingback: Festive fortnight notes: 18-31 December 2023 | Neil Williams

  2. Pingback: Fortnightnote – 31st December – Verygood-byes - LeaningForward Blog

  3. Pingback: Weeknote 7th Jan 2024 – End of One Era… - LeaningForward Blog

  4. Pingback: Weeknote – 3rd Feb – Stockpiling - LeaningForward Blog

  5. Pingback: Weeknote 3rd May - Readiness - Leaning Forward

  6. Pingback: Weeknote+VAT - 6th May 2024 - Getting Going - Leaning Forward

Leave a Reply

Your email address will not be published. Required fields are marked *