Episode 3 of Good Product Management brought to you by Scott Colfer.

Introduction

Product management is about improving the value of products and services for their users and their organisation. Product managers take the insights of several perspectives and find value in the sweet spot where they align. This is a specialist role.

In plain English? Product Managers do a lot of listening, thinking, and speaking. Hopefully in that order.

Everything changes but you

People find change uncomfortable. Groups of people find change particularly hard. Product management helps us make the right change at the right time to improve the value of our products. Deciding what change to make next is a lot of the job.

There are ten principles of product management that help to make good decisions:

Be passionate about problems but flexible on solutions
Keep it simple
Make time to think
Think about all the things
Move fast and mends things
Alignment over prioritisation
Everything is a gamble
Be honest with yourself
It’s OK to say ‘no’
Do good.

These principles are the opposite of the most common reasons why products and services fail. They create signals that inform evidence-based decisions for the good of products. You can read more about these principles in episode 1 of this newsletter.

Let’s stick together

Product management isn’t a technology function, it’s an organisational function. Technology is (usually) not the whole of a product or service, there are loads of other things, people, and partnerships required for success. This means that product managers need the ability to understand and align many perspectives. These perspectives come from real, human people. They may contradict each other, often with good reason. In an ideal world every perspective needed to make a product or service a success sits in the same team. Each perspective has at least one person providing this perspective. I’ve only worked in one organisation where this is the case, everywhere else has been as close to this as possible. No matter how these perspectives are provided, they need alignment if a product is to be a success.

Successful products and services need at least four perspectives:

i. People using the thing.

The perspective of the users of your product or service are important. This sounds obvious but is often ignored. We only achieve organisational goals by solving problems for our users. We need to understand the goals of our users and the barriers to achieving them, as well as the broader reality of their lives. We also need to understand how they interact with our products and services. We should measure the success of our products and services through observable changes in behaviour of our users in the real world.

The people providing the perspective of our users are often described as ‘UX’ specialists, where this stands for ‘user experience’. I don’t personally find this very useful. ‘Research and design’ might be better. There are researchers and designers who like to look at the broader lives of our users, and those who like to focus on how users interact with our products and services. Some like to do both.

ii. People paying our salaries.

It’s important to understand the perspective of the people funding your product or service. There can be a lot of snark towards this perspective, which we need to get over. When you’re funding your own product or service then you get to call the shots, until then you need to show some gratitude and empathy towards the folks trusting you enough to pay your salary and fund the product. Ditch the phrase ‘the business’ and call them ‘colleagues’ instead, as that’s what they are. They may have a broad perspective and organisational awareness that doesn’t exist within the core product or service team.

This might be a Director, CEO, CDO, CIO (lots of Cs), Head of, etc. You might also work with a specialist like a Business Analyst to help better understand organisational goals and to align product or service measures of success with broader organisational measure of success.

iii. The people bringing the product or service to life and keeping it alive.

There will be people actually creating the product or service. Let’s take software for example. To build the software itself there may be any combination of graphic designer, interaction designer, content designer, front end developer, web operations engineer, security specialist. To get the software into the hands of users there may be any combination of support desk, communication manager, engagement manager, training, partnership manager. And lots more. The perspective of these folks is critical because they know what is feasible and will often be first to see problems and opportunities with the product or service.

iv. People managing people and workflow.

You need at least one person managing the workflow of the product team, making sure it fits with any constraints or dependencies in the real world. They are responsible for the output of the product or service team. You might have these as Delivery Manager, Project Manager, or something framework specific like Scrum Master. Equally, you might not have this as a discrete role. In my experience, it’s often been missing as a role and picked up by someone else (including the product manager). This perspective is crucial because the product or service is as good as the team behind it. Understanding the team’s capability and developing their performance is the bedrock of what is possible.

Product Managers need to understand all four of these perspectives, listening to them, thinking about how they align, and talking about the correct configuration needed for the most valuable improvement to a product or service at any given time.

One perspective tends to dominate when they’re not aligned, and this is often toxic for the product or service:

