Always attempt to break down your problems and assumptions into their most basic truths.
If you are in a new role as a product manager, on a lot of occasions you will be given an already well defined problem and some possible approaches to solve it - you are expected to just get things done. You then end up putting your entire focus on the solutions and how to get engineers to work on it in the next sprint. This is even more true if you are a PM in a big company where everyone already seems to "know" what the problems to solve are.
Here are some tips and observations that maybe useful :
1> Infinite Regress and Occam's Razor
Some of your attempts to understand things in detail would end up in Infinite Regress. This situation is even more likely if you are working as a PM for a tech product and don't know how to code. I am not advocating that all PMs should be engineers or should know coding but it is not very difficult to read up and understand the tech stack your product works on.
"Dimitri: If Atlas holds up the world, what holds up Atlas
Tasso: Atlas stands on the back of a turtle.
Dimitri: But what does the turtle stand on?
Tasso: Another turtle.
Dmitri: And what does that turtle stand on?
Tasso: My dear Dimitri, it's turtles all the way down ! "
So an attempt must be made to understand the stack and the viable / new alternatives available in the market. Will allow you to understand what the turtles are standing on :)
------
One peculiar feature of philosophical questions is how people eagerly offer answers that miss the point of the question altogether. The same can happen when as a new product manager you try to dig deep and reach out to people who have been in the company for a while. People will give you very complicated explanations but remember sometimes the simplest explanation is the right answer (Occam's Razor)
"Dimitri: I ask you one simple question, and you give me ten different answers. It's not exactly helpful.
Tasso: If it's help you want, go see a social worker.I hear they've got loads on them in Sparta.
Dimitri: No, what I want to know is which answer is true?
Tasso: Aha ! Now we're getting somewhere
2> Using First Principles in your Product Roadmap
But first, what is first principle thinking? A first principle is a“basic, foundational proposition or assumption that cannot be deduced from any other proposition or assumption.”.
Product Managers at all levels can use First Principle thinking to bring about a step change in results.
Thinking from first principles is very helpful because then you can break non-existing constraints that everyone else thinks to be true.
Dig Deeper: If you take a new product role in a startup it is very likely that the founders hired a product manager after the company got some early traction. Naturally they assume they know what needs to be done (and how) since they already saw success with their approach. But they could be wrong. Things can change as the company starts going after a different type of user ( geography, demographic etc. ) or just because the product starts getting popular and people expect more ( security in Zoom etc. ). As a PM you should try to go deeper and keep stripping things back until you reach the real reasons why something needs to be done a particular way. That is how you will be able to build a better solution. You may find it even more difficult to dig deeper if you are in big firm. There are some "truths" which would now be considered a given but you should not let that stop you from questioning things more. Be prepared to piss off a few people !
Question your "beliefs": A bigger issue can be that you have solved a similar problem in the past and you know how to do it again. A good exercise is to simply write down your current assumptions about the problem and then see how many of them you can prove to be true. Rene Descartes came up with a method now called Cartesian Doubt. He realised that the only way to make sure he wasn't holding any false beliefs was to disbelieve everything, at least temporarily. He offered this as an analogy:" Imagine you have a basket of apples and you're concerned that some of the apples might be rotten. Since the rot could spread and ruin the fresh apples, the only way to make sure there's no rot in the basket is to dump out all the fruit, inspect each apple in turn, and return only the fresh apples to the basket." So Descartes began the arduous task of examining his beliefs one by one. This is something you should do with all your assumptions and "truths" from time to time
To Copy or Not: This is a very interesting dilemma. And the right answer is - it depends ! Instead of having to think through what to build and why a PM can just look at the best things competitors are doing and choose what fits their plan. You can't fault this approach because some of the best loved products have succeeded in creating more usage and engagement by copying features from others ( Instagram stories anyone? ). But one way a PM can put limitations on themselves is assume that no point in trying anything new as all the good ideas are taken . That can stop you from launching something totally ground breaking.
Spend more time on the Problem: Spend time analysing the problem you are solving for instead of immediately jumping into the details of the solution. Yes you are running from sprint to sprint and a lot needs to be done. But please don't jump into writing the PRD or stories without thinking deeper about what you are trying to achieve. As Einstein said “If I had an hour to solve a problem, I’d spend 55 minutes thinking about the problem and 5 minutes thinking about solutions."
Try to understand the Current Scenario: Get a good understanding of the current situation for customers. Find out how they are currently using your product and what problems they are facing. Or if the product is not launched then how are they solving their problem right now. Then work out what their desired state looks like.
The 5 Whys? Five whys (or 5 whys) is an iterative interrogative technique used to explore the cause-and-effect relationships underlying a particular problem. The primary goal of the technique is to determine the root cause of a defect or problem by repeating the question "Why?". Each answer forms the basis of the next question. An example of the technique is:
The vehicle will not start. Why? – The battery is dead. (First why) Why? – The alternator is not functioning. (Second why) Why? – The alternator belt has broken. (Third why) Why? – The alternator belt was well beyond its useful service life and not replaced. (Fourth why) Why? – The vehicle was not maintained according to the recommended service schedule. (Fifth why, a root cause)
You may not need to go to the 5th level every time though. Stop when you reach an answer which can be proved to be true.
3> Find the right Explanation (Hempel's Theory)
Hempel claimed that there are two types of explanation, what he called ‘deductive-nomological’ (DN) and ‘inductive-statistical’ (IS) respectively.” Both IS and DN arguments have the same structure. Their premises each contain statements of two types: (1) initial conditions C, and (2) law-like generalisations L. In each, the conclusion is the event E to be explained. [ Note: This is an interesting topic one should read more about]
But Hempel's Theory has it's critics and doesn't work in all scenarios. Consider this below:
1> Initial Condition: The barometer is falling rapidly. 2> Law / Generalisation: Whenever the barometer falls rapidly, a storm is approaching. 3> Explanation : A storm is approaching.
Does the barometer explain the occurrence of the storm or is it the approaching storm that explains the falling barometer?
Apply this framework to question some of the findings or results of your A/B test. Always think of correlation vs causality
__________________________________________________________________________________
In conclusion, try to overcome the bias in the "system" or in your thinking. Dig deeper and find out the real reasons. And remember these "truths" will change as the market evolves, your users evolve or when you enter a new market.
So keep asking Why? Why? Why? Why? Why?
This post has been published on www.productschool.com communities