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.