Episode 4 of Good Product Management brought to you by Scott Colfer.
Previously on good product management: we uncovered principles for ‘product-thinking’ that can be used by anyone to improve the values of their products and services; found out how I learned the most important principle is being passionate about problems and flexible on solutions; then defined what it means to be a product manager. In this episode we uncover:
2015-ish. Cabinet Office asks the Treasury if it can pay attractive salaries for ‘digital’ folk. Treasury says ‘yes’, but ‘you need to show the roles exist in the market, and the people in them have specialist skills. Or words to that effect. The Cabinet Office’s ‘Government Digital Service’ had to define the ‘specialist digital’ roles needed by the Civil Service, prove that they exist in the marketplace already, and justify the need to pay them more than a traditional Civil Service salary. All according to someone involved in the project.
This sounded promising so I got involved. Go back in time to 2015 and there was no career pathway for product managers in the Civil Service. Use of the role was inconsistent. It was difficult to get promotion beyond Product Manager. Senior Product Managers were contractors, for the most part. Lead Product Manager roles were rare. Head of Product was new in the few organisations that had one. Here was an opportunity to work with peers from across the Civil Service and improve things. Awesome.
There was an attempt to do this late 2015/early 2016 but it petered out. Then it restarted in the Summer of 2016, this time with an external organisation leading it. We had a deadline of December 2016. Things got moving. So it was that I found myself meeting a regular cast of peers every few weeks in the second half of 2016. Zoe, Alex, Will, Ross, and myself, and others. Facilitated by an external organisation. Led by GDS. We defined the skills required of product managers in government . . . but first we had to agree our role title.
The perennial question ‘product owner or product manager?’ came up early on. The answer was swift: we agreed the role is ‘product manager’. Product owner is a narrow version of product management within the Scrum framework. It focuses on the tactics of helping a technology team to develop software. Product management is the broad role in which we’re responsible for every aspect of a product needed to meet the needs of users, and our organisation. This discussion helped to align our thinking about the scope of the role, and to define the skills needed.
We received a final draft of the skills, pretty close to what you see below, at the end of 2016. I started using them from January 2017 and they were a huge improvement on what went before. I had greater confident in our recruitment. I could open our first campaign for permanent Senior Product Managers. This was open to internal candidates, providing the first chance for promotion.
The skills we defined remain online and in use as part of the UK government’s ‘digital, data, and technology capability framework’. They are:
We should always learn and improve. I’ve used these skills to recruit dozens, interview hundreds, and sift 1,000+ product managers. I review and retrospect following each campaign and have incrementally tweaked how I use the skills. Here’s how I personally define the skills after 3-4 years of iterations.
The two core skills are product strategy and product tactics. They’re called ‘strategic ownership’ and ‘product ownership’ in our original definitions. All the other skills are facets of these two.
A strategy is a goal (expressed with a clear outcome) along with a plan for how to achieve it. Product management is about improving the value of a product for its users and your organisation. Product strategy is the outcomes you want for your users and your organisation through your product, along with a plan for how to achieve it.
Tactics are the specific steps we take to achieve our strategy. Product tactics are the individual hypotheses we have for improving the value of our product, taking us closer to achieving our strategy.
Strategy has no value if it’s not brought to life for the people who will actually put it in place. Likewise, a tactical team that can ‘get shit done’ but doesn’t have a strategy will become a feature-factory. Product managers must be strategic and tactical. To go with some broad stereotypes (apologies), what I’ve noticed is:
Some product managers wish to embed in a software development team and prioritise and accept features. On the flip side, some product managers want to work with ‘the business’, and hand-off to a product owner who works with the people building the thing. Both of these approaches are valid and work in many situations. In government we’re looking for the type of product manager who can lead both strategy and tactics, so that we can reduce hand-offs and make decisions.
There are important facets of product strategy and tactics that it’s useful to pull out. Over time, I’ve refined and conflated the original skills.
We should be passionate about problems but flexible on solutions. People talk about problems through solutions. We can fall in love with solutions. Product managers need the ability to flip-this. Focusing on your users’ problems gives you the flexibility to make useful changes to your products and services. It’s OK to have organisational goals as long as we understand that they’ll only be achieved when they also solve users’ problems. If we find a problem we need to find out if it’s urgent enough, pervasive enough, and valuable enough to be worth solving.
This is an aspect of problem-focus. But in 2020 it remains important that ‘user-focus’ is an explicit skill. We’re still sometimes challenged that user research is an expensive, ‘nice to have’. We can be pressured to skip it. One aspect of the skill is an ability to commission and support research to understand users. And use insights from this research to improve the value of the product for users and the organisation. Another aspect of the skill is the ability to ensure research happens despite hostility towards it.
I’m largely to blame for this one. I made the case for this skill because it seemed the largest gap in product managers’ abilities. This remains the same in 2020 in my experience. Based on sifting and interviewing candidates from all sectors, it’s the skill that most people struggle with. Understanding the point of each phase of the product lifecycle. What ‘success’ looks like. How we know when we’re ready for the next phase. And what this change will mean for us, our strategy, and our team.
Product management expertise can be skewed towards developing the new. Sometimes we need to improve the mature. There’s a skill to prioritising new product features against new features of the service wrapper, paying down technical debt, and looking for new opportunities for growth. Incidents will happen and need resolution. All whilst you have a user group with much higher expectations of your product. This is a subset of product lifecycle but useful to pull out on its own.
This is interesting to me. This was included to check that all ‘digital’ specialists were working in a particular way.
I’m going to stick my neck out and say that, for me, working with agility means two things. One: focus on outcomes over outputs and release stuff early and often to check you’re getting the outcomes you want. Two: empower colocated, multidisciplinary teams to do this. One is led by product managers and two is led by delivery managers. Following this chain of logic, half of working with agility is covered by being a product manager. The other half we’d expect to be led by a delivery manager.
The way I’ve found this to be useful is as a space to test the skill of understanding how to work with others. Can a product manager create a bank of hypotheses for improving the value of the product but support and empower the team to figure out how to test the prioritised hypothesis? Can the product manager focus on product strategy and work with a delivery manager who leads workflow strategy (team performance, constraints, dependencies)? Can the product manager help a team to release improvements to our products early and often, to check that we’re getting the value we expect? And do this through iterative cycles of collaboration, delivery, reflection, and improvement? This provides space to learn how the product manager works in context and in relation to others, rather than assessing them in isolation.
Some original skills don’t appear in my suggested improvements. They were already classed as ‘desirable’ rather than ‘essential’ and I’ve found further reason why they’re already covered elsewhere:
I hope these skills are useful for you. I’m aware that I’ve barely scratched the surface of talking about them but equally aware that this episode is long. So a future episode will go into more detail on the core skills of product strategy and product tactics, jumping off to touch on the supplementary skills too. Before that, I’m going to talk about behaviours of product managers. Stay subscribed for both.
Let me know - do you have your own set of skills you use? - do you have experience of using the government skills list above and have opinions about them? - do you think there’s an important skill that’s overlooked? - do you have tips on how to use skills like this to make them more helpful?
Thank you for subscribing to this series of emails on good product management and for reading this episode. If you’ve found it useful or interesting please consider sharing it with someone else and sticking around for the next episode.