Against the standardisation of product management
George Stephenson pioneered a standard gauge of 4 feet 8.5 inches for railways with the Liverpool & Manchester line in 1829. In 1845, the Royal Commissioner recommended the standard gauge, and in 1846, the British Parliament passed a bill requiring all railroads to use standard rails in the future. Before that, railway lines had many different widths, but as the standard was exported from Britain to Europe and the United States it allowed railways to work as interconnected networks rather than individual lines.
Standardising the track gauge made train cars interchangeable and made railways interoperable. This brought commercial benefit to railway manufacturers and convenience to passengers. It’s why you can get a single train from St Pancras to Marseille or travel by train from New York City to San Francisco, if you’re into that sort of thing.
Although railways standardised track gauge, they didn’t standardise engine design. Between the 1820’s and WWII, steam engines increased rapidly in size and power. Being able to innovate led to experiments with stronger materials and new technologies, better cylinder design allowed for more efficient fuel usage and improvements in lubrication which increased running time. Without innovation and improvement, it might never have become viable for trains to travel such long distances to realise the benefits of interoperability.
So here’s the lesson: standardise where interoperability is required, otherwise optimise for innovation.
We should apply that same lesson to product management and beware of standardising the role in ways that prevents innovation. Product management is a highly contextual role and the demands organisations are placing on it are changing too quickly for it to become standardised.
However, organisations, sometimes unthinkingly, default to standardising things on the assumption that it makes them more efficient. If everyone works in the same way and uses the same tools, the assumption goes, then their outputs will be the same, which is more efficient. This might have been true when manufacturing steam trains, but it isn’t when tackling complex problems. As product manager KP Frahm, once told me, “Get effective first, then efficient. If you get efficient first, you’ll never get to be effective.”
This is the problem with product management capability frameworks, role-based skill descriptions, and standardised levels for what is expected of product managers; for organisations wanting to improve their product function – they seem like a good idea. They seek to standardise the knowledge and skills expected of product managers, which seems like it should improve the quality of product management. But those frameworks are built on the idea of interoperable product managers that can fit into a product team in exactly the same way as the product manager leaving the team, and carry on working in the same way with minimal disruption. Interoperability is great for physical systems like railway tracks and for digital systems like railway timetables. Without the ISO 8601 international standard allowing any computer anywhere in the world to exchange date and time-related data with any other computer, you’d probably miss that train to Marseille. But human beings aren’t like that. They are unique. And trying to make them interoperable is a bad idea.
The lesson of the railways is true for product management. Making choices about what to standardise and, just as importantly, what not to standardise, is important for optimising performance of an entire system. A product management function needs to have some things standardised, where there is a need for interoperability, but product managers need to have non-standardised freedom to respond to change and innovate in how they work. Without this, product managers will not be able to manage products, they’ll simply be building the same railway as everyone else.
There are better ways to improve the quality of product management in an organisation. There are ways that focus on effectiveness over efficiency, ways that allow product managers to develop areas of specialist knowledge in economics or payment systems or behaviour change techniques or network effects or marketing, ways to support and coach product managers to lean into their uniqueness.
No two product managers should be the same, and they shouldn’t develop the same product in the same way. If they did, what would be the point of product managers? The point should be for each product manager to bring their own knowledge, skills and experience to their role and use them to tackle complex problems in unique and innovative ways. The point should be for organisations to maximise innovation in product management as a competitive advantage. The point should be for the discipline of product management to evolve at pace in a changing world.
Weeknotes 432
I did:
Consequences
Did you ever play that game where everyone writes words on a piece of paper, folds it and passes it to the next person to write their words, and when everyone is done the story is read out. That could be a pretty accurate description of how work happens, but there’s more to it than that. How good the story is depends on the people writing it, on how well they know each other, what signals they follow to stay aligned whilst doing their bit. The more complicated the story, the more alignment is needed, but it’s worth it for story we get in the end. This week I…
- Added to our Theory of change so it aligns with three pieces of work that all add up to the change we’re trying to create.
- Did some scenario planning to look at how different options pan out and make sure we get to all aspects of the end state we’re trying to reach.
- Talked about a product toolkit of things like a roadmap, OKRs, etc., that product managers are well-versed in using, know how to introduce to a team, and use effectively. The challenge, of course, is that the team exists within an ecosystem of other people and teams that may or may not be willing to accept the product manager bringing in these things.
- Started planning some solution design work to tackle some some evolving problems. Then stopped myself when I realised we don’t understand the problems well enough yet (or what problems we’ll have in the future). Rookie error. So, next week I’ll bringing together what we currently know about the problems.
- Wrote up some thoughts on what others should know about what product managers do and how to work well with them.
- Saw some wonderful examples of people reaching out for help and tackling problems together.
OKRs are really simple but…
Got around to writing up the intro to OKRs presentation I did back in October.
How does service design and product management fit together
Went to the good product leaders group session about how service design and product management fit together.
An interesting theme came out about how we think about the size of things, how the bigger the thing the more important it is, and how roles that work on bigger things are seen as more important than those that work on smaller more detailed things. This old hierarchical thinking doesn’t fit with roles like product and service design which don’t work at a single size level and have to be able to zoom in and out, and connect the big vision-y stuff with the small change stuff.
I’ve written before about how I think product managers and service designers can work together, but in a world where a service and a product are mostly the same thing, it doesn’t make sense for these roles to have mutually exclusive responsibilities, but instead to have complimentary perspectives. So, if I had to somehow try to explain a difference, I might say both roles create alignment for the team and coherence for the product/service, but product managers do it by zooming in and and out vertically, to connect strategy, goals, etc., and service designers do it by zooming in and out horizontally, to connect experience, process, etc.
I read/listened to:
10 things nobody tells you about OKRs
This looks like an interesting series:
What’s particularly useful about what Neil says is how it serves as a diagnostic for an organisation’s ability to work effectively. He says, “OKRs should be quick to write”. If you’re spending ages writing them it highlights a lack of alignment on organisational strategy and priorities. Fix that and OKRs will be quick to write. And OKRs demand data to be able report on key results, so not being able to report highlights the need for better data analytics. Fix that and OKRs will show if the objective is being achieved. I think this is where OKRs can be a tool for change, but only if there are used in this way by people with that intention. If they are implemented as just another goal-tracking method, then they are just more admin overhead, they won’t change anything.
My Product Management Toolkit
Read some of Marc Abraham’s My Product Management Toolkit book. It’s a quick and easy read with some interesting points.
Interventions
This study talks about how policymakers tend to treat enduring, systemically generated problems with limited interventions that are insufficient or inappropriate for the intended improvement. Of course, it’s only one study about something very specific so we should be wary of generalising the conclusion, but when have I ever been wary? It’s a pattern that shows up within organisations and in products as a result of most problems being wicked, novel and vague, and solutions usually being small, specific and constrained by time, knowledge and budget. We just don’t have the tools and techniques for making effective system-level changes.
My go-to example is the effect Uber had on drink-driving in the U.S. Researchers found ride-sharing reduces alcohol-related traffic fatalities by 6.1% and total traffic fatalities by 4%. Uber didn’t set out to achieve that. No product manager came up with an OKR to achieve that. But it still happened. That’s a product having a system-level intervention, and it was unintended. So, I think that’s the only way to work. Build products that have the potential for unintended consequences, and let those consequences emerge as people use them in real life.
Randomness
I listened to this podcast with Matt Ballantine, which completely ticked my boxes for thinking about working in non-deterministic ways.
I thought about:
What are your Whypotheses?
A simple hypothesis is like, ‘if this, then that’. It expresses a cause and effect that says if ‘this’ thing happens, then we can expect ‘that’ other things to happen. And the ‘this’ thing is usually something in our control. But hypothesis don’t explain why we chose the ‘this’.
So, a whypothesis asks, “Why this, if this, then that?” It tries to express intent beyond the simple effect we’re trying to have, to check that the ‘this’ isn’t seen as purely a means to an end, because of the unintended consequences isolated thinking can lead to.
Where do logic models fit
Where does the logic model for a product fit in the decision stack? I think it probably goes either between vision and strategy, if we want to order things by longevity, or maybe it’s better between opportunities and principles, if we think it’s more important to show that it’s foundational and supporting of how all the things above will work.
Whether you show the logic model using north star metrics or impact mapping (a favourite of mine) or theory of change (been exploring this more recently), the point is to help understand which aspects of the product that are within our ability to change, will lead to what outcomes (change in user behaviour) and impact.
Is it a product?
A product is a product if an organisation chooses to treat it as a product, and the best way to decide is to look at the problems it’s tackling. If the problems are well-defined, stable, and have predictable solutions, you don’t need product thinking or the skills a product team brings in tackle uncertain problems, and so don’t treat it as a product. If the problems are new, unknown and the potential solutions are uncertain, then a product team with the skills to apply product thinking are a good way to tackle those problems, and so the organisation should treat those problems as a product.
What is a product?
The object of the exchange process.
Provided by the supplier in return for something of equal or greater value.
Fulfils demand, where demand is a business opportunity.
(Baker & Hart, 1999. Product strategy and management)
A great product isn’t just a collection of feature. It’s how it all works together.
Marco Arment, founder of Instapaper.
If an asset does not create value for its customers and users, and for the company, then I don’t regard it as a product.
Roman Pichler
A product is a hammer, and a service is someone holding the hammer and hammering for you.
Patrick Quattlebaum and Jamin Hegeman