I’ve had contact with tech startups that favour the people bringing the product to life (e.g. technologists, possibly design too). If you give a problem to an engineer, the answer is often to build something. And this is what these startups do. They become feature factories, building costly software features and often ignoring cheaper, more effective improvements to the overall service model.
At the opposite end of the scale, I’ve worked with teams so focused on the perspective of their users that they never define a narrow enough scope of the problem to solve. They remain in permanent research and have analysis paralysis.
I’ve worked with startups where funding hurt them. Weird but true. The perspective of the funder, the person paying the salaries and bills, can dominate. Say you get funding from a tech investor, then you find that you need to change your service to be mainly offline: what do you do?
We all have scare stories of working on products or services that were really projects. Where stage after stage was solemnly followed as planned even though it was obvious the thing would fail. Or we’ve gone ahead with something because ‘delivery is the strategy’, even though we had niggling doubts about whether we were truly solving a valuable problem. This is the risk of the output-focus becoming dominant.

Product managers facilitate and align these perspectives to find the right blend. The blend you need changes depending on the problem you’d like to solve and the maturity of the product or service. For example, a leap of faith product idea in discovery is focused on defining the problem it wants to solve, testing the riskiest assumptions about the problem and finding out if it’s sufficiently real, urgent, pervasive, valuable and as yet unsolved. This is likely to be led by specialists in understanding users. Other perspectives may be required in a supporting role but run the risk of distorting the problem definition if they are in a lead role.

I wish I could tell you that I’ve found a simple way of aligning these perspectives. I’d love to pull together a ‘You Won’t Believe This One Insane Trick For Aligning Perspectives’ article. But every single decision should be treated on its own terms. Technology is simple but people are complicated. If you only had time to learn one new skill I wouldn’t suggest a computer science degree, I’d suggest learning about people. I’ve done this via coaching. I’m a trained non-directive performance coach and this is the skill that has most helped me as a product manager. Over the years I’ve learned the basics of HTML, CSS, JS, modern development workflows and remote collaboration using version control, web operations, architecture for the cloud, and continuous integration. You can throw is an iOS development bootcamp, a dabble in Ruby, and even Dreamweaver (back in the day). They’ve all helped at times. But coaching is a skill that I have used several times every single day of my career. It’s helped me work with people and given me tools to understand their goals, obstacles, reality, and practical steps that can help them. It took months to learn the basics. I’m still improving at it more than a decade later. It’s the closest thing I’ve got to a trick for understanding the perspectives of others in order to find value where they align.

Something good can work

This article is about product management that puts people before profit. So doing good is important. Whenever we’re working on a product or service we must ask ourselves a couple of questions and give honest answers:

Are we making life better for our users?
In solving a problem for users through our product or service, do we mess with problems being solved elsewhere in society?

If we really want to create ethical products and services then we can go further and ensure that our product/service/organisation:

Has the voluntary, well-informed consent of our users
Aims at positive results for society that cannot be achieved some other way
Is based on insights that justify the work
Is developed in a way that protects the needs of users
Doesn’t go ahead if it risks jeopardising users’ needs
Ensures that any risks are proportionate to the expected humanitarian benefits
Adequately prepares to protect users against any risks
Has staff who are fully trained and qualified
Is able to stop if users report that it is making their situation worse
Is able to stop if staff report that it is making the situation worse for users.

Check the meaning

The elements of product management discussed so far must work together to improve the value of your products and services. Value is context specific and can be ambiguous, it’s the job of product management to define it and improve it. People understand profit as a way of measuring value and can get lost without it. This can be tricky if you’re working in an organisation that measures value through the amount of good it does. How do you measure value if you are a product manager in a Government Department or Agency, Local Authority, Charity, Non-profit, Social enterprise, or Non-Governmental Organisation?

We’re comfortable thinking about value when it’s measured through financial profit and financial return to shareholders. This is private value measured through money.

At the opposite end of the value scale are organisations that measure value through the good they do in society. They set themselves a social mission and measure value through the impact of their mission within society. This is called mission value. The goal is not to make a financial profit, it is to achieve the social mission as well as possible whilst maintaining financial liquidity.

