PM Life: What Is Product Strategy?

How to conquer the dreaded feedback: You’re not thinking strategically.

PM 101 — where we all start

When I was 22 and an APM, strategy was a vague concept. It sounded important but I wasn’t sure what it meant. My first product was Gmail and my first project was vacation autoresponder. It was a feature a lot of users wanted and success was clearly defined as shipping at a high quality bar quickly. So my job was to:

1. Think through the details so the product is designed to meet user need. (Even a small feature involve a lot of detailed decisions. I remember a heated debate on how often we sent an auto response.)
2. Project management work to help the team ship a high quality product quickly. (What are the dependencies, what are the high priority bugs? How can I help the eng team?)

That’s basically PM 101, skills all PMs need to master.

But it’s not enough (the strategic wall)

About 5 years into my career as a PM. I was working on Facebook’s first generation mobile products. My engineering team was amazing and we were shipping all the time. We embraced the Facebook motto of “Move fast and break things”. I loved my job and my team. But I kept getting this feedback:

Rose, you are great at getting stuff done and rallying a team, but you’re not being strategic.

Or this feedback which I hated even more.

For this next phase of the product, we need to be more visionary and creative!

It was frustrating and I had no idea how to become “visionary or strategic”. The biggest hurdle was being humble and putting myself in a growth mindset. I learned a lot by watching and listening to people who are great at strategy, as well as making decisions and analyzing the results of those decisions.

A helping hand — Product Strategy 101

So my goal today is to save everyone a few years by providing a basic framework for product strategy. This framework isn’t meant to be a fill in the blank worksheet. The PM role is a combination of art and science. The science comes from hard work understanding the market, the users, the team, and the technology. The art comes from intuition, experience, and our own creative spark. But it’s nice to get a little help. So let’s try to break down the problem.

First, what is strategy. Strategy is an intentional plan with priorities that gets us to a goal. We’re generally trying to answer these three questions.

• What are the specific outcomes/goals we are targeting?
• Given our goals, why are we building the products/features we are building? Just as important: what are we NOT doing and why?
• What is the best path to our goals?

Notice, we’re emphasizing a lot the why and what vs the how.

Step 1. Do the work: There is a myth that strategy comes from a “natural genius”. That we just need to lock ourselves in a room and the next iPhone will be born from a messy set of scribbles on a whiteboard. At least for me, strategy is hard work and starts with a lot of data gathering.

Here are some common questions I start with:

• What does the data say? Are there any obvious trends and patterns in the usage numbers? Usually I break usage down by user types, countries, platforms, industries to find those trends. (Note:This works well for products at a certain scale, can be misleading when the user base is small.)
• What are my users saying? Once we find the anomalies in the numbers, go talk to those users and understand why they are behaving the way they are. Often we are users of our own products, so don’t discount your own experience (although often we can over index on our own experience). This is where we are developing intuition and empathy. (Ask users about their lives/businesses/problems vs what they want you to build.)
• What is going on in the market? What are growing industries we should bet on? What are the emerging technologies and can they apply to the problem I’m solving for.
• What are we as a company/team great at? How we can leverage those assets or advantages? What are we terrible at and is that something we want to and are willing to change? This is generally how we start identifying our natural differentiators for the product.

Step 2: Define success.

What is success and how do we measure it?

Everyone usually starts with increase revenue or increase engagement. Key metrics are important but they are not the goal. A good answer takes on both the long term and short term perspective and has a strong opinion about what the world should be. Let’s use an example from a past life for me. When I was on the Gmail team, the goal was to be the best email service in the world. The success metric was active users. That was a noble goal but by defining the goal this way, the team missed major opportunities like mobile messaging (Whatsapp/Messenger) or small group conversations (Slack, Facebook Groups). By defining success as email, we spent a lot of time chasing features of current email systems vs new paradigms of communications. (btw hindsight is obviously 20/20 and Gmail is still very very successful.)

So how can we have avoid being short-sighted? Again, I will answer a question with more questions :P.

• What is the mission statement for our team? Why does it matter and how does it tie to a greater mission statement if we’re part of a bigger team/company? A good test is to say out loud: “What would the world be like if <insert mission statement> was true?” If the answer to that question feels ambivalent then the mission is probably too vague or not aspirational enough.
• What is the basic human need we are trying to fulfill? In Gmail’s case, if the team looked at communications more broadly vs focusing on email, we might have made different decisions.
• What would it mean to be successful in 6 months? 3 years? The different time horizons help you answer different questions. I love 3 years because it’s not long enough to wave a magical technology wand and get rid of all resource constraints but it is long enough to be ambitious.

