3 key factors that make the most drastic difference in how a PM operates

Written by Adrienne* and Alexis

The common narrative is that a product manager needs to have certain qualities and operate in a certain way in order to succeed, but the fact of the matter is, these things vary greatly depending on the company you are at. I* remember when I transitioned from working at Google as a PM on the Chrome Team, to working at Tesla on the in-car experience team. I started doing the same kinds of things that worked well at Google, only to realize that at Tesla, these activities added no value.

I teased out some patterns in the things I did to operate effectively at various companies, and developed a framework.

The role of a product manager is to drive down risk and uncertainty

While a product manager does many things, the core of my role comes down to driving down the uncertainty in a set of hypotheses that are necessary for the business to succeed. There are three types of risk that could be facing a product, and these risks differ depending on the lifecycle of the company and its industry. Specifically, a company’s business, user, and execution risk change over their lifecycle, and each combination requires a different skill set to overcome. 

There were three key factors that made the biggest difference in how I operated at various companies:

1. User risk - Do people want this?

The companies most focused on user risk are generally early stage companies, still focused on finding product-market fit. Alternatively, the company could be mature, but the team may not be -- for example, a team working on unproven, experimental projects at a large tech company.

2. Business risk - Will it be profitable?

Growth stage companies have typically found product-market fit and are more focused on business risk: will the unit economics work? For example, you might have a product that everyone wants and have zero user risk -- e.g. low-cost home cleaning -- but discover that it won’t be a viable business due to high operational and customer acquisition costs (i.e. Homejoy).

3. Ops + Technology risk - Can we execute on this?

Companies with technically or operationally complex challenges tend to be at an earlier stage (e.g. Cruise, Waymo). Products that depend on a lot of partnerships to be successful also fall into this category (e.g. GoogleFi when it was starting out).

Example: As an APM at Google, I was working on a mature product and our focus was mainly sustaining our market leadership with Chrome as the #1 browser. At Tesla, on the other hand, we were still in the early stages and building a lot of 0 to 1 products with high technical risk. If I were at a startup working on giving fans a community for their Instagram influencers, there would be less technical risk and more user risk. An influencer platform is not difficult to engineer -- the main question is: do people actually want to use it?

You could imagine a matrix:

Tesla is in a high execution risk state, and you can contrast its scenario with Pinterest's scenario in a high market risk state -- do people actually want to collect pins on a website and browse through other users’ pins? And can Pinterest make this experience enjoyable? These levers change over time, however. For example, Tesla is currently focused on building a self-driving electric car, but later, they might be focused on building a platform that enables people to rent out their cars, which means they’ll have to overcome a higher level of business risk.

Here are examples of how this impacts how you focus your time as a PM.

User risk: Will people use Chrome Themes?

When I worked on Chrome Themes, the strategy was to increase user retention through personalization. A lot of the risk involved was related to users: why aren’t people using themes? Is it the accessibility or the themes themselves? This involved a lot of surveys, reviewing customer feedback, and thinking about how we might launch experiments to understand at what stage of the Chrome Themes user journey was the biggest pain point (e.g. browsing for themes vs. trying a theme vs. installing a theme).

Execution risk: Can we build Tesla Theater?

At Tesla, however, a lot of the risk in designing the in-car experience was in execution. For example when we were launching Tesla Theater, an app that allowed Tesla customers to watch their favorite shows and movies in their cars, there was a lot of risk in nailing the partnerships with streaming video providers and technical execution, with implementing all the levels of security involved in digital rights management for piracy prevention.

User risk: Will people find the Tesla Theater experience confusing?

There was some user risk in how to create a smooth Tesla Theater experience, especially in making it clear to customers whether Tesla Theater could be used while the car was in park, driving, or both. This user experience issue, however, was not the main point of failure, and bringing over a user risk mentality like I did at Google and focusing my team on that would’ve led to me ignoring all of the other important items on the execution risk side.

It’s not easy

This process is not easy -- it’s easy to rush into a situation and start launching into a set of tasks immediately. When you take a moment to step back and draw a map of the lay of the land and decide where you want to focus your effort, this discipline can go a long way to guaranteeing the success of your product.

The burden is not all on you to figure these things out -- it’s often very clear to the company leaders what the biggest risks are. But it’s not always the case for individual members of your product team. Labeling the biggest risks and focusing your team on the highest priority can often make huge differences downstream on your product launch day.

This post has also been published on www.productschool.com communities.