5 First Principles Approaches to Product Management
Every product manager in the course of their career constantly encounters complex situations. These situations can include starting at a new company and having to understand the landscape in which the product resides, or resolving a request for a feature in an already complex current landscape. Whatever the case, complex situations are best deconstructed, understood, and ultimately solved utilizing a first principles based approach.
Using a first principles approach to product management is more difficult than a using a comparative approach, one where we apply reasoning based on past experiences, to solve new and more complex problems. As product managers, whether you’re starting out on a new product, or trying to understand and improve an existing product, you’re always going to have a complex situation handed to you no matter the company or users. So how do you start to determine the crux of the problem?
My approach involves using my scientific background to inform my product management methodology. Prior to working as a product manager in tech, I was a research scientist training to get my PhD in Microbiology, studying the affects of the acetylation of a global transcription factor in E. coli, on gene expression and carbon utilization (metabolism). I walked into this project knowing nothing about what any of those words listed above truly meant, similar to what product managers do when they encounter new products or ideas. However, scientists, unlike product managers, are trained in using a first principles approach to understanding complex systems. You see, as a scientist, I just couldn’t start studying the affects of an event on a system without first understanding the fundamental building blocks of that system, or how that system fits into the larger world (the bacteria), or an even bigger unknown world around it (the environment).
A first principles approach is crucial in order to understand how one problem can be tied to many factors, both known and unknown. Here, I’ve listed out 5 ways that you as a product manager can apply the same first principles approach that philosophers and scientists, starting with Aristotle in his series Physics, use everyday to unweave the tangled web that can be present in a single problem.
In every systematic inquiry (methodos) where there are first principles, or causes, or elements, knowledge and science result from acquiring knowledge of these; for we think we know something just in case we acquire knowledge of the primary causes, the primary first principles, all the way to the elements. It is clear then, that in the science of nature as elsewhere, we should try first to determine questions about the first principles. — Aristotle Physics, Book I, 184a10–21
To see a World in a Grain of Sand
And a Heaven in a Wild Flower
Hold Infinity in the palm of your hand
And Eternity in an hour
- Auguries of Innocence, William Blake
Find the grain of sand: The easiest thing to do when presented with a complex problem is to start coming up with solutions immediately after listening to the problem. That’s also the worst thing you could possibly do — so don’t do it.
To truly understand the problem, there are three questions that you must ask, or things you should keep in mind:
- The known knowns: What are the facts that you know about the current system? Identify these known facts, and use them to build your paradigm.
- The known unknowns: What are the questions you still have after examining the system? These are the next set of items to investigate and understand.
- The unknown unknowns: Biological systems always have external or internal factors that can influence the system, unbeknownst to you. To create a complete picture of your problem you must acknowledge these unknown factors in advance.
As a product manager, when I get handed any problem, I walk through the exercise listed above, and determine what I know, what I don’t know, and what I’ll likely never know. Using this approach, you’ll understand what the fundamental truths are to any situation. And this is crucial, because it allows you to build a solution from that point of truth.
T reat everything like it’s new: When you’re presented with a complex problem with multiple variables, inputs, and users, you cannot, nor should you attempt to solve the problem using an approach you used in a previously “similar” situation. Every problem is different, and the benefit of having experience shouldn’t be equivalent to using a hammer to fix everything. Rather, your experience should be reflected as a toolbox of varying approaches you can use together to create a customized solution for each new problem you encounter.
Think about the caveats to your approach: Out of every point listed in this post, this is by far the most important. Every time you identify a solution to a problem, always think of the caveats to your solution.
When you’re defending your PhD thesis, you are expected to poke holes at your paradigm that you’re actively working on building. It is the hardest thing to do — but it is so crucial, as you’re forced to think critically about the model that you are creating.
This is something that I’ve rarely seen done in tech. In our aim to execute fast, build it and see what breaks, we miss an incredibly crucial step of critically questioning our own approach. The next time you find yourself handing off user stories to your dev team, ask your team these questions:
- What parts of the problem won’t this solution address?
- What parts of this problem will be exacerbated by this solution?
- If we implement solution A over solution B, what am I gaining/losing? What are the caveats to each approach?
The beauty of constantly questioning your team in this manner is that it forces everyone on the team to think critically about the solution, through the lens of rational thinking and not through the lens of emotional based thinking.
We’ve all had meetings where certain team members are so passionate about their ideas and want to see them built into the products. And while that passion is great to have, the collective critical thought process of the team must balance it. So as product manager, gather your team together before sprints, and ask the above questions. Using this approach has pushed my product teams to accept ideas they were previously hesitant to accept because they collectively understood the rational validity of those ideas.
A caveat-based approach to product development builds consensus within your team, and this consensus and trust is crucial in your team’s ability to move fast and build groundbreaking products.
Build the smallest piece first: Once you’ve understood the complexities of the system you’re working in, and identified your approach to solving the problem, how do you decide what feature you should build first? To determine this, the engineers and I work together to identify the smallest, but most crucial pieces of the system that if built first, will allow for immediate validation of our solution.
In scientific experiments, you always have positive and negative controls to validate that your experimental approach is sound, even if the result isn’t one you expect. Those controls don’t test your hypothesis and similarly, building the first piece of your product won’t allow you to fully determine the success of your product. But, in building this small, but essential piece, you’ll get almost immediate validation that you are headed in the right direction.
Never forget the big picture: I’ll never forget the day of my candidacy defense. It was on my birthday (note: worst/best birthday ever) and I was so nervous. I kept pacing in the hallway before the defense thinking, “Did I think of all the caveats? Did I forget to include the controls? Did I state my hypothesis succinctly but thoroughly enough?” I went into the defense with 90 extra slides of supporting information on experimental techniques, data from other sources, etc. I thought I was prepared, so I went into the room, presented, and answered all the questions my committee asked of me, and then left the room for committee deliberations.
When my committee called me back into the room, they acknowledged that I had done well, that I had written up a beautiful experimental approach section, listed out all the caveats, and really thought hard about the details. However, they said, I had failed to think about the big picture. How did the all the little details fit into the larger paradigm I was trying to create? How did my small experimental tests that only assessed one small piece of a puzzle fit into that larger puzzle?
What I learned that day as a scientist, and what I still carry with me as a product manager, is that it isn’t enough to think from a first principles approach. You have to start from a first principles approach, find the grain of sand, the source of truth, or whatever you want to call it, and build from there. You always have to remember how that small piece fits into the larger picture.
Products are created in open systems. Our users live complex, ever-changing, and extremely stressful lives. So when we think of our products, we have to think of how they live not just in the context of the problem that we’re trying to solve, but also how they fit into the users life as a whole. And starting from a first principles perspective gives you the ability to start small, find the truth, and apply it to the bigger picture.
So, in summary, here are 5 First Principles approaches you can apply to product management:
1. Find the grain of sand: Work hard to discover the core of the problem presented to you and build your solution from that point.
2. Treat everything like it is new: Use a multi-faceted approach to problem solving, not a singular, used-in-the past, “I know this works because I did it at my last company” method.
3. Think about the caveats to your approach: Always question the limitations of your implementation strategy. In doing so, you’ll allow room for your team to rationally argue about various ideas and come to a consensus on the best approach to solving the problem.
4. Build the smallest piece first: Find the smallest piece of the puzzle that you can build first to get immediate validation of your ideas. This will be a huge win for your team, and will set you up for long-term success.
5. Never forget the big picture: Don’t forget to see the forest for the trees. Always think about how your solution affects the user in their larger life, and remember that you’re building something that will live in a complex, multi-faceted system.
Thanks so much for reading this! Comment, share, and 💚 this post if you like it!