Products and services provided through democratic government measure their impact through mission value but have a second element. Government needs to maintain the trust of the public in order for democracy to persist. Value is placed on maintaining the trust of the public in government and democracy, which we’ll call political value. Political value often takes the form of transparency and openness around things like costs, contracts, reporting, etc. This is OK. Maintaining democracy is important. We need to ensure that the majority of value is mission value, with political value being the minority. Political value sounds wooly. It is. I’d love to give you something more specific but I’m not clever enough. Soz.

Ok, so we measure our value through the extent to which we achieve our mission and have a positive impact on society. We may also need to invest some of our time and effort in being open about what we’re doing if we’re creating products or services within government and spending taxpayers’ money. This works at a high-level and can be used to set corporate goals and visions. But how do we measure the value of individual products and services within a larger organisation?

Our organisation will probably achieve its social mission through the outcomes of smaller products or services. These individual outcomes and up to the overall impact the organisation wants in society. This is where context is key. I am not smart enough to tell you how to put a value-figure on the outcomes of your products or services because this depends on what you’re doing, who you’re doing it for, why you’re doing it, and how you’re doing it. I can sketch out how I’ve put a value figure on the outcomes of products in my organisation.

Some key outcomes are consistent to the vast majority of them:

‘completion rate’ - do users complete their journey and receive the help they were looking for?
‘time taken’ - this is about reducing the time or effort needed to complete a task (which might be a transaction if it’s the public, or administration if it’s staff) and requires us to benchmark time take before we introduce our product, and time taken after introduction
‘adoption’ - there is a minimum % or number of our target user group needed to use our product before we’re justified the time and money spent on it; this becomes the our target for reaching product-market fit/benefits realisation/Live assessment
‘cost per transaction’ - particularly once a product is mature, we should get better a meeting the needs of our users with less and less effort based on our increasingly sophisticated understanding of what we’re doing and who we’re doing it for
‘satisfaction’ - it’s important to understand sentiment towards our product. Low satisfaction might suggest that people may be avoiding a public service because they dislike it so much, or that staff may be creating their own workarounds via spreadsheets (as a couple of examples).

These are principles for how we measure the outcomes, each product manager and their team has to take these and contextualise them further to work for their own product before they become useful. For example, time taken could need to mean ‘number of steps taken to complete or process an application for public service X’.

There are others, and they’re more or less useful depending on the product and its maturity, but they give a sense of what I’m talking about. Our public services are a mix of public-facing and professional-facing products. Several of the ways in which we measure the outcomes of our products are shared cross-government and published on GOV.UK however they focus on public-facing products. In reality, most of a public service happens behind the scenes, driven by staff. I have blended the governments suggested ways of measuring outcomes of public-facing products with standard ways of measuring the outcomes of staff-facing/business-to-business products.

Conclusion

Product management boils down to helping teams to make regular changes that improve the value of our products and services. Each change is a gamble. It should be a hypothesis that some insights we’ve developed suggest that making a change to an element of our business model should improve outcomes for our users and our organisation, and we’ll know if we’ve been successful if we observe the behaviour of our users after we’ve introduced our improvement. If it works, we move on to the next opportunity to change. If it doesn’t work, we roll it back. It’s as easy and as hard as that.

Next episode

Recap

So far I’ve shared principles for product thinking, plain English principles that anyone can use to improve the value of their product or service. I’ve also shared a personal story about how I learned some of these principles when founding a non-profit service for young parents in the early 2010s.

This episode you’ve just read gives a high-level of description of what it looks like when product thinking is brought to life through a specialist role called product management.

Episode 4

Next episode will focus on how to bring this to life through product strategy and product tactics. I’ll also talk about the skills and attributes of product managers. This will likely include my take on how and why we wrote the product manager role description and skills in GDS’ Digital, Data, and Technology Profession Capability Framework and how I’ve tweaked and improved these skills for my own context over the years. The next episode will get into the detail of the role and focus on the technical aspects of product management.

Thank you

Thank you for subscribing to this series of emails on good product management brought to you by Scott Colfer. If you’ve found it useful or interesting please consider sharing it with someone else and sticking around for the next episode.

Sharing

Attribution-NonCommercial-ShareAlike 4.0 International (CC BY-NC-SA 4.0)

And finally

Most of the section headings are song titles as a way of keeping things interesting for me during the editing process :)