Decoding Behavioral Interviewing: Strategies for Success

Today's memo is sponsored by Amplitude:

Did you know that the North Star Metric is the leading indicator for sustainable growth? Defining your North Star gives you a powerful tool for product development and helps product teams quickly measure business impact. Check out Amplitude's free North Star Playbook to learn more! Get your free playbook.

---

I’ve been trying to figure out what makes a great behavioral interview response – and more deeply, to talk and tell a story about the things I’ve built and accomplished. When I was earlier in my career, this felt easier – I used the STAR framework (answering interview questions in a Situation, Task, Action, Result format) and my stories were straightforward.

But as I’ve grown in my career, I realized the STAR framework alone was no longer serving me. I started interviewing with senior executives, CEOs, CTOs at companies making hundreds of millions of dollars a year for higher level roles, and I realized there needed to be a deeper level of precision in my communication, to give them the signal they’re looking for from the interview questions. I began thinking about what that meant in the context of a behavioral interview and how I talked about the things I’ve done.

Some recent inflection points I’ve had:

1. Answering bottoms up vs. top-down

When I first started interviewing earlier in my career, I had taken a question like “Tell me about a failure you had,” brainstormed all the times I had failed, and chose the best response. It sounds straightforward, right? While this bottoms-up approach worked earlier in my career, I realized I needed to take a top-down approach for the next stage in my career. 

A top-down approach is based on the skills you want to show, or the scars you want to show you have. Many candidates think back to the mistakes they made and try to fit them into a story. But a more effective way is to shape your story by thinking about what the interviewer wants to know you've gotten down, and then use that to decide what mistakes you want to speak about.

Example 1: For example, once Adrienne was interviewing with a company looking for a PM to help with 0 to 1 bets. She realized that they would be looking for signals around strategy, so from there she went to think about key skills required for shaping strategy (e.g. shaping an unstructured space into a pragmatic solution, executing on strategy and balancing planning vs. executing, navigating stakeholder disagreement) and brainstormed stories from that framework.

• Amateur PM: Thinks about all their failures and then choose one to talk about. Bottoms-up approach.

• Senior PM: Consider the company, the role, and the types of failure one might face in that role. then, they think about the types of failure (eg. look at otter) they’d run into. They make sure the answer sits in the context of the company, how their teams are structured, and the stage they’re at.

Oftentimes the instinct is to go straight into an answer. Taking a pause to understand the company, or even pushing back with a question about the type of work you’ll be doing or the way their engineering team is structured goes a long way.

Example 2: Once Alexis was telling stories about working with engineering teams. When asked, “Tell me about how you work with engineers,” Her first instinct was to answer the question right away from her experience working with large engineering teams at Facebook and how she makes sure to make engineering voices feel heard in the long term roadmapping process.

However, she quickly realized that the company she was interviewing at had a very small engineering team, and the interviewer’s intent was to understand how she might operate in that context. So instead, she discussed her experience working with a small engineering team at a startup where her focus was recognizing that engineering time is scarce.

She focused her answer on how she could be a good execution partner and help clear any blockers for the team to execute without noise by staying ahead of cross functional alignment, and giving engineering teams precise and well thought out directions and timelines so there’s minimum wasted work.

2. Tease out the noteworthy part of each story

Instead of just answering a question with a story, first think of 6 stories first, then fit them into different behavioral questions, based on the most noteworthy part of each story.

Example: Adrienne had a story about launching a 0 to 1 product where she identified the market, drafted a PRD, then hired engineers to build and execute a new product as a 1-person enterprise. She kept trying to fit it into a “tell me about something you launched from 0->1,” anchoring on the difficulty of execution and tradeoffs she had to make in what features to implement first –- but the story wasn’t clicking. That’s when she realized that this product would never reach the level of complexity of things she built at Google or Tesla. 

The most noteworthy part of this story – and the toughest part of building it – was not bringing from conception to launch, rather it was how she validated that there was a market: Is there a real need? And are people willing to pay for it? 

When she switched the frame of the story from answering a 0 to 1 execution question and anchored instead on taking an unstructured space and structuring it into a pragmatic solution (e.g. “Tell me about a time you had to make a decision based on little data,” “Tell me about a time you had an unpopular opinion and had to convince others of something,” or “Tell me about a time you validated market demand for a new product,”), the story became much stronger.

• Amateur PM: Takes a product or feature they launched and tries to fit it into a question. Doesn’t think about what’s noteworthy or what scar they are trying to show.
  → The story feels plain and ends up being unmemorable.
  

• Senior PM: Thinks about what the most interesting or toughest part of a story was, and use that as a lead-in for when to tell the story.

If a story is not feeling right, be curious and open-minded about what part of the story is actually noteworthy, and repurpose it for answering another question. 

3. How to properly add color

Having done a lot of mock interviews, I noticed when some people first start telling stories, they leave out a lot of color. They’d say something like, “Then I wrote the PRD and got engineers to build the product.” To them, it seems like an obvious product development process.

Then on the other side of the spectrum, I noticed some people would add unnecessary color, “I met with engineers and designers, prioritized the list of features we should work on according to the most common use cases and the effort required to implement.”

What you are really trying to do here is to give the interviewer a high confidence signal that you have experience solving problems that the new company is hiring you to solve for them. So it’s important to paint a picture for them, enough so that the interviewer can draw a connection in their head about your situation and what the interviewer is experiencing in the company you’re applying for. And you do this by highlighting the critical decision points that were important for you, but also the key questions the interviewer’s company is grappling with themselves, either in the past or currently.

And often you can do this by asking yourself, with any product:

What are the three most critical inflection points that shape what the product is going to look like and how the market is going to respond to it? 

These are the things you want to articulate.

Example: When Adrienne was sharing the launch of Tesla Voice Assistant, instead of describing all the motions of the things she did to launch it, she instead thought about the three critical decision points that would shape how the market would respond to the new product. The first was creating a prioritization guideline for what commands to focus on developing, the second was determining the key metric to guide success of the product, and the third was the development journey from the MVP, iteration, to launch.

• Amateur PM: Adds either no color or too much color everywhere. Ends up coming off as either a big picture person or a process person.

• Expert PM: Adds color in the right places by asking what the critical decision points are that shaped the product. 

Getting good at interviewing unlocks more opportunities

A lot of people think behavioral interviewing is just a matter of factually recounting things you’ve done, and forget that that’s only the first step. The final and most important step is crafting a narrative around it in the context of the the company you’re interviewing for, so that your message lands. The key to your message landing to the audience (the interviewer) is providing the context and color, and also adjusting the way you talk about your story so that the interviewer can easily draw a connection to their current lives in their respective roles and companies. 

The skill of being a PM is very different from the skill of interviewing. Behavioral interviewing isn’t necessarily about the things you’ve done – it’s about giving the interviewer a high confidence signal that you can do the job which is a different skill from product management. And the fact of the matter is, the better you get at this skill, the more and better opportunities you will have – so it’s great to learn both.

---

Have an interview coming up and want coaching?

Adrienne offers interview coaching to candidates applying to product manager roles. She’s a former PM at Google and Tesla and has given over 100+ mocks, helping her candidates receive offers from top tech companies including Stripe and Lyft.

Practice 1-on-1 with her and have her guide you on how to ace product management interview questions at top tech companies.

Book an interview coaching session here.