The label of ‘product manager’ doesn’t usefully describe what I actually do.

I was recently introduced a new colleague. They said ‘Ah, you’re a product guy!’, then asked me about software to print large collections of documents. Their assumption was that, as a product manager, I am something close to a walking catalogue of products - which is fair enough, with a title like ‘product manager’, right?

In reality, it’s been years since product managers were people ‘from the business’ (possibly a senior and trusted technical specialist or subject matter expert) who would be placed in to a development team to decide what features they should build. Today, product management is a distinct profession in its own right - that wasn’t as true even four or five years ago. Product management in 2017 is more likely to be about creating a strategy that maximises the value of a service, working with a team to set goals that descrbe what the increase in value looks like if they’re successful but leaving the team to figure out how to do it.

We don’t yet have a label that usefully describes what our profession really does.

I think that the ‘product manager’ is dead, and the ‘value manager’ is emerging to take their place.

Identity crisis in product management

Look at the product management posts and talks of 2017 and a pattern emerges. We’re having a crisis of identity. This is clearest in the ‘product owner or product manager?’ posts and talks. Melissa Perri summarises this discussion succinctly:

“Product Owner is a role you play on a Scrum team. Product Manager is the job {…} A good Product Manager is taught how to prioritize work against clear outcome oriented goals, how to discover and validate real customer and business value, and what processes are needed to reduce the uncertainty that the product will succeed in market. Without this background in Product Management, someone can effectively go through the motions of Product Owner role in Scrum, but they can never be successful in making sure they are building the right thing.”

Roman Pichler has recently written a similar post:

“The confusion stems—at least partly—from the fact that Scrum is a simple framework focused on helping teams develop software. It does not cover common product management practices, such as, product strategy development, product roadmapping, and financial forecasting; and the only product management tool it offers is the product backlog.”

Government product management (my current bit of the product world) has been exploring this too, with Ross Ferguson saying that government needs the skills of product managers rather than product owners, and Zoe Gould essentially agreeing but saying that we shouldn’t get too hung-up on labels. Ross and Zoe get on well and are making the same point: that, whatever we’re called, the important thing is to be clear what makes us valuable in a team. And what we as Heads of Product in government have agreed is that product ownership is just one of the capabilities needed to be a valuable product manager.

The main theme I took from this year’s Mind the Product conference was product managers (myself included) admitting that we hadn’t chosen product features in years. The role of the product manager has become one of strategy and value, helping teams to set goals that describe and increase in value then getting out of the way and empowering the team to figure out how to do that. Martin Eriksson’s post from earlier in the year acts as a summary of the message we heard time and again throughout the conference: we are not the CEO’s of our products, our role is to lead by setting clear goals that hold teams accountable but also empower them to own the solutions. Martin’s closing remarks for this year’s conference were that the label of ‘product manager’ hasn’t really fit the role we do for a while now. I’ve been thinking the same for a while too.

Can we learn anything useful from the origins of the product management profession?

It started with soap

A product is something that you buy and own, like soap. I have never managed a ‘product’, despite having been a product manager for over a decade. A service is something you use but do not own, like Netflix. This better describes the things I’ve worked on. So why are we product managers?

‘You’ll be a little lovelier each day with fabulous pink Camay’

It’s 1931. Neil McElroy is in charge of promoting the Camay soap brand for Proctor & Gamble. Neil is frustrated that Camay always plays second fiddle to P&G’s leading brand, Ivory.

“In a famous memo to management, he argued for the creation of the role of “brand manager”. This person would take overall responsibility for the commercial success of a product, managing it holistically like a business in its own right.” - The Practitioner’s Guide to Product Management by Jock Busuttil, p.10

P&G agreed, and Neil paved the way for the profession of product management - our profession grew out of managing genuine products, in such a way as to maximise their value.

Agile and software and scrum, oh my

It’s 2001. The manifesto for agile software development has been created by a group including Ken Schwaber and Mike Beedle in February, and then Ken Schwaber and Mike Beedle publish Agile Software Development with Scrum’in October (quick work, huh?). In 2002, Schwaber and others will found the Scrum Alliance. The agile manifesto and accompanying principles say that we should seek to maximise the value of software, by prioritising features based on how valuable and delivering them asap. The scrum framework interprets the agile manifesto as a framework for development teams to use, and names product managers as the members of the team who prioritise the features to be developed, based on how valuable they are. The scrum framework also chooses to rebrand product managers as ‘product owners’. Neil McElroy’s vision of someone managing a product and running it like a business in its own right has been taken and rebooted for software, by the scrum framework . . . promoting the role of product manager in the process under the banner of ‘product owner’.

