When defining the job of a product manager, at least one of two definitions always pops up. The first one (chronologically speaking) is from the original edition of Marty Cagan’s indispensable book Inspired: How to Create Tech Products Customers Love; Marty describes it as ”to discover a product that is valuable, usable and feasible”. The other one is Martin Eriksson’s Venn diagram, supporting his definition of “product management as the intersection between business, technology and user experience”.
None of them is, of course, more correct than the other. They are both seminal, and just look at product management from different angles. However, they do share a seemingly futile common characteristic: none of them refer to “software”, or to “digital product”. Product is product.
Too often, I see Martin’s Venn diagram being misquoted, or adapted, with “Design” in the place of “UX”, and/or “Engineering” in the place of “Technology”.
This is not necessarily wrong. For instance, in the first example above, Chaki Ng presents this Venn diagram when explaining his hiring preferences. If he means “Design” (and he clearly does), it’s no-one’s right to say “this should read UX”.
The example on the right, from Benjamin F. Wirtz’s “3 Product Manager job spec requirements that need to go”, is a fine example of why most of Martin’s Venn diagram variations: bias.
Product Management is not just software and digital
The contemporary product management community emerged in software and digital products. Bias towards these types of product is natural when interpreting and building upon its body of knowledge. I plead guilty of this bias as well!
Product Management is a decades-old discipline from consumer goods. If we remember that and keep terminology neutral, the power of these definitions is evident (especially when considered in relation to one another). Let’s tie both Marty Cagan’s and Martin Eriksson’s definitions together as per “Marty meets Martin” .
Re-use with appropriate attribution (link to https://jcraveiro.com/blog/marty-meets-martin/).
As an example, let’s now imagine for a bit that we’re “PM of Stools and Benches” at IKEA. Here are some questions we could ask to assess an existing or future product.
Valuable (Business × UX) — “Will customers buy the product?”
Can the customer understand its purpose, and how it fulfils a need of theirs? Is it a natural cross-sell from another product? Is the price point compatible with…
- … the customer(s) we’re targeting with it?
- … its purpose?
- … any effort the customer will still spend in assembling it?
- … its aesthetics?
- … the (perceived) quality of the materials?
- … how often the customer expects using it?
- … how long they expect to keep it?
- … the quantity which makes sense buying at once for its use case?
Usable (UX × Technology) — “Can customers use the product?”
Is it the (disassembled) product easy (or cost-efficient) to transport from the store to the customer’s home? Does the assembly process lend itself to being easy / pleasant? Does the assembly process ensure that the end result meets the product’s expectations, regardless of the customer’s handiness? Is the material compatible with the context where customers use it (e.g. outdoor vs indoor)?
Does the product go well with other products the customer uses together. E.g., how well does it fit under a table?
Does the product pose a danger in the context where customers use it. E.g., can a customer trap his testicles in the stool if he uses it to sit in the shower?
Feasible (Technology × Business) — “Can we build it?”, “Can our stakeholders support it?”
What’s the cost of manufacturing? How scalable is the manufacturing process? Is the cost of putting it into the market compatible with the price customers are willing to pay? Don’t forget this includes manufacturing it, shipping it, marketing it, and supporting it.
We can see that there’s more than just design in the UX aspects of the “Valuable” and “Usable” sections. For instance, think about the question “Can the customer understand its purpose, and how it fulfils a need of theirs?”. The answer involves not only the product’s design, but also the staff at the store: what they know about it, what they ask the customer about their needs, etc. All of that is part of User Experience. Conversely, most of the technological considerations in the “Usable” and “Feasible” sections can hardly be seen as relating to engineering.
With this understanding, we can build strong arguments around these two solid definitions of Product Management when we realise that they’re applicable to other industries. For instance, Ben F. Wirtz’s section on technical background as a requirement for a PM has a new life when we add furniture role-play. Would we require a candidate to “PM of Stools and Benches” at IKEA (yeah, I’ve just quit) to have experience building furniture?
Closing remarks on product management
The product management community is alive and kicking, mainly powered by:
- the boom of digital products and
- the proactiveness of the product people in this area to share their knowledge.
However, we should keep paying homage to the origin of product management in consumer products. We’re then able to recognise that good product management knowledge is, with due adaptation, applicable to any product — not just software or digital products.
If you enjoyed reading this story, you might also like its prequel “Marty meets Martin”.
This post represents my individual professional opinion on this subject, not that of any company I work (or have worked) at/for on this subject area.