What is product management, anyway?

For me, one of the most interesting parts of the product management role in software is that it can be so different from one company to another.  It's highly subject to variation from place to place, based on a company's executive team, its culture, the kinds of products it makes, and the other roles on-staff.

When talking about product management, I used to frame the job in terms of a triangle, whose points denoted the three most common responsibilities of the PM role -- Marketing work (principally, understanding the market and generating the core of the solution messaging), Product work (articulating the market needs and defining the solution requirements), and Project work (some form of cross-functional go-to-market/readiness planning).  Something like this:

I'd often scribble something like this (including pertinent examples of the kind of tasks I've included here) on a white board when bringing new PM's up to speed, talking to new engineers, or even in interviews.  My point was that the product management role for any given organization could be defined as a shape (the blue blobby triangular thing) that stretched into each corner to the extent defined by that organization.  And I think it's fair to say that in most organizations, the shape would likely be subject to frequent revision as the organization and its product and market situations evolved.

Recently, though, I've added a fourth point to my diagram -- the Business.  Some of this stems from my time as a GM, owning a P&L, and some is just the result of moving up the PM ladder over the years, where responsibilities shift from the tactical to the strategic -- or maybe just expand to require both.  And it's a useful inclusion for the PM function, if not necessarily for every PM on the team.  Adding this dimension makes the PM team accountable for the results of their work within the other three axes, and also provides an important lens through which the PM's should look at everything they do:

• What, really, is the market opportunity, and which are the right problems to solve?  It's my hide on the line if we pursue the wrong opportunities.
• What, are the true must-have's we should spend money on?  It's my hide on the line if what we deliver doesn't work right, or doesn't find enough market interest to buy.
• How can I be sure that the rest of the company is ready to push forward with what we've built?  It's my hide on the line if Sales doesn't pursue opportunities to sell it, if the service quality around the solution is poor, and customers are both few and unhappy.

And so on...  These are important questions that may never be asked if the PM's are thinking mostly about features and demos.  The ultimate judge of an offering (and thus the performance of its product manager) is its financial performance against the established goals.  And so a square it is, not a triangle, and with a 4-pointed blob defining a given role against all possible responsibilities:

I'm not sure how much value these diagrams really have out of the context of a white board -- PowerPoint seems to formalize them inappropriately to me -- but they've been useful framing tools with a pen or marker.

So, back to the question -- what is software product management?  A product manager is a custodian of a business.  The PM's job is to make sure that there is an opportunity worth pursuing, that the people building the solution for that opportunity get it right, that the people who need to execute the solution and bring it to market get those jobs done successfully, that customers are delighted and kept happy, and ultimately to make sure that all of that effort was worth making, as judged by the financial success of the product.  There are a thousand different tasks and activities that fall into getting all of this right, but focusing on those risks diminishing the role and its strategic importance.

That's my simplified take on the job.  How do you see the role?  I'd appreciate your opinions, and I thank you for reading.

All for now,

J