The tension between First Principles and Product Sense
The two greatest assets of a product manager are at odds with one another.
One you get over the shock learn the basics of Product Management, there are two things that come up as distinguishing mid to senior PMs. Those are “reasoning from first principles” — the ability to re-examine the basics and (re-)reason conclusions, and having a “product sense” — the ability to quickly, innately, choose the right course.
It doesn’t take much reflection to see that those ideas clash. Let’s dig into them, and see if we can reconcile in practical ways.
Definitions
First, let’s define the two terms. These are pulled from various sources, but consider them my definitions for the sake of this discussion.
First Principles
“Reasoning from first principles” goes back a long way, to Aristotle and the Greek philosophers. The idea was to break down complicated problems into basic elements and then reassemble them from the ground up. It should help you deepen your understanding of a subject, as you can see the reasoning behind conclusions and not just the soundbite. (I highly recommend this article on fs.blog, a resource I’ll review in an upcoming post).
An obvious objection is that modern product development and companies (humans) in general are complex, not complicated. This refers to the Cynefin framework (another upcoming post), but the distinction is that in complex systems all the components are tightly interrelated and cannot be examined in isolation. One requires systems thinking and other approaches. Still, you can look at inputs and history and try to reason as to why things became as they are — what were the small decisions along the way that created the current situation.
Another difference, is that when Aristotle spoke about First Principles he was referring to mathematical axioms — foundational, incontrovertible truths. But this is almost never the case in product development. And while you should question your assumptions and you can keep digging deeper just like 3-year-olds on a Jobs To Be Done bender, there is a limit on the practicality of this approach. At some point you’ll have to accept things at face value… Which does make this whole approach a lot more hand-wavy than some Silicone Valley pundits would like to present.
Product sense
Product sense (taken from various talks by Shreyas Doshi) is the ability to innately see what’s “right” for the product, what would resonate with users and work for the business, without having to slowly reason through all the minute decisions. It’s making the right decision (usually) in the face of ambiguity and complexity. It isn’t a born ability, but a skill which usually evolves after some time you have been in charge of the same product, or generally in the same industry. When you’ve spent so much time talking to customers, users, industry experts, et alia, that you understand their context so deeply that when presented with a new option you can quickly categorise or decide whether it fits or not.
To build this deep understanding of context, you need some empathy (with external customers and users, as well as with internal stakeholder on how the business operates), you need to know the domain (from physical environments to legal restrictions), and a touch or creativity to imagine what might be possible.
So Product Sense is effectively a deeply qualitative property. There is no amount of “data” that could drive it, you must immerse yourself in the context of your users and business, and apply some creative thinking about what migh be possible. It also means that you can’t have it coming in the door, but have to spend time getting to know your company and its customers.
Challenges
As we can see, it seems like these concepts clash. Thinking from first principles requires you to stop, dig deep, evaluate all original causes, and see if you can reconstruct the situation in a different way. Product sense, on the other hand, almost relies on “System 1 Thinking”, letting out subconscious come up with a (hopefully correct) reason quickly.
This is partly why SMEs often aren’t good product managers — they’re so embedded in a domain, it’s hard to examine the basic assumptions. Once they’ve identified a problem and possible solution, they tend to assume that all other users are like them (after all, they’ve been there for years), and by this lose empathy and openness to varying contexts.
It seems like product sense would grow out of first principles thinking, by graduating from from being a beginner who has to reason through everything to someone who can come up with the right decision more often than not. But, luckily, this isn’t quite so.
How to reconcile
As product managers, both are useful and important. It’s critical to understand when to use each way of thinking, and how to force yourself to do it (rather than fall into the wrong type by rote).
First, the above description of product sense arising out of first principles thinking isn’t correct. Rather, both come from the same source, but are applicable at different times.
Let’s start with beginner mindset — and by this I mean being like that annoying 3-year-old asking why. When you’re a beginner, you’re learning. If you don’t just accept the first answer but dig deeper, you will eventually build a more comprehensive understanding of the situation (leading to product sense), but you can also reflect upon your learnings, map your assumptions, and question them (thinking from first principles). But you can’t keep pestering people with “why” or questioning every single assumption — you have to do it in stages, as your knowledge grows.
The most important part of learning is the reflection. Stopping and taking the time to stand back and examine events and reports enables processing the information and learning in general. You have to know not just “how” to think from first principles (ie question an assumption and see what might change if it were wrong), but also when this is needed, which assumptions to question, and how to validate your new mental construct.
In essence, knowing when to apply first principle is qualitative, just like product sense. Reflection allows you to choose which of these tools are appropriate at a given situation.
I can’t give you an exact rule (if it was that easy, ChatGPT could do it 😜), but consider the magnitude of the decision (eg one way doors), the information you have already gathered (from all the hours you spend with users and others), why these might lead you to lean one way or another, and — of course — what are you trying to achieve in the first place.
If the objective is to move fast, to unblock dev teams, to disseminate learnings across the organisations, then having your subconscious mind come up with a course of action or a key reason is probably great. If, upon reflection, you aren’t getting the results you expect or want, then perhaps it’s time to slow down, map your assumptions, and reconstruct a different, considered approach.
I hope this all makes sense (and feel free to comment below to spark further discussion). But the idea is that you must always:
Immerse yourself in the context (user, business)
Take time to methodically reflect, as well as process in the background of your mind
Know when to “just do it” and when to go back to basics
Great article, mate. I’m a big fan of both approaches - but when the 2 collide, I often go with my gut. Thanks for this refresher/reminder of these 2 principles. Hope you’re doing great 😉👊