Product Management

What is product management? Who’s asking?

Who

I’m convinced that there are as many definitions of what product management is as there are product managers.  There are certainly as many definitions as there are companies.

This is one of the struggles of our line of work — it is difficult to gain agreement on its scope, its deliverables, its very purpose.   This leads to difficulties in evaluating whether it’s being done well, what should be done, and what kind of skills are necessary in filling an open position.

In “Why CMOs Should Care About The Rise of Product Management,” an interview conducted by Kimberly Whitler of Andrew Barr Brunger, formerly of Coach and Citibank, I see a great example of the difficulty in writing or speaking about product management.

Brunger’s comments appear to be from the perspective of a company where product management is responsible for executing on the brand’s digital marketing strategy (web properties and mobile apps).  I would be unfulfilled working for a product management team that meets the description in the article.

What’s difficult in talking about product management is not apparent here: Context.

Managing commercial products is vastly different than managing websites and shopping apps for a consumer goods brand; managing commercial software-as-a-service offerings is vastly different from managing internal products that support other teams within the enterprise; and managing consumer goods products is different than managing commercial off-the-shelf (installed) software.  All of these are different than managing the upcoming Internet-of-Things wave of devices with embedded software.

Some of this is brand management; some is product management; some is agile product ownership.  None of those are the same thing.

Tactical Product Management

Here’s an interesting passage from Brunger:

Product management teams, for the most part, concern themselves with re-engineering or evolving digital products to make these experiences simpler, easier to use, and more pleasing to consumers. Given the passion and expertise of these teams, and the excellent performance and business metrics that these teams deliver on a regular basis for their companies as they focus on user-centric design, it can be easy for a CMO to assume that the long-term competitiveness of a brand’s digital presentation is being well-cared for.

In practice, the brand’s digital presentation is increasingly being cared for through a time-boxed, feature-driven lens that drives impressive short-term value for customers, but has less demonstrated success in creating long-term strategic wins….

In my world of commercial Software-as-a-Service products, product management is unsuccessful if we assume our responsibilities are simply “evolving” a digital product through a “time-boxed, feature-driven lens.”   Further, in our world, product management is a business function–with vested interest in user experience and user-centered design, but where those responsibilities are shared with a user experience / design function.

But in the context of a digital agency, digital brand or even a consumer brand with a web presence, this definition may be pretty accurate.

In fact, the intense focus on time-boxed sprints is only part of the role.  Another part of the role covers the area Whitler describes as missing–thinking of the big picture, of where the product needs to go in the longer term.  In my world, this sentence scares me:

“Where should we be in nine to 18 months’ time to stay relevant and competitive?”–is getting less attention in the agile-driven product management organization of today than we might think.

Alright Already with Agile!

Reading the above quote, I perceive a product management organization that isn’t functioning very well, and that has become overly enamored with agile.  In my world, product management is responsible for the entire scope of offerings — including, as Whitler describes, “peering over the horizon to anticipate, say, a new category of wide-body, long range aircraft with over-ocean Wi-Fi capability and on-board cloud-based business productivity software solutions.”

RELATED:  From Scrum to Scrumban: An Agile Journey

Agile itself is another world of confusion.  Frequently I see authors conflating the Agile role of “product owner” with product management.  Agile development is applied in custom software, in internal software, and in commercial software; both off-the-shelf and SaaS.   The product owner role is a little different in all those contexts.  In commercial software, the role overlaps some (but not all) of what a product manager does.

One of the biggest challenges in my world is to maintain enough focus on the individual time box, but also maintain enough focus on reaching the right place in the market at a distant point in the future.  Resources must be devoted to both (among many other things).

So What Exactly *Is* Product Management, Anyway?

This week I spotted The Clever PM’s take on that very question this week.  He did an admirable job, and also recognized that trying to distill what product management actually is is an exercise in folly.  Here is the definition he’s put together over his time in the profession:

“Product Management is a multi-disciplinary role that guides the strategic and tactical efforts of a product to ensure that, in the end, a marketable product is delivered to the end user. Their primary purpose is to gather market intelligence, perform customer research, translate customer ‘needs’ and ‘wants’ into requirements, and occasionally to shepherd those requirements through to delivery.”

That sounds more like the kind of work I do; that doesn’t sound much (if at all) like the team described on CMO.Com.  It’s also not entirely in line with recent thinking about the lexicon of product management.  After all, many of us now use the ubiquitous Agile phrase “user story” in place of “requirements,” but is that even the best term?

Nils Davis recently suggested neither “requirements” nor “user stories” is the best way to capture potential software functionality:

I’m leaning toward “feature.” Having more features in our backlog than we can do makes more literal sense than having more “requirements” than we can do. And it’s easy to say that a feature solves a problem for the customer, which is the crucial link (i.e., to the market or customer problem).

“User story” is also a problem. Based on the original definition (a customer-visible piece of value), it’s not meaningful for a productcompany. Almost no real feature in a real product – and features are the increment of value in a product – fits into a user story. “User story” as an increment makes sense for IT applications, but not for products.”

We’ve struggled with this too.  Primarily because we use a tool that encompasses these terms, we refer refer to user stories individually, and collectively refer to a feature as an “epic” which gets delivered to customers.  Teams seem to find a lexicon that works for them, but may not be consistent with that of other teams.

Which is exactly my point.

The point of this post isn’t to call any specific definition wrong, including that of Mr. Brunger (or even my own).  Instead, I think we need to remind ourselves that product management takes many forms, and it is important to set the context when making generalizations about what product management is or isn’t, or should be.

So what is product management?  Who’s asking?

 

Photo via Flickr.

1 Comment

  1. John – great article! I agree that this is a fundamental problem. I like that you have started sub-dividing the topic into things like “commercial Software-as-a-Service products” versus “web properties and mobile apps.” There’s no question that at minimum the tactics of product management are different for these domains.

    Keeping in the general realm of B2B software/enterprise software/”commercial Software-as-a-Service products”, the way I’ve been talking about product management lately is as three top-level activities: 1) find and validate a market problem for which people will pay for a solution; 2) create or guide creation of a solution to the problem; 3) take the solution to market.

    Doing #2 without having done #1 will almost certainly lead to failure (“a solution without a problem”). And if you don’t do #3 well, you won’t realize the value of having done a good job on finding a problem and creating a solution.

Leave a Reply

Theme by Anders Norén

GET MY B2B PRODUCT NEWSLETTER TO CRUSH PRODUCT.
x

Get the B2B Product Newsletter to Master Your Craft

Join over 300 product managers sharpening the saw.

%d bloggers like this:
Read previous post:
Interaction Design
The Business Case for User Experience Investment

User Experience (UX) is the discipline responsible for delivering an optimal experience to the user of a product or service. For decades,...

Close