In 2001, software is still predominantly sold in shops, in boxes, on discs. It is something that you buy, and own. It is a product, so a product manager/owner makes sense.

There is no cloud, it’s just someone elses computer

It’s 2011. ‘Software as a service’ is now a thing. SaaS describes a shift in the relationship between businesses and consumers where by consumers rent use of software, with consumer hardware acting as terminals that access software that remains stored on the businesses computer, via the internet. In the realm of ‘cloud computing’, we no longer own the software we use. Software ceases to be a product and becomes a service. This leads to a huge shift in production, with successful companies breaking traditional barriers between design, development, operations, sales and marketing in order to have the much quicker sales cycles needed to compete in this market. Annual sales cycles for software products don’t cut it for software as a service: massive projects and formal handovers between departments are a good way to go out of business. Co-located, cross-disciplinary teams are increasingly standard.

Which means that product managers need to adapt. The traditional scrum product owner, focussed on software features, does’t work when each product mission needs to include work on your service wrapper, sales, and marketing - all of whom are likely to be part of the product team. Communities like ‘Mind the Product’ emerge, publishing their now famous article what exactly is a product manager?, which attempts to figure out what product management means when we no longer manage products. The now ubiquitous overlapping circles place product management at the heart of user experience, technology, and business - showing what the scrum product owner role, focussing on new features, does not encompass the skills needed of a product manager.

A product is (usually) not a business

. . . which brings us back to today, and our current identity crisis in product management. As anyone who has taken or taught on the General Assembly product manager course will know, ‘a product is (usually) not a business’. A product or service is only valuable when it is in the hands of a user, and getting software in the hands of a user takes more that just new features. A ‘product manager’ is accountable for the strategy by which the value of a product or service (and, increasingly, it’s a service) is maximised. We’re generalist amongst a team of specialists, hired to be the person in a team who’s passionate about the problem and the value of solving that problem, rather than the solution itself. We succeed when we help the team to prioritise its activity to best increase the value of the service, through data-driven prioritisation of goals. We manage value, not the product or service itself. The product or service is built and operated by the teams we work with.

We manage value. We own the strategy by which we maximise the value of services.

Value manager

Lots of product managers do not manage products, they’re managing services. It’s no longer enough just to help teams decide on the new features of their service, we need to focus on the ‘so what?’

  • how will this actually increase the value of the service, for users and for our organisation?
  • how do we hold ourselves accountable for increasing the value of our service, and empower our teams to use their combined skills to achieve this increase in value?

I’d like to propose that we are value managers, not product managers.

In The Art of Business Value, Mark Schwartz argues that we’re increasingly working in complex adaptive systems, typified by rapid change and complex interactions, in which we can influence but not control outcomes. The function of product management is to provide context and incentives that nudge the system towards its desired outcomes. We cannot, and need not, have perfect information - our challenge is to create conditions that move the system as a whole towards the value-outomes we want.

This is a fancy way of saying what me and others have been seeing for a while, and what came through time and again at the Mind the Product Conference: our role is to prioritise and set clear, value-driven goals that maximise the value of services by holding teams to account and empowering them to be their best.

The template for a good ‘goal’ to be set by a leadership role like a product manager is outlined by Barry O’Reilly:

  • We believe [this capability]
  • Will result in [this outcome]
  • We will have confidence to proceed when we see [measurable signal].

This value-driven approach works at all levels of an organisation: from a user-story on a team backlog, to a mission on a services’ roadmap, to a whole-organisation’s corporate strategy.

In 2017, this is what is needed from product management: value-driven strategy that can work in complex, adaptive systems and nudege services and organisations towards their goals. Total control and perfect information are not possible today, if indeed they ever were, and we need to introduce confidence through an adapative, data-driven approach that’s always linked to the ultimate goal: increasing value for our users, and our organisation. This is why we’re increasingly seeing product management moving into the leadership space, with roles such as Lead Product Manager, Product Director and Chief Product Offier much more visible than they used to be. Value strategy applies to the organisation as a whole, not just the individual products and services it creates.

The product manager is dead. Long live the value manager.

Afterword

. . . so, obviously we can’t just stop using the label of ‘product manager’. I’m responsible for recruitment and know that if I started advertising for the role of ‘value manager’ then I would not get many applicants. So we need to keep using the label of ‘product manager’ for practical resons . . . for now at least :)

But what I believe we can do is be more explicit about the truth that what product managers are accountable for is maximising value through valule stratgy, rather than just ‘the product’ and its features. It’d be great to get your take on ‘value management’ as described in this post, it’s still an early idea so I’d like to test it and improve it as much as is useful. Say hello on Twitter or Github if you’d like to talk.

There’s a bunch of things I re-read when writing this post that I didn’t have space to reference but are worth sharing anyway: