Against entropy — Why product managers really manage conversations

Photo by Brett Jordan on Unsplash

As Practice Lead for Product at NHS Digital, I often have discussions with colleagues about what product management is and what it does —in particular how it’s distinct from other roles, and what makes it a necessary function for public service digital delivery teams.

This can often be a lot more challenging than one might expect — particularly as product intersects and overlaps with a range of other roles in a way that can make its boundaries tricky to articulate in a ‘one size fits all’ description.

I’ve noted some of the common challenges I’ve faced in these discussions over the years:

• Common definitions of product management often come laden with ‘insidery’ terms and jargon that serve as a barrier to the uninitiated. A cursory Google search will reveal a broad range of articles and blog posts attempting to explain what product management is. These use different language and conceptual frameworks with varying degrees of success. However, while they capture important aspects of the work, I’ve found they often do so in terms that are either needlessly wooly or inaccessibly complex — especially to those who don’t work in software development. I feel strongly that to advance as a profession, we need to find language that avoids us seeming like just another “conspiracy against the laity”.
• Product managers can have very different routines depending on the particular context of their product or service. Product work tends to be highly context-driven — product managers working with different domains, teams, users, stakeholders, technologies and operations can have routines that look quite different from the outside. However, there definitely are common skillsets that underpin product management practice across this wide variety of domains — even if this isn’t currently especially well-articulated.
• Common descriptions of product management often fail to establish the ‘why’ of things up front — and therefore tend to leave implicit much of the ‘in-between’ work of product management that isn’t formalised (i.e. a particular technique or method), but is nonetheless vital to being effective in the role.

As a result, accessible definitions of product management that speak to the ‘whole’ of the work (rather than merely listing its parts) can often feel elusive. This has the unfortunate side-effect of leaving those outside the profession to question whether the distinctions that supposedly define product management are spurious.

I’ve spoken with enough product managers, working across enough different sectors, who despite their considerable efforts and achievements still struggle to explain simply what exactly it is they do to others. However, I’ve long suspected that the issue isn’t with them, but with the commonly accepted definitions and framing of the role.

I’ve been thinking about those definitions and their limitations for several years now whilst supporting the growth of the product management profession within the NHS — trying to work out ways to bring the role product managers play in service design and development ‘down to earth’ for others.

I’ve also encountered some interesting ideas that have convinced me that there might be better ways of framing both the means and ends of product management.

The rest of this post is my attempt to make sense of these ideas.

Start with the team

‘The team is the unit of delivery’ is now a well-established maxim in the UK’s public sector digital community. Today it is increasingly becoming common wisdom that multidisciplinary teams are critical to the future of government service & policy design.

The rationale for this important shift in practice is actually quite straightforward —policy and service design decisions are often (and increasingly) highly complex and multifaceted. Having teams with the relevant mixture of skills and expertise continuously engaged in design and delivery decisions (whatever these may comprise) allows teams to more readily and rapidly navigate this complexity.

Conversely, by leaving critical perspectives out of the equation, one can easily end up making poor choices — the consequences of which often need to be remedied or ‘unpicked’ at a later point (if it isn’t already too late).

Depending on the implications of those decisions, the outcome can be anything from unnecessary confusion, delay or waste to mismanaged expectations, organisational conflict and the unmet needs of service users.

In addition to poorer results for those ultimately affected by a service or policy, these things can put unnecessary stresses on teams, or have other adverse consequences for the organisations involved.

We can’t afford for this to be the case if we can readily avoid it — which is why the choice of how we work together is fundamental to whether we create vicious or virtuous circles whilst attempting to deliver services and policy in a complex and uncertain world.

However, multidisciplinary working also introduces some of its own challenges — primarily in navigating the differing levels of awareness, understanding and use of language between differently skilled and experienced team members, as well as in negotiating trade-offs between what is optimal from one perspective versus another (e.g. for design vs. development).

Widening the lens

The same basic principle applies beyond teams as within them. In any reasonably sized organisation, no team is wholly self-sufficient —a fact that often applies even more acutely in public sector work. As Honey Decanay illustrates here with superb clarity — policy, programme and product/service design are often intimately and inextricably interwoven.

