What does good product management look like?

So, what does Good product management look like?

This framework is an evolution of something I worked on at Sky. an overview of what’s expected both from individuals and teams.

It’s very high level. There’s a whole other level of detail as you start to explore what good looks like for each of these boxes; and both the language and the specifics of that will be different for different organisations. I give a few notes on how you can use this, and bring it to life in your organisation, below.

What you do

In the top half of the framework there are three main ‘buckets of activity’. I’m always suspicious of alliterative groups! But they happen to be the Three D’s..

Direction People need to know where they’re going; and why; and what success looks like. The processes that give this clarity are things we all talk about: Product Vision; Strategies; Outcomes; Roadmaps. There’s lots of different ways to do them - but they all have the same objective: to set the Direction of a product or portfolio. This isn’t something Product managers do on their own: like 90% of things PMs do, these are collaborative efforts. But if there’s a lack of direction, or - just as important - a lack of one, it’s for the Product leader to fix.

Discovery Avoid at your peril. Again, there are different ways to carry out a discovery process - but however you do it, the ambition is the same: define and solve problems; test ideas; and minimise risk and wasted effort by seeing if something has a good chance of actually being used and can be built (for legal and regulatory reasons as much as technical). Different companies, types of problem, and org structures, all require different ways of working and different outputs. What matters is not how you do it; but that you do it. Every time.

Delivery Ironically the bit of product management that tends to get the least written about it is the nuts and bolds of actually building and shipping products. The day to day processes of giving clarity over requirements, making close-up prioritisation decisions, getting clear about what’s good enough to ship - and, harder, what’s not; and getting together whatever’s needed to bring your product for feature to market. This is where the difference between ok and great happens.

It’s important to stress that this isn’t a strict sequential flow of activity. There’s no arrow that flows from right to left. Discovery can inform your Direction, for example; and the lines between Discovery and Delivery can get blurred. But the point is all three have to happen in order for the team or individual to be effective.

How you do it

In the bottom half of the framework are a number broad capabilities. I’ve grouped them together in pairs, because in reality they have to go together.

Ownership & Accountability Bad product managers think ‘Ownership’ is about entitlement. They have the title of PM and the ‘ownership’ of a specific product or feature and they think they get to call the shots. They don’t. Ownership for PMs is about responsibility and accountability. They help their engineering and design teams do great work, and get the credit for it; but the PM knows they are on the hook for whether or not it’s a success. They see their job as ‘whatever it takes’ not just what’s on their job description.

Communication & Collaboration It’s important to see these two together. A large part of the communication needed from Product Managers is to ensure that the right people are involved at the right time in the right way. This is about dialogue, not rhetoric. It’s about listening, not just crafting docs and decks. It’s about working people in a way that both brings clarity; and builds trust.

Analysis & Decision making Decisions are the fuel that drives great products and effective delivery. Sometimes you are making decisions yourselves; more often you are bringing the right people together to make that decision and/ or presenting the information to help others make them. Decision-making is a skill you get better at with practice. But, the fuel for good decision making is structured analysis - gleaning insights from a combination of data and annecdotes; not jumping to conclusions; being aware of your own biases. Similarly, analysis is never an end in itself. It’s there to enable decision making, not to avoid it.

How to use this..

Like I’ve said, this is very high level: and the real detail comes one layer down. This is where you actually make it your own.

But the benefit of a relatively simple framework like this is that it creates a common language for individuals to assess themselves; and for leaders to talk to their teams - and their reports - about strengths and opportunities to improve.

No individual or team will score 10/10 in every box. But that’s what makes our role so interesting: we can all always get better.

Those looking to build a sustainable product capability rather than just a team of individuals can this to life - putting it at the heart of your recruitment; job descriptions, levelling guidelines, training, promotion and appraisal processes. Get in touch if you’d like to know more about how to make that happen.

This is a draft bit of an eBook that I'm writing for later this year. Subscribe to my newsletter: The Ockham Bugle if you'd like to read more like this and get a weekly helping of other product management goodness.

Oh - and why Ockham? It's the hamlet where I live that was also home to Ada Lovelace, the first 'computer programmer'; and William of Ockham - who told us to always take the simpler of two options (Ockham's Razor). That mix of innovation and simplicity is something we can all aspire to.