Product Management from First Principles
22 September 2019 ‧ 4 min read
First principles are a philosophical / logical concept originally stemming from Aristotle. A first principle is “a basic, foundational, self-evident proposition or assumption that cannot be deduced from any other proposition or assumption”.
Thinking from first principles is helpful if you are trying to improve upon the status quo. Once a set of first principles has been established, you start deducing derived concepts from them that you know to be true, without making wrong assumptions or imperfect analogies.
If you want to innovate and break prevailing conditions in the marketplace with your product, then thinking from first principles is often helpful since you want to break non-existing constraints that everyone else thinks to be true. In this article, however, I want to talk about applying first principles thinking to the craft of product management itself, in order to improve our practice without following fads or getting stuck in the status quo.
Some first principles that I've found to be useful about product management are the following:
- Value must be created before it can be extracted
- Success equals business/customer/user outcomes
- Real-world behavior is (the only) proof
- Most improvement ideas fail
- Competitive advantage matters
A bit more on each of these in the following.
Value must be created before it can be extracted
This principle sounds a bit abstract, but has concrete implications for product development. The proposition itself is straight forward: Where no value has been created, there generally is no way to extract any value. (Of course, it is possible to extract value without creating it, but it generally involves illegal means like fraud or theft.)
For product management and product development, this means that solving customer and user problems is the most important goal—if you are not getting better at solving those problems, you are not creating additional value, you are just optimizing how you extract the value that has been created.
There is of course value that is created but can't be extracted because there is no willingness to pay for that value. Early in the life of a startup, right after you have proven that you are solving a real problem, you therefore have to prove that there is also a viable business model that goes with said value. After it has been proven that the value can be extracted, however, you will generally need to keep working on creating additional value (by solving the same problem better, or taking on adjacent problems), otherwise your potential for additional value extraction (= revenue, in the end) is limited by the value you are already creating.
Success equals (business/customer/user) outcomes
This principle completes the previous one: you cannot call your product, or any change to the product, a success unless it produces positive outcomes for the business, the customer, or the user. Simply shipping something doesn't change anything in and of itself. Therefore, as a product manager, you are also only successful if the work you do contributes to creating these outcomes.
The well-known maxim ”outcomes over outputs” directly follows from this principle: if success means outcomes, then you should measure outcomes, not output (the latter being something like how much you shipped). Measuring outcomes (especially for the user / customer) can be hard, but that doesn't invalidate the principle.
Real-world behavior is (the only) proof
This principle somewhat qualifies the previous one, and is not entirely self-explanatory: It means that in order to prove the success (i.e., the positive outcomes) of a feature, you need to change real-world behavior of people (e.g., your users and customers). The most tangible and immediately understandable behavior that is proof for an outcome is ”a customer pays you for your product”. That behavior is evidence that the customer valued your product, in other words they believe that it solves a problem they have, or they wouldn't have given you money.
”Real-world” behavior also means: someone telling you in a user interview that they would pay for the product doesn't count. How someone interacts with your prototype doesn't count. Those things can give you an indication, but they don't prove anything.
From this principle you can also deduct that you need to determine success by tracking this kind of real-world behavior through measuring KPIs over time or through A/B testing.
Most improvement ideas fail
Alright, with this principle I am cheating a bit. In contrast to the others, this one isn't self-evident. However, it's based on observation across a lot of companies and summarized by Marty Cagan in his inconvenient truth about product:
[…] at least half of our ideas are just not going to work.
While this isn't truly a first principle, I find it useful to regard it as one, because a lot of useful best practices can be deduced from it: for example, validating solutions early and often—for example through value and usability testing with prototypes—is paramount in order to not waste resources on an idea that's not going to deliver the hypothesized value. Similarly, properly defining (and prioritizing) problems, not just solutions, is critical, since a solution idea that didn't work doesn't invalidate the problem itself.
(Only) competitive advantage matters
This principle perhaps looks even more obvious than the others: of course competitive advantage matters! However, keeping this principle in mind is very useful in order to not only think about how you can improve your product today (in terms of solving user and customer problems, and extracting value for the business), but also how you can defend that position in the future.
Competitive advantage, sometimes also called “unfair advantage” in VC parlance, means an advantage over the competition that is defensible (not just “being there first”). Good competitive advantages are things like network effects, high barriers to entry like investment requirements or switching costs, patents and licenses, or even just a very strong brand.
The takeaways for product development are tangible: Even if you constantly improve how you create value for the users, you will not gain a sustainable edge, unless the improvements are linked to some form of competitive advantage. Prioritization decisions between various ways of improving the product should involve evaluating the potential for creating competitive advantage.
With these first principles in place, you can start making deductions about the way you approach product management and product development. Do you make assumptions that go beyond these principles that are not self evident? If so, how do you know they are right? If you have doubts about their accuracy, perhaps you should test them or think about what you would do differently if the assumption didn't hold. That's how you can use first principles to improve the way you think about product management.
One small note: None of these principles cover the work of a product manager as part of a team. The reason is that I couldn't come up with true first principles that would apply in the realm of team work—for anything that I came up with, I could think of a counterexample.
If you liked this article, feel free to follow me on Twitter for more thoughts and interesting reading about product management.