3 pivotal learnings from 3 years as a Google PM

The opinions stated here are my own, not those of my company. Names are used with permission!

It’s May 7, 2019, 3:20pm, and it’s Google I/O. This is Google’s largest annual event, with over 7,000 in-person developer attendees and millions of online viewers. I’m hovering at the side of one of this year’s larger stages. To my right, the audience is shrouded in darkness. I’m waiting  for the right moment to climb the stairs, enter into the stage lighting, and accept the slide-controlling “clicker” from my colleague. Then, I’ll speak about ARCore (Google’s Augmented Reality smartphone platform) – including giving a live demo of some of our newest, neural net-based tech. All of it is being live-streamed and recorded. I’m nervous and excited!

That experience (including the relief I felt after the live demo went well!) is one of my favorites as a Google PM. Moments like these are emotional highs. It’s validating and invigorating to finally reveal features my colleagues and I have poured time and energy into, and to see our customers react with delight. I’m proud of the work I’ve done at Google so far, on the Google My Business and Augmented Reality (ARCore & Lens) teams. 

We often have good visibility into other people’s successes. This is true both in our personal lives (via Facebook and Instagram) and in our professional lives (across LinkedIn, networking, and the news cycle). But this limited visibility can lead to feeling like others don’t make mistakes, didn’t need to grow to get to where they are, or accomplished things all by themselves. Sometimes, this can ultimately lead to impostor syndrome, especially for those who don’t see themselves represented in their chosen professions.

But the truth is that you don’t have to be perfect at everything from the start to do great work or to be an effective PM. So I’d like to contribute to the visibility of that truth by sharing the best constructive feedback that helped me get here. (Many thanks to my managers, who have really invested in my growth, and by virtue of their varied backgrounds have done so in different ways!)

1) Challenge push back

My first manager, Amir Fish, encouraged me to challenge push back. In those first few months as a PM, I sometimes felt that I was surrounded by people with decades of experience building successful products. If one of these Super Experienced Teammates said “no” to an idea, decision, or timeline, wouldn’t they have watertight reasons for it? 

Amir encouraged me to dig deeper, and analyze the deeper assumptions that led to that impasse. Here are some examples of situations with push back, and some potential ways to respond:

• An engineer might refuse to commit to a timeline because they’re thinking of nice-to-have features as must-have features, or have a specific way to build the feature in mind. Next steps could include explicitly removing requirements from scope or collaboratively exploring faster ways to implement.
• A designer who disagrees with a User Experience decision might be doing so based on user research they read that I had not. The next step would be to read and understand the novel research and the designer’s interpretation of it. In this case, I would not be surprised to learn that my initial understanding of the problem was incorrect!
• Leads might not agree with the magnitude of impact of your proposal. Next steps could include reframing the proposal, gathering better supporting data, or agreeing to conduct a small Live Experiment (launch the feature to a small number of users) to see what the data shows.
• Partner teams might turn down a request for collaboration because they have other goals. A next step could be to see if there are timelines in which the goals do align, identify another “champion” (e.g. a peer Engineering Manager) for the proposal, or to escalate to the leadership level where those goals are negotiated against each other. 

To be clear, challenging push back doesn’t always ultimately unblock progress, but it’s always led me to more thoughtful decisions.

2) Frame data and analysis in a narrative arc

My second manager, Ben Schrom, taught me to tell better stories. I had a tendency to lead with data and analysis – not a terrible foundation. But science tells us people often decide based on emotion (and justify later with logic), so weaving data and analysis into an emotionally compelling story about user impact is often more effective. Ben taught me to explicitly apply narrative arcs and the traditional storytelling roles of villains and heroes when talking about products.

We applied these structures to the I/O talk and live demo:

• First, in exposition, the audience heard about why realistic AR is important – to help users make decisions based on what they’re seeing, especially when accurate color matters, like trying on AR makeup. We explained what factors into realism.
• Second, we introduced our villain: issues with today’s unrealistic AR visualizations, with rising action as more and more issues became apparent. 
• Third, in the tensionful climax, the audience saw our hero, the new features, powering realistic AR live on stage.
• Finally, in resolution, we showed the audience a few edge cases where the hero was still able to save the day (like even when the lights are moving) and talked about how we did it (using a neural network).

These concepts can apply to telling stories about people, too. The way Ben wrote his end-of-internship evaluation for our summer intern read like a superhero story, narrating the product problems she faced and overcame! Storytelling should not replace due diligence or data, but it can really help to ground work in its impact.

3) Use frameworks for better problem-solving

My third and current manager, Vijay Shankar, introduced me to the extensive usage of frameworks. Frameworks are abstract structures that capture the salient components of something, like a product area, steps of the user journey, or approach to solving a problem. Some examples:

• The narrative arc that we talked about in the previous section is a framework for storytelling. 
• The 5 “Ws” – Who, What, Where, When, Why – are a framework used by journalists to gather information.
• The Marketing Funnel describes consumers’ buying journeys
• Some PM-specific frameworks, including the popular “HEART” approach to choosing metrics for your product: Happiness, Engagement, Adoption, Retention, Task Success

Before I became intentional about using frameworks, my approach to solving problems was more haphazard. Sometimes, I did stumble upon good frameworks. Other times, there was “wiggle-room” in my decision-making. I relied more on pros and cons lists, which are an okay place to start but usually don’t capture which decision criteria are more important. 

Good frameworks are often Mutually Exclusive and Collectively Exhaustive (MECE), a term popularized by management consulting. This basically means that the segments of your framework don’t overlap, yet they cover the whole space. I’ve found that the process of constructing a framework, especially a MECE one, forces me to be complete, rigorous, and perceptive: 

• Complete in the sense that I’ve got to think about the whole space or process. If I can think of examples that don’t fit in the framework, I haven’t constructed a model that completely describes the space. 
• Rigorous because choosing the framework components requires a precise and deep understanding of the space. For example, I’m sure that the creators of the HEART framework needed to justify to themselves: “why should Engagement and Task Success be separate categories?”
• Perceptive because constructing a framework requires you to answer: “what are the most important ways to describe this space?”

Vijay also showed me that when you finally do arrive at a satisfactory framework, it’s usually a great basis (and visualization) for both making decisions and explaining the space to others.

On Day 1 as a PM, I was not 100% proficient in challenging push back, storytelling, and frameworking. Yes, I had practiced some of this before in college and internships. Yes, I was sometimes doing these things right by sheer will and luck. But my mentor-managers helped me name these skills to work on and entrusted me with the autonomy to do so. And today in Year 3 as a PM, I’m still using and strengthening these PM skills. This work – of seeking and applying feedback – is behind shiny moments like speaking onstage at I/O, and it is proof that you don’t have to be perfect from the start.