5 Ways to Level Up Behavioral Answers
When interviewing for more senior roles, we need to level up our answers to sound more senior. For many, we know it when we hear it but we can’t quite quantify what it takes to level up our answers. This article addresses those concerns with 5 elements you should consider adding to your next answer if you are trying to go from an L6 to an L7 or L7 to Director. Or if you are a leader who is just a little rusty interviewing.
Scope
Business Impact
Visibility
Conflict
Scalability
Let’s Dive in…
Scope: The extent of the area that a product manager owns.
Some easy ways to demonstrate scope are the team size (count and function) and the cross-functional makeup (partner teams) required to get the solution launched.
Example: I led a 100+ cross-functional person team, including product, engineering, data science, design, user research, human reviewers, customer support, business development, and sales. I had to negotiate across 5 different partner teams, including: ads bidding, ad serving, keyword classifier, organic search design, advertiser interface team, and organic local search.
Business Impact: The effect of your actions and decisions on your organization's performance.
The most common way to illustrate this is to “show them the money”. But this can also be displayed in engagement measures, reduction in cost, increase in productivity. When you can’t attribute your direct impact on revenue, don’t despair, there are other ways of showing your impact.
Example: When I owned new merchant (merchants with less than 90 days on the platform) growth at Amazon, I drove nearly $750M in additional attributed revenue for merchants during their first 90 days on the Amazon Marketplace. We increased the number of successful merchants, those with at least 10+ sales per year by 20%, and increased available inventory by 15% YoY.
Visibility: The state of being seen.
The best way to demonstrate this is to mention the level of the executives you presented to or reported directly to for your initiative. (Yes, the name-dropping thing I hate is still required. But make sure it is in service to your story not just waved in the interviewer’s face.)
Example: To get buy-in for my launch, I had to get buy-in with the Director of Engineering for YouTube Measurement as well as the VP of Product for Measurement across Search Ads and YouTube Ads. I did so leveraging 4 communication tools: Talking Points for my Leadership, XFN Product Updates, Strategy Document, and 1:1 Meetings (with the leaders as well as those who influenced the leaders I needed to reach).
Conflict: A serious disagreement or argument, typically a protracted one.
Product Leaders who own important products and product decisions will always encounter pushback and conflict. If the initiative were easy, they would have given the work to a more junior product person. A senior product leader needs to display the ability to handle conflict, ideally with a repeatable framework.
Example: When working on Google Local Search ads, where I was responsible for $500M in ARR, I was tasked with driving new sources of revenue. When I joined the team, a partner engineering director had about 10+ ideas on what the next big bet was going to be. As the product leader on the team, it was my job to prioritize our efforts. In this case, my engineering partner was disappointed and frustrated my with prioritization decision to kill one of his ideas: promoting ads for telephone calls.
The essence of the disagreement stemmed from different historical context. I came from 15+ years working in retail. My engineering partner had found $500M in revenue the previous year, long before I arrived, by looking at user behaviors and monetizing those behaviors by creating a new ad format for all activity over a certain engagement threshold.
When we reached H2, and it was clear our revenue goals were in jeopardy, my engineering partner got frustrated with my prioritization decision and kept bringing up his concerns that we could make our goal if we just created an ad for phone calls. I realized quickly I had to provide (1) more data to back up my decision and (2) get xfn feedback on the idea to address the disagreement head-on. I could see that my engineering partner was very frustrated and this was likely to be heard by Directors and VPs in the organization if I didn’t act quickly to get control of the narrative.
To address my engineering partner’s concern, I reached out to product teams that owned the phone number product, including 2 product directors, to get their points of view. I also spoke with customer service and sales teams, everyone repeated what I was telling my engineering partner: retail shops do not want to pay for phone calls, they are necessary evils but not something they want to even test ROAS on. Further complicating things were sales goals held by other teams that would have been diverted if we added the phone number option to our roadmap.
After getting the cross-functional partners to share their POV with me 1:1, I set up a quick meeting where my partner could hear the other voices in the room. I did this because the data wasn’t enough to convince my partner. Even though I knew I was right, and I had the data to defend my POV, if I didn’t address the pushback, it would have led to a loss of trust with executives I needed in the future. In the end, going the extra mile to take his concerns seriously and by bringing in 3 to 4 experts on the product area to a group meeting, I built trust with my engineering partner. He appreciated that I got facts and came to respect my product instincts on future initiatives. While it was an expensive use of my time in the short term, it built a foundation of trust for future discussions.
Scalability: the capacity to be changed in size or scale.
Senior Product leaders make prioritization decisions with scale in mind. We either make tradeoffs to build a scrappy solution quickly to prove the idea before building a scalable solution before we have a strong hypothesis on what form will achieve product-market fit (PMF). Or, perhaps, because we want to test out the workflow to allow for better system design decisions once we know the extend of our data needs. Or, we make crucial decisions on what to work on next, keeping scalability in mind, we might sacrifice the short-term for the long-term if we made a bet on scalability, and so we had to build the solid foundation before building the much-desired feature.
Example: While working on Yelp’s experimentation platform, I made the call that our team had to bite the bullet and own the data transfer for the largest team: Search. It put other initiatives on hold, but if we waited for the Search team to prioritize the work themselves, while it would have taught them how to clean up their data, it would have taken twice as long and delayed the onboarding of 7 other product teams to the new experimentation platform by 6 months.
Here is an example that trys to include it all 5 elements:
Scope: hundreds of functional and cross-functional stakeholders
Visibility: Directors and VPs
Business Impact: $500M to $1B ad revenue
Conflict: Definition of Demand
Scalability: Unlocking new ad formats/surfaces
When I was working on YouTube’s Ads Measurement team, I was tasked with coming up with a 3-year strategy for the team that included 25+ engineers, 5 business development partners, 10 Sales teams, and 20+ ads platform client teams, including 2 public-facing demand-side ad platforms with their own public relations teams that were interested in the outcome of my plan. Once this was built, it would unlock a new ad surface for YouTube and major demand-side ad platforms that could lead to billions of dollars of future revenue and help Google stay in the game as Spotify was making major moves in audio measurement.
I used a two-pronged strategy to get buy-in. First, from the very early stages, I shared my research efforts weekly with those in my most immediate circle, widening the circle as I got buy-in from different cross-functional teams and partners, like YouTube Music and Podcasts, as well as demand-side Ads platforms with advertisers hungry for new formats.
Then, I presented my ideas for a $500M to $1B incremental ad revenue opportunity over the next 2-3 years, to the Director of Engineering for YouTube measurement as well as the VP of Engineering and Product for Ads Measurement in both 1:1 and group settings. After presenting my plan, I got buy-in and a verbal go ahead.
But about 6 weeks into our phase 1 work, I started hearing from my manager and a business development partner, that one of the executive that approved the strategic plans was having second thoughts. This engineering director was instrumental in keeping our strategic plan funded. They didn’t see the value, despite the fact that I had strong financial models attached to my plan.
My first step in addressing his concerns was to talk to the engineering leaders who reported into the director. I asked about the concerns, pushback and history of this leaders’s preferences. With this information, I scheduled a 1:1 with the Engineering Director to give them a chance to explain their concerns and offer up my willingness to acquire any additional evidence or cross-functional buy-in. It was during our 1:1 discussion that I discovered some historical context to explain the conflict and pushback. In the not-so-distant past, a number of projects got pulled at the last minute if there were not at least 2 other engineering leaders at his level in at least 1 or 2 other organizations co-sponsoring the initiative. I then spent the next 2 weeks, getting my partners at the product level to help me network with the engineering leads on their teams. I pitched my product to them and brought to their attention what we had been doing. I got them to give me their support verbally and facilitated a discussion with them and the engineering director, who had hesitated. I soon had the support from that engineering director. They went from hesitate to sharing the teams ’s milestones at the VP level of the Ads Measurement organization moving forward.
As you can see by the examples, I used numbers, counts, context and titles to illustrate the size of the projects and products I owned.
