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.
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:
- 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.
- How I chose to cluster the problems was a pretty key decision, with implications on a lot of other team topologies
- 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?
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!