Marty meets Martin: connecting the two triads of Product Management
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)
n.
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 product manager being “the voice of the user inside the business and must be 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 employed, 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 the question “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:
- the product can be possible to build with the available technology, but thelatter is too expensive to hold a solid business case;
- the product can be easy and cheap to build, but entails a heavy service component (support, operations, etc.) whose cost outweighs the money that can 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
Re-use with appropriate attribution (link to https://jpgcc.eu/blog/marty-meets-martin/).
Corollary: using these intersections to become a better PM
A corollary of this can be drawn starting from Martin Eriksson’s remaining definition — 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 Business, UX or Tech. Such PMs, when they broke into product management, were typically purely T-shaped product managers: experienced in exactly one of Business, UX and Tech, and not entirely passionate (yet) for the remaining two.
If we employ the framework I presented above, with Marty Cagan’s three adjectives, one of Marty Cagan’s adjectives will map to the two weaker circles of such developing 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.
Re-use with appropriate attribution (link to https://jpgcc.eu/blog/marty-meets-martin/).
Such perspective can be quite useful to both:
- the developing PM — to be extra vigilant to related pitfalls in their work, and to devise where to focus skill development efforts in his/her career development; and
- the organisation where he/she belongs — as a way of best leveraging their strengths and coach them to develop upon their weaknesses.
Even established product managers can surely take advantage of this framework to better understand how any unconscious biases brought by their own particular background/experience can be a source of shortcomings in 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!”.
(The full version of this article is also available here.)
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 to do minor tweaks to 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 have (and didn’t yet have) in mind when I first wrote this in November 2017, I didn’t add to the story the improvements reflected on the talk (namely, 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.
