Mastering Execution as a Product Manager
“Ideas are easy. Execution is everything.”
This was once said by the Global Head of Operations and Strategy, and now CEO, of the late stage startup that I was working at as a nod toward the John Doerr’s mantra. The Global Head said this line as he was recounting to an audience his time at Columbia University working on a product idea with his friends. This idea was a social network that can connect people in a university environment. Sounds familiar?
He strongly felt that he was one of the early group of people working on university social networks, perhaps, even before Mark Zuckerberg at Harvard. Of course, we all know who won in the end. The Global Head shared with us his mistakes of managing a product and how these mistakes eventually led to his social network being swallowed, like many of his competitors, by what would become Facebook today.
This is one of the many stories I have heard where a team of creative folks can come up with a product idea with high potential but fail to seize the opportunity. Hearing about these experiences, I have learned that it was not enough to just have a strong vision and creative ideas as a Product Manager, but I also had to sharpen my execution abilities to truly deliver impactful products to users.
In my opinion, there are three key elements to execution: problem solving, prioritization, and decision making.
Problem solving refers to the ability of approaching an ambiguous problem, breaking it down to smaller pieces, and eliminating assumptions to bring clarity. Prioritization means working on the right problems at the right time to maximize the amount of deliverable impact. Lastly, decision making is the skill of being able to weigh the benefits with the drawbacks to improve the likelihood of success.
In this article, I would like to share some of my tips and mental models to hone your abilities in each of these areas within execution.
Let’s start with problem solving.
Nearly every project handed to you as a PM will have a certain degree of ambiguity. Of course, the more experienced you are, the larger the scope and the more ambiguous your problems will be.
In the face of ambiguity, a PM’s problem solving ability is not tied purely to having the right answers, but to asking the right questions. Clarifying the unknowns is the key to problem solving. During this stage of product development, you should make it your key objective to learn about the problem space. You should learn about the objective of the product for your company, the potential users of this solution, the jobs to be done, and the reasons the product matters to the users. Only by knowing these answers can you build a product that deeply meets users’ underserved needs and helps push your company’s vision forward.
There are two frameworks that I have had success with: the 5W1H and the 5 Whys.
5W1H stands for Who, What, Where, When, and Why and How. This framework has been introduced to us since our primary school days, but I have found it extremely effective in clarifying ambiguity when building new products as a PM. Let’s see an example of this.
Developing a new generation electric scooter
- Who are the target users we are designing this new scooter for? Will it be for commuters or action sports athletes? Are tourists in scope for this product?
- What do we envision as the final product here? Will this be a new ground up product or are we developing feature enhancements to our legacy platform?
- Where do we envision launching this product when at full scale? Do we have any pilot markets in mind? In which countries do we expect regulatory problems for this product?
- When should we plan to launch this new product? Will we have the engineering and design resources to get this product developed in time? Does the program timeline capture holiday time offs?
- Why are we as a company developing this product? Is it to expand our commuting market share? Are we launching this product as a defensive play to a competitor who launched a similar product recently?
- How are we planning to realize this product vision? Will we be approaching this with the standard design, develop, and test product development model? Is it viable for us to do a joint development with a third party firm?
As you can see, using the 5W1H framework does not mean you can only ask who, what, when, where, why and how questions. The framework is meant to be a mental checklist during the discovery phase to better understand the problem at hand by clarifying unknowns and teasing out assumptions or risks.
The 5 Whys is another problem solving framework that I frequently find myself using. This framework was developed by Toyota back in the days to understand why new product features or processes were needed within their manufacturing plants in order to improve manufacturing methods and make them leaner. The heart of the framework is that, by asking why 5 times. a person can draw connections between different pieces of information that may not be related at all and be able to deduce the root cause of a problem. Here is an example.
Monthly revenue is down by 25%
- Why is our monthly revenue down by 25%? Because 10% of our users is not paying their invoices
- Why are 10% of users not paying their invoices? Because they did not realize there are open invoices
- Why do they not realize there are open invoices? Because the invoice feature on our platform is not displaying invoices to some users
- Why is the invoice feature on our platform not displaying invoices to some users? Because we are having some data loss within the live data stream
- Why are we having some data loss within the live data stream? Because we are currently migrating data sources from A to B
Impactful problem solving requires having a strong understanding and having strong understanding comes from asking the right questions.
Albert Einstein had a famous quote:
“If I had an hour to solve a problem and my life depended on the solution, I would spend the first 55 minutes determining the proper question to ask… for once I know the proper question, I could solve the problem in less than five minutes.”
Next, let’s move on to prioritization, which is another key execution skill that PMs need to master.
The heart of prioritization is focusing on the most important problems to solve. No matter if you are at a start-up or a megacorp, you will always encounter limited resources and unlimited product opportunities to work on. So, the key here is maximizing the impact you can deliver while understanding resources and constraints.
To prioritize the different initiatives on my roadmap, I like using the RICE framework. RICE stands for Reach, Impact, Confidence, and Effort.
RICE Score = (Reach * Impact * Confidence) / (Effort)
- Reach — how many users can this project benefit?
- Impact — how much business impact will success drive?
- Confidence — how confident are we in completing this project?
- Effort — how much development effort is needed to complete this project?
Here is an example of this framework in action
- Launching chat feature — (500users * $100/user * 45% confidence) / (30days of work) = 750
- Fixing backend bug — (500users * $85/user * 90% confidence) / (45days of work) = 850
- Improving loading time — (300users * $25/user * 60% confidence) / (30 days of work) = 150
As a PM, you can use a RICE mindset to prioritize not only your quarterly product roadmap but also your day to day tasks. Quickly jumping on any initiative pitched to you is an easy mistake which can lead to important projects falling behind and resources being misallocated, so it is critical for any PM with ambition to ruthlessly prioritize.
Lastly, let’s cover decision making.
When you make decisions as a PM, you will never make decisions with complete information. Decision making is almost like a probability exercise such as playing poker. The idea is to determine the expected value of an outcome and the likelihood of that outcome happening. You will find these probability exercises when discussing design trade-offs with your designers, running A/B tests with your data scientists, down selecting on implementation methods with your engineers, and during other steps within the product development lifecycle.
Since you will be making many decisions on a daily basis as a PM, you will need to understand the key elements of decision making: Importance, Time, Benefits, and Drawbacks.
- Importance — How important is this decision to your product and overall business?
- Time — How much time or effort should you be taking to make this decision?
- Benefits — What benefits or opportunities would a good outcome unlock?
- Drawbacks — What drawbacks would a bad outcome create?
Higher importance means more time will be needed to make a decision. Lower importance means less time needed. Benefits outweighing the drawbacks usually means higher expected value, while drawbacks outweighing the benefits means lower expected value.
Knowing where each situation lays along these 4 elements would allow you to know when a situation calls for deep critical thinking or snap judgement as well as enable you to consider the pros and cons. Hence, enhancing your likelihood of success as a PM.
With the information shared in this post here, I hope that you are able to take away new learnings about product management, feel more well-equipped to tackle different challenges, and take steps toward mastering execution.
Stay curious and make a dent in the universe!