Step 3. Triage: Now that you have a clear idea of success and a lot of data. It’s time to form an opinion and a first proposal. This can be overwhelming because there are lots of ideas that are good but throwing a lot of good ideas on a timeline is NOT a strategy… . Here are some common pitfalls.

1. Faster Horse: Do exactly what the <users/team/execs> asks for.

It seems like a pretty safe route to go. These are key stakeholders and even better if their asks overlap right? It’s easy to build a full roadmap based on those asks and it will make people happy in the short term. But this is a dangerous strategy that usually lead to the “not strategic/visionary” feedback. Most of the time people will ask for incremental improvements vs taking an elegant leap in product evolution. Another challenge is that making existing users happier generally leads to incremental growth. Don’t ignore this source of feedback, but recognize that this is generally going to give us our low hanging fruits and customer retention drivers not step function growth into new areas.

2. Dream Chaser: All in on one big splashy idea.

Sometimes, we are so in love with an idea that we want to go all in knowing there’s a ton of risk. This can be the right strategy if the company is small and pre product market fit. For instance: let’s go all in on VR everything, that’s the future. Most of the time, this is not the right strategy because it introduces a ton of risk without a lot of data or validation. It’s not a smart risk.

3. Redo: Let’s rebuild everything.

This is often associated with tech debt and the need to cleanup a large code base. The product version is a redesign. It can be exciting because it’s a clean slate to “do it right”. To be clear, redesigns of the product and code base are necessary but in my experience it’s dangerous and time consuming to do it all at once without clear goals and outcomes. Many a redesign have led to unhappy users (I led that one). Many a code cleanup have led to unhappy teams because in the end there was very little impact. Be careful!

Okay, I’ve told you about what not to do, but what does a good strategy look like? Here are some frameworks I go back to frequently.

1. 70/20/10

It’s an oldie but a goodie. The numbers can change, but the idea is being intentional about what percent of time/effort that go into:

• improving the existing product/business (70)
• building out medium size products/features with good validation. (20)
• long term/riskier bets (10)

This structure can help categorize ideas and understand what type of risk tolerance the team/company has at the moment. The percentages can change based on the ambition of the team and the state of the existing business.

2. ROI based

This is another classic. Basically for the amount of effort a project can take, what is the expected outcome. It can be something besides revenue or engagement such as customer happiness (low hanging fruit) , development velocity, etc. Don’t get too granular and make this a a complex math problem. Here’s an example:

I find just doing the exercise can help me refine and become more opinionated on what we should or should not invest in as a team and why.

3. Market based

The first 2 frameworks starts with an internal perspective. Another way to look at the problem is what does the market want/need and where is the growth? Starting purely from an external perspective can help us eliminate biases and find new opportunities. Of course we then have to marry that with our insider knowledge and data. Sources like the Mary Meeker reports often have surprising insights. Since I work on Google Maps, I often geek out following industry news on auto makers, on demand ridesharing companies, as well as startups in the micro mobility space to get a complete picture of the market. Market based strategies often take an opinionated stance on the future.

For example: We believe that in the next 5 years, everything will be available on demand, but because the business only works at scale, there’ll be 1–2 competitor per market. Therefore we should invest in building the enterprise platform that make on demand more efficient based on our unique knowledge of traffic patterns and roads.

Step 4: Put it on paper. In recent years, I’ve become a big fan of docs vs slides for summarizing and sharing product strategy. It forces clarity and specificity without distracting visuals. Docs also tend to stand the test of time better. Generally a strategy doc has these sections and is no longer than 6 pages ideally 2–3 pages. Template here.

Step 5: Iterate. We have done a lot of work to get to a doc, it can be scary to share it out, and to get feedback. At this point, I usually hate the comments feature in docs. But a strategy gets better when we get feedback and when hard questions are asked early. More important a strategy is more likely to be success when everyone is bought in early. As the author, try to stay in listening and growth mindset and thank your readers for their feedback. As a reader, try to add constructive feedback and assume good intentions from the author even if there’s a an extreme difference in opinions. (Don’t get into comment wars, go grab a coffee and talk live.)

Thank you and hope this helps!

So that’s it. Product strategy 101. I hope it helps de-mystify the topic a bit. Obviously real life is generally more complex and involve a lot of subtleties and constraints. Yes, it’s hard to find that balance between ambitious and interesting but also reachable. To balance our intuitions with data and be opinionated. We can also write a whole book on how to communicate strategy and get buy in from stakeholders. But like everything in life, we have to start somewhere simple.