Use PEARL instead of STAR to shine in your PM interviews

Highlight your seniority with the PEARL framework for talking about your experiences

When I was a hiring manager I was responsible not just for giving a hire/no-hire decision, but also for “leveling” the candidate. Leveling means making a decision about the person’s seniority level (and hence compensation level).

I’d start with a guess based on their years and type of experience, previous title, and where they’d worked. But leveling product managers that way doesn’t always give an accurate answer. If someone has six years of marketing experience and two of PM, how much does that count for? What about four years in customer support and five in product? Is senior PM at Zynga the same as senior PM at Google? I needed a way to sort this out.

A PM’s level is really about their scope, autonomy, and impact. And my favorite way to evaluate that is with the question “Tell me about a recent project you’re proud of.” I’ve found this to be a great way to understand how the PM has approached their job up to this point, and to probe for the potential to operate at higher levels.

At the junior end of the spectrum are PMs who have launched straightforward features. Someone else told the PM to build the feature, or it was the obvious thing to build. The PM was learning the ropes of product management—figuring out which stakeholders to loop in, how to buffer engineer estimates, catching usability issues. The PM makes choices, but those choices tend to have a right answer. This is typically APM level.

With a little more experience, I meet PMs who figured out what their team should build. They’re assigned a team, do customer research and/or data analysis, and consider their product’s goals. There was an actual choice, with more than one option, and a reason for the direction they chose. At this level the PM starts to run into conflict, or at least pushback, because they are becoming the expert in their area and have a unique, useful perspective. This is typically the PM 1 / PM 2 level.

At the senior end of the spectrum (for individual contributors), PMs have found new opportunities and done what it takes to go after them successfully. This means they’ve paid attention and spotted a customer problem or business opportunity that was being overlooked. They’ve advocated for investing in that area. They’ve convinced the leadership team to let them go after it, or found a clever way to test and launch. They drove the project forward and achieved successful results. This is typically the Senior PM level.

A counterintuitive thing about these levels is that the more your decisions were obviously correct, the lower your level.

The more your decisions were obviously right, the lower your level.

This might seem surprising—don’t more senior people make more correct decisions? Sure, in general… but when there’s a clear right and wrong answer, that’s the easy stuff. The hard stuff starts when you leave the land of “right” and “wrong” and enter the land of “it depends” and “oh I never thought of it like that.”

So, in order to highlight your seniority, you need to focus on why your decisions weren’t obvious. You need to build up all the reasons that smart people thought you should do something different… until you came along with new insights that convinced them.

PEARL Framework

Enter the PEARL framework—Problem, Epiphany, Action, Result, Learning. Use it instead of STAR (Situation, Task, Action, Result) to make sure your stories highlight your seniority.

Problem

Product managers deal with problems. Customer problems. Business problems. Team problems. Sell us on the problems.

By framing this as a problem, you’re drawing the interviewer into the story and helping them understand why it’s important. You can start with the larger problem that your overall product is solving, and then get into the specific problem that you want to tell a story about.

Draw a distinction between what you were handed and what problem you identified and prioritized. Did your boss hand you the fully formed project and you just executed? If so, this story isn’t going to make you look very senior.

Epiphany

(This probably should have been “insight”, but I couldn’t resist making it spell PEARL)

I think the epiphany is the most important part of the story for product managers. We’re not drawing the designs or writing the code. We do some project management, but great project management isn’t really valued. Our insights are how we uniquely contribute to the team.

Share the details of how you came to this epiphany. What’s the key thing you learned or realized that kicked off your action? Did it come from customer research, data analysis, or somewhere else? What did you see that other people were missing?

Make sure to contrast your insights with the ‘obvious’ path. “Everyone thought we should do X, but based on Y, I realized we should actually do Z!” If you just did the obvious thing, anyone could have done it.

Action

The action is the work you did to make it happen. Keep it short and focus on the things that you did that a PM with less experience wouldn’t have done as well. Instead of listing out every step of the process, pick out the hard or clever parts.

Give your interviewer enough context to understand how challenging your role was. That said, be diplomatic when the challenge came from other people: badmouthing other people is a red flag and will trigger the interviewer to wonder if you were the problem.

Result

The result is the happy ending. PMs are supposed to be results-oriented, so make sure you don’t skip this.

When you have good results, connect them to the larger goals, strategy, and mission. For example, instead of just talking about how people loved your feature, talk about how it improved retention.

It’s okay to have setbacks and failures in the story, but those should be the middle of the story. If you’re talking about a failed experiment, keep going and share how you iterated and had a successful launch later or how you used what you learned to avoid a similar problem at your next company.

Learning

Ending with what you learned gives you a chance to be leveled higher than how you performed in your story.

Each of us grows with experience. How did that experience shape you? What will you take forward for next time? Did you get a chance to use that learning in a later project?

An example:

(Problem) When I was working on the search team, we knew that we weren’t returning good local results for queries about local businesses like “pizza restaurants”.

(Epiphany) I worked with the engineers and found that we had all the technical components we needed, but the leadership team didn’t trust the location information and didn’t want to risk returning irrelevant results. I knew I had to find a way to validate the location information, so I dug in to the data and realized something amazing! We could compare the location information on queries that had an obvious location, like “NYU bookstore” to see how accurate it was.

(Action) I hand coded a few hundred queries and shared the results with the leadership team.

(Result) They were convinced by my analysis and we were able to test and then launch. It was a huge success, as later measured by how many people used those local results and other global health metrics.

(Learning) My big takeaways from this experience were how valuable it is to look at the data directly, and how important it is for products to do the right thing without any configuration.

Practice with a friend

“It sounds like you picked a vanity metric and then just built what your boss told you to even though it was a bad idea.”

I was kind of terrified to give my friend this feedback, but I had told him I’d help him with a mock interview. Luckily he reacted well: “Woah that’s what it sounded like? That’s not what happened at all,” and he went on to explain more of what happened, how he’d taken initiative, and why his decisions were actually good. I was relieved. But also concerned. I’m not sure he would have gotten hired with the first version.

This is why I think it’s important to practice your stories with a friend who’s willing to put on the hat of someone who doesn’t want to hire you. Most companies ask a variety of “tell me about a time when…” questions, so you can prepare ahead of time.

Start by thinking about the best stories that show off your seniority and impact. The ones you’re proud of. They should be recent, but not so recent that you don’t have results yet. Then round out your set of stories with ones that demonstrate a failure, a conflict, a challenge, collaboration and so on. If you can, pick negative stories from earlier in your career so it’s believable that you’ve improved.

Run each story through the PEARL framework. Find the details that show off your seniority.

Good luck!