As a result, design decisions relevant to a given policy or service can conceivably occur at any level of the system(s) under discussion— whether within or beyond the organisation responsible for a given programme of work. The July 2021 NAO report on the challenges of implementing digital change gives long overdue recognition that:

“Initiating digital change involves taking a difficult set of decisions about risk
and opportunity, but these decisions often do not reflect the reality of the legacy environment and do not fit comfortably into government’s standard mechanisms for approval, procurement, funding and assurance.”

…and…

“If… delivery implications are poorly understood the level of ambition can be unrealistic from the outset.”

Moreover, in any such programme of change there are always dependencies and constraints to navigate involving other people, teams or organisations — whether these are in terms of expertise, technical or operational capacity, authority to act, or other important things like clinical judgement or legal and regulatory compliance.

In government, the situation isn’t helped by a model for allocating and assuring spend which is currently ill-equipped to support and incentivise the most urgent and necessary forms of inter-agency collaboration in policy and service design.

Furthermore, in large, complex systems like the NHS — where there are simply so many actors with some stake in the delivery of services or policy outcomes — the above challenges can prove particularly acute.

In such complex delivery environments it’s actually relatively easy for the perspectives, decisions and actions of those involved to fall out of alignment with each other — presuming that they were even aligned to begin with!

Rule #1: Things fall apart

Turning and turning in the widening gyre

The falcon cannot hear the falconer;

Things fall apart; the centre cannot hold;

Mere anarchy is loosed upon the world

From The Second Coming by William Butler Yeats

There’s a useful (if loose) analogy with scientific ideas that can help us understand why we need to invest continuous effort in order to maintain alignment — especially in complex contexts involving lots of variables.

In thermodynamics (the physics of how heat effects matter) there’s a measure of how ‘disordered’ a system is known as entropy. Entropy is a function of the number of possible states the system could be in.

The Second Law of Thermodynamics states that the entropy of a closed system will never decrease — in other words, overall the universe (the ultimate closed system) tends inevitably toward more ‘disordered’ state over time.

The Second Law explains why your cup of tea gets colder over time — coming into thermal equilibrium with the surrounding air rather than remaining warm indefinitely. The reason for this is because, probabilistically speaking, the likelihood of ‘disordered’ states (where the tea’s heat energy is dissipated outward) is in practice far greater than that of ‘ordered’ states (where it is not).

A consequence of this is that it often requires focussed or continued investment of effort to maintain order against the overwhelming likelihood of growing disorder.

This blog post from Farnham Street discusses how we can use the idea of entropy as a mental model for thinking about the work of teams and organisations. This quote from the post captures the key insight:

For every useful arrangement of affairs towards a common business goal, there are many orders of magnitude more arrangements that will get us nowhere. For progress to be made, everything needs to be arranged and managed in a certain way; we have to input a lot of energy to keep things in an ordered state.

In scientific terms, organisational analogies with this kind of entropy have their limits. However, for this discussion entropy’s usefulness is in helping to foster an intuitive understanding that it often takes continuous, focussed effort to maintain organisation.

The art of conversation

As humans, we use conversations to exchange information. Conversations are the fundamental unit of human collaboration — the means by which we construct and share our knowledge, experiences, thoughts and opinions, and the way in which we reach agreement about what to do and how. It’s not entirely unreasonable to suggest that any organisation is basically a set of conversations.

In the fight against ‘things falling apart’ in matters of organisation, conversations are our primary tools. To stand a chance of achieving the best possible outcomes when creating services or otherwise shaping systems, we need to take the conduct and general health of our collective conversations seriously — to treat good conversations as fundamental enablers of progress.

When ‘things fall apart’ — as we have established they are more likely to do than not, at least without some concerted effort — in retrospect we are often able to recognise that it was ultimately because for some reason we weren’t able to have the conversations that mattered.

But what if there was someone on the team whose primary purpose was to make sure the conversations that most needed to happen actually happened?

Focus on what matters

So, if we take the above as read, we know:

• The world is complex and tends toward disorder
• By containing diverse yet relevant expertise, (well-facilitated) multidisciplinary teams are better equipped to navigate complexity
• Actions and decisions that materially impact service outcomes can occur at all levels of a system — within and beyond those teams
• Conversation is the vehicle for aligning decisions and actions toward shared goals or outcomes — creating useful order where it might not otherwise exist

Building on these premises, we can reframe the role of product managers:

Product managers help delivery teams understand and maximise the value that they and their products or services deliver.

They do this by creating an environment where teams and their partners can have timely, relevant and informed conversations about the things that matter most.

This is what I believe the core of my job is as a product manager actually is — making sure the conversations that need to happen are actually happening.

Conversely, if something I’m doing isn’t contributing to this, there’s a question about whether it should really be a priority for me.

The definition above is what I believe remains when you remove the specifics of a particular business, industry context (e.g. a VC-backed fintech startup vs. a government agency), group of users or products and services — and ask what product management fundamentally is.

The rest, for me, is simply detail (though those details are often far from simple)— bound up in the specifics of a particular domain and context — in users and their needs, services, outcomes, operations, policies and technologies.

All the product management frameworks and canvasses, skills and expertise, strategies and tactics that one finds online— these are all tools that help product managers facilitate common classes of service design and product development conversation, for example:

• What are our goals & priorities?
• Who are our users and what do they need?
• What do we assume or not know that we need to find out?
• What does success look like and how will we know we’re achieving it?
• What is possible & feasible with the technology and other resources we have (or could employ)?
• What operational capacity do we need to meet demands for our services?

Much of the art of product management is in knowing what conversations are currently most important, who needs to be involved (as well as what views and concerns they bring to the table), and what information and tools are best used to support them.

This is where the product manager’s skillset comes in — which includes, among other things:

• understanding what different teams members contribute in terms of skills knowledge and situational awareness
• knowing what techniques and tools can be used to tackle different classes of problem
• appreciating how management approaches and constraints might differ at different stages of the product lifecycle

Where ‘traditional’ software project management created generic, single-sized (and therefore often ill-fitting) suits of so-called ‘best practice’ for managing change, contemporary product management recognises the need to tailor design and delivery approaches to the problems, teams and context at hand — making it better suited to design and development in novel, uncertain and evolving domains.

Product managers as keepers of the collective conversation

There’s a reading of my definition above that might seem unappealingly passive to some. Surely the product manager is a driver, an agent of change, a mini-CEO — or some other self-aggrandising metaphor that centres the PM as someone who effectively instrumentalises others— the visionary genius who takes control of things.

Melissa Perri busts this myth in the intro to her Product Management Foundations course — but she appears to be in the minority in an industry that still too often hangs its hat on the Jobsian myth of the ‘visionary.

This might be the way to get people with a certain strain of ambition to apply for your jobs — but its not what my experience tells me effective product managers actually do for their teams and organisations.

Sadly the critical organisation-facilitating function of product management has for some time been cloaked in a hazy mystique that ultimately doesn’t serve our cause — delivering products, services and infrastructure that better meet people’s needs.

So much of being a product manager is about making sure the right conversations are happening — irrespective of whether the PM is a participant in them or not. If they are happening — happy days! If not — time to hustle:

• Sometimes it’s simply making sure the right people are talking.
• Sometimes it’s setting up the space and prerequisites for a productive conversation about X — one that reaches actual conclusions and decisions that move things toward clarity and action.
• Sometimes it’s about finding people with the right expertise or authority to involve in a conversation.

My definition and rationale above attempts to address these problems by articulating not only what product management seeks to achieve, but how it claims to do so and (most importantly) why it is necessary:

• What? — The understanding and maximising of the value services deliver.
• How? — Through timely, relevant and informed conversation between those responsible for delivering services (and any other relevant people).
• Why? — Because navigating complexity to deliver effective services & policy requires the integration and alignment of diverse perspectives, both within and beyond delivery teams.

In this scheme, a good product manager is more an orchestrator of necessary conversations than someone who instrumentalises people toward their own ‘visionary’ plans and goals. It recognises that in reality the visions that stand the test of time are in general the hard-won work of collaborative endeavour under challenging circumstances.

That is what I believe the heart of product management is in practical terms.

It begins with understanding a context — a system, an organisation, a team, a set of goals or purposes. Users and stakeholders, needs and policies, technologies and operations, constraints and dependencies.

It moves through cycles of decision and action — what could and should be done, and who could and should be involved in doing it.

“What conversations matter most right now?”

“Who should be involved in them?”

“How should we have them?”

“What do they need to achieve?”

“What will we do next?”

Rinse and repeat — until DONE.