Product management credo

Introduction

I work in software product management (a.k.a. digital product management). What software product management as a discipline is, or should be, varies a lot from person to person and, more importantly, from organisation to organisation. Today a solid foundation of best practices have emerged and been proven to work, yet they are often superficially acknowledged but not really implemented.

This page details a few things I hold dear when it comes to how product management ought to be practiced. I’m a good candidate for your organisation if it truly aligns with, or at least earnestly pursues, the principles I summarise here. Conversely, if those principles are neither applied not seriously considered, we might not have the same understanding of product management and the fit probably isn’t that good.

One thing to keep in mind though is that these principles vary in relevance and implementation depending on the organisation itself. They are worded from the point of view of a medium-sized product organisation with 3-15 small product teams in mind.

Outcomes

A product team is cross-functional and empowered with the pursuit of a long-lived outcome. Any outcome requires exploration and experimentation, leveraging the diverse skills available in the team. Chasing multiple outcomes from a single small team, or switching outcomes every few weeks, makes it impossible to get true return on investment in terms of learning through discovery and brings the risk of creating an organisation of dilettante teams.
Each team constantly explores the opportunity space. Continuous discovery is the keyword here, and anything written by Teresa Torres is valuable. The team maintains an overview of which opportunties map into which outcome they have looked at, typically as an opportunity-solution tree.
The available evidence is rated for what it is. Itamar Gilad’s confidence meter is a good illustration of how we need to consider some usually trusted sources of evidence as unreliable. Being efficient in finding additional evidence early on is a core part of the PM process, regardless of how the company chooses to tackle this.
Product outcomes are not business outcomes. The company pursues business outcomes, but product teams need to work on product outcomes which enable the business outcomes. As Itamar Gilad explains, the organisation aims to capture value from customers (business outcomes) in exchange for delivering value to them (product outcomes). Both types of outcomes are important and need to be aligned, but giving a team the mission of “increasing revenue 20%” does not root that team in the creation of value that will sustain the company’s value proposition.
Aligning product strategy and company strategy is what enables the right product outcomes to surface.. The head of the product organisation is responsible for this, as is the leadership of the company when it comes to defining a viable company strategy in the first place. Good strategy, bad strategy by Richard Rumelt is a reference book in this regard.

Roadmaps

Roadmaps should not be about delivery dates. Based on all the above, it’s clear that the goal of a product team is not to deliver feature X by date Y. So roadmaps should not be about feature delivery dates. Those roadmaps always fail to be accurate anyway. A roadmap makes should depict the plans of the team; therefore, applying healthy outcome-driven decisions, a roadmap should show which outcomes we want to work on at which time. It may be punctuated by known delivery targets, being the final delivery of a fully validated idea, or some experiments already slotted in in the short term, but it should reflect the fact that the team is not a feature assembly line.

The role of a head of product

I like to make this analogy: a product organisation is like a car and its engine.

First you need to assemble and maintain the engine, or the car won’t be moving. In product terms, that’s the structure of the product teams, the ways of working between teams and with the rest of the organisation, etc.

Then, since you have a car capable of moving, you need to set a direction to make it useful. You want to go somewhere, but where? Set a bearing and start using the wheel, pedals, and all its components to move it in the desired direction. In product terms, that’s looking at the company and its strategy, setting a global product strategy, and cascading this into each team’s objectives. Of course this is iterative as well, as you may get feedback on the way: just as a road might be closed and you need to adjust the plan on the map, you might learn important things about demand or feasibility that make you reassess which outcomes to pursue.

I think this covers the most important aspects of the head of product’s role. Most of the activities that are crucial in that role’s portfolio can be somehow viewed from the perspective of that analogy.

Conversely, this means that the head of product is not normally interfering in the daily work of the teams, except where a junior PM might need coaching or temporary support. If the head of product overrides roadmaps or mandates particular features being built, either they are pointing out issues in how the team’s PM is steering their team, or they are micro-managing, thereby disempowering and possibly alienating the team.

Some personal values

In addition to all the above, I need to highlight some core values I hold dear:

Product management is about doing, not selling. Of course I’m not referring to selling to customers here, but convincing stakeholders and managers through the sheer application of carisma, presentation skills or persuasion techniques. Aligning everyone as much as possible on how we plan and decide helps prevent the constant need to spend hours on a presentation just so that it flies better. It’s the raw content that must sell itself, not the presenter.
Similarly, product management involves negotiation, not deceit. Adjusting the message to the audience is one thing, letting everyone hear what they want to hear to build a fake consensus is unethical and ultimately counter-productive.
We’re humans, not robots. Yes, we must be successful. We need to deliver and capture value in a sustainable way to stay in business and grow sufficiently for investments to repay themselves. But from the investors to the lowest-level employee, everyone is a human being and deserves respect. Companies or individuals who forget that have no place in an ethical business, and I’ll only work for ethical businesses.

Some books

If those inspired you, we should work together:

Continuous Discovery Habits by Teresa Torres
Evidence Guided by Itamar Gilad
Inspired by Marty Cagan
Empowered by Marty Cagan and Chris Jones