Written by Adrienne* and Alexis

When I first started at Google, I thought the role of a product manager was simply to define the product vision and then work with my team to execute on it. I realized soon after that the most effective managers do not simply think of products and then launch -- at their core, what effective product managers do that newer PMs do not do, is that they think of setting the right hypothesis as the most important step, and organize their time testing it well.

They think of this as the most important thing to do to remove risk for success of a product launch. While a newer PM may begin by simply defining a list of product features, and corral the team to build those, a more experienced PM asks: what are all the underlying hypotheses necessary for this opportunity to succeed?

Example: I was working on the Chrome Team on Themes, a feature that enables you to personalize your Chrome look and feel with a variety of colors and patterns. The assumption was that users of Chrome Themes were more likely to use Chrome compared to another browser (e.g. if you love spaceships and have themed your Chrome in an outer space theme, you’d be more likely to open Chrome than say, Safari or Firefox), because the user made the space feel more familiar and inviting for themselves. Then the next question was, how do we redesign Chrome Themes as a way to increase theme usage?

New PM vs. Experienced PM

New PM: Focuses on the “what” to build

1. Brainstorms different ways to make the Chrome Theme experience more enticing

2. Narrows down a feature list to allowing users to design their own themes vs. offering a clean minimal set of preset themes

3. Spends time debating the two options and gets sucked into tunnel vision

4. Finally decides on one, and works with team to launch a product that is built on many shaky promises and assumptions

Experienced PM: Starts with the “how and why” of mechanisms that would increase usage

1. Examines the user journey and asks: what are the key levers here that affect my end goal, the # of users using Themes?

2. Identifies the levers:

   1. Discovery: How many people know about themes?

      1. Hypothesis: People are not using Chrome Themes because they don’t know about the feature -- the more people know about themes, the more likely themes usage is to increase.

   2. Quality: Are people satisfied with the quality of themes in the Theme Store?

      1. Hypothesis: People are not installing Themes because they aren’t satisfied with any of the Themes in the store.

   3. Installation: How easy is it to install?

      1. Hypothesis: People know about themes and like the themes in the store, but they are not installing Themes because the installation flow is not user-friendly.

3. Runs experiments testing each of those hypotheses

4. Narrows down which lever that would most affect the outcome and builds and launches a product around that well-tested hypothesis
   

The thinking trap

As a new PM, your scope might be a small feature. When a PM perceives a feature to be small, it’s easy to draw up the entire picture of the feature in your head and just start building it, without thinking about the hypotheses. You get pigeonholed thinking  “my job is to launch themes” and get sucked up planning the steps for launch. It’s important, however, to have an opinion and a clear “why” for why you’re making one product decision over another. That comes with starting with a hypothesis.

As a new PM with smaller scope for a single feature, hypothesis testing might take a few weeks or months. As your scope grows over time to a Director of Product role, for example, you’ll need to apply a similar type of thinking but on a macro scale, involving the company’s business model as a whole, and working through all the hypotheses could take years.

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