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: 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.
That’s what I tried to do when I was preparing my talk “What the heck is a product manager?”, targeted at would-be PMs and junior PMs (which I’ve delivered at Pixels Camp, and at university invited lectures). My first naive thought was to associate:
- 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, even by himself, 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 is one that 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 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.
For the product to be usable we need to both find the right experience that matches the customer’s Job To Be Done and deliver that experience. The technology we employ (be it 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 the Tech circle 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.) whose 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: 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 circles
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, one of Marty Cagan’s adjectives maps to the two weaker circles of that PM:
- 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 be vigilant to related pitfalls in their work, and focus skill development efforts in his/her career development; and
- the organisation where he/she belongs — to make the 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 also be interested in the followup story “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 maintain the truthfulness to what I did (not) have in mind when I first wrote this in 2017, I didn’t add to the story the improvements reflected on 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.