A Product is a Product: Product Management Is Not Just Software!

When defining the job of a product manager, at least one of two definitions always pops up. The first one (chronologically speaking) is from Marty Cagan’s indispensable book Inspired: How to Create Tech Products Customers Love; Marty describes it as “to discover a product that is valuableusable and feasible”. The other one is Martin Eriksson’s Venn diagram, supporting his definition of “product management as the intersection between businesstechnology and user experience”.

© 2011 Martin Eriksson

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”.

Left: Chaki Ng (“UX” becomes “Design”). Right: Benjamin F. Wirtz (“UX” becomes “Design”, and “Tech” becomes “Engineering”.

This is not necessarily wrong. For instance, in the first example above, Chaki Ng presents this as the Venn diagram he draws when explaining his hiring preferences. If he means “Design” (and he clearly does, and one can see in the surrounding text), 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 — aka Moneyball for Hiring Product Managers” (which I strongly recommend), seems to me a fine example of the reason for most of Martin’s Venn diagram variations: bias.

The contemporary product management community emerged in software and digital products, so a bias towards these types of product is natural when interpreting and building upon its body of knowledge. I confess myself as guilty of this bias as well!

If we remember that Product Management is indeed a decades-old discipline from consumer goods and keep the terminology neutral, then the power of these definitions —especially when considered in relation with one another— is evident. For the example below, let’s tie both Marty Cagan’s and Martin Eriksson’s definitions together in the spirit of my previous article “Marty meets Martin: connecting the two triads of Product Management” — from where I literally copied and pasted the first 106 words of this article.

© 2018 João Craveiro (inspired by the work of Martin Eriksson).
Re-use with appropriate attribution (link to https://jpgcc.eu/blog/marty-meets-martin/).

As an example, let’s now imagine for a bit that we’re “Product Manager 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 it?”
    Is the price point compatible with the customer’s to which it’s directed? Is the price point compatible with its purpose? Can the customer understand its purpose, and how it fulfils a need of theirs? Is the price point compatible with any effort the customer will still spend in assembling it? Is the price point compatible with its aesthetics? Is the price point compatible with the (perceived) quality of the materials? Is the price point compatible with how often the customer expects using it? Is the price point compatible with how long they expect to keep it? Is the price point compatible with the quantity which makes sense buying at once for its use case? Is it a natural cross-sell from another product?
  • Usable (UX × Technology) — “Can customers use it?”
    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 used compatible with the context in which it is used (e.g. outdoor vs indoor)? Does the product go well together with other products the customer employs for the same use case (e.g., how well does it fit under a table)? Does the product pose a danger in the context(s) it’s expected to be used — 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 (manufacturing it, shipping it, marketing it, supporting it) compatible with the price customers are willing to pay?

We can see that there’s more than just design in the UX aspects of the “Valuable” and “Usable” sections. For instance, seeking to answer “Can the customer understand its purpose, and how it fulfils a need of theirs?” involves not only the product’s design, but also the staff at the store—what they know about the product, 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, solid arguments built around these two solid definitions of Product Management gain additional strength when we realise that they’re applicable to other industries. For instance, Ben F. Wirtz’s whole section on technical background as a requirement for a PM (the part of the article where there’s a strong bias towards software) has a new life when we bring the above furniture role-play into it. Would we require a candidate to “Product Manager of Stools and Benches” at IKEA (yeah, I’ve just quit) to have experience building furniture themselves?

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, and 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 be interested in its prequel “Marty meets Martin: connecting the two triads of Product Management”.

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.