When defining the job of a product manager, at least one of two definitions always pops up. The first one (chronologically) 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 is Martin Eriksson’s product management 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’re both seminal, and just look at product management from different angles. However, they do share a seemingly futile common characteristic: the number three. It is thus tempting (at least it was for me) to try and fit these two triads together.
tri-ad (trī′ăd′, -əd)
1. A group of three. 2. … 3. …
[Late Latin trias, triad-, from Greek, the number three]\ tri-ad′ic (trī-ăd′ĭk) adj.
- valuable to Business,
- usable to UX, and
- feasible to Tech;
but this just didn’t sound right. Let’s go through each one of these.
Valuable = ?
The “valuable” requisite in Marty Cagan’s triad is also often put as “will customers buy it?”. This formulation alone highlights how “valuable” has one foot in the Business (“buy it”) and one in UX (“customers”, users). A valuable product achieves business goals in exchange for delivering value to the end user. Ergo:
Valuable = Business × UX
Usable = UX?
Once more turning the adjective into a question about the product, the issue now is “can customers use it?”. In Martin Eriksson’s product management Venn diagram, UX stands for the PM being:
“the voice of the user inside the business and passionate about the user experience”
Is this enough for the product to be usable? No. We need to find the right experience for the customer’s Job To Be Done and deliver that experience. The technology we use (software or hardware, high-end or low-end) must enable that experience and not get in the way of it.
Usable = UX × Tech
Feasible = Tech?
Tying feasibility to “Tech” would reduce the problem to “can you build it within the limits of the available technology?”. However, there’s much more at play than the mere possibility of building the product.
The real question is whether we can build and maintain the product with a cost compatible with business goals. There are two levels to this.
- We can build the product with the available technology, but it’s too expensive to hold a solid business case.
- We can build the product easy and cheap, but it entails a heavy service component (support, operations, etc.). Its cost outweighs the money to be made out of the product’s value proposition.
It’s not by chance that, in his article The Biggest Risk, Marty Cagan lists four critical questions for product discovery. They’re the two I’ve brought before for “valuable” and “usable”, plus two more :
- ”can we build it?” and
- “can our stakeholders support it?”.
Feasible = Tech × Business
Marty’s adjectives at the intersection of Martin’s product management Venn diagram
Corollary: using these intersections to become a better Product Manager
We can draw a corollary of this from Martin Eriksson’s remaining definition. Martin describes the T-shaped product manager:
“experienced in at least one, passionate about all three, and conversant with practitioners in all.”
Many PMs are experienced in at least one of Business, UX and Tech because they came from either one. When they broke into product management, such PMs were purely T-shaped product managers: experienced in exactly one of the three, and not entirely passionate (yet) for the remaining two.
Applying the framework I presented above, each adjective maps to the two weaker circles in the product management Venn diagram:
- a Business-deep PM might struggle with discovering a usable product;
- a UX-deep PM might struggle with discovering a feasible product;
- a Tech-deep PM might struggle with discovering a valuable product.
Such perspective can be quite useful to both:
- the developing PM — to watch out for related pitfalls in their work, and focus skill development efforts in their career development; and
- the organisation where they belong — to best use of their strengths and coach them to develop on their weaknesses.
Even established product managers can improve with this framework. Unconscious biases from their own particular background/experience can negatively impact the results of their product discovery initiatives.
- If you enjoyed reading this story, you might wanna read the followup “A Product is a Product: product management is not just software!”.
- 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.
- Edit (December 2018). On 29 November 2018, I’ve presented an improved version of the ideas in this post at Productized Talks. You can check out the respective slides here. I took the opportunity tweak this story. Most notably, I’ve improved the graphical representation of my main idea and moved it towards the end of the story. To remain truthful to what I did (not) have in mind when I wrote this in 2017, I didn’t add the improvements from the talk. Namely, I kept out the idea of using this framework to assess product organisations/companies and guide stakeholder management accordingly. I’ll be working on a separate story to cover that.