The only “framework” you need for PM interview questions

When I’m coaching product managers on their interview skills, the question I get asked most often is, “what framework should I use for this question?”

My answer is, “how would you do it if this was really your job? That’s your framework.”

There are a lot of fallacies about product management interviews. The worst one, by far, is that you should memorize and use frameworks when answering a question — that frameworks will lead you to the “right” answer so you can pass this part of the interview.

Let me show you why this is wrong. Imagine you were asked this interview question: “How would you increase the number of active Gmail users by 25%?”

Here’s the beginning of a typical “framework” answer:

First, let me brainstorm some user groups and their problems, then I’ll pick one, dive into their problems, and brainstorm solutions based on those problems. Then I’ll evaluate tradeoffs, pick some key metrics, and make some wireframes.

If increasing Gmail active users by 25% was actually your job, do you think those steps will solve the problem? Are those the steps you’d really follow? Do you think that’s how Google improves Gmail? No, no, and no.

To put it another way — imagine the interviewer is making a decision on your interview. Based on your answer, what kind of coworker would you be? How would you work with other people in the company? Could you be trusted to make the next, great Google product? There’s no way to tell, so you’re not gonna pass this interview.

If you want to get that job offer, you have to be the best candidate they interview. You’re up against dozens or hundreds of other people. You have to be better than all of them — the best at creativity, user-centeredness, analyzing, strategy, and communicating. No framework will help you be the best candidate.

Your job as an interviewee is to show that you can do the job better than anyone. Frameworks show how you can get an answer, but they don’t give any indication about how you’d do the work — and the whole point of an interview is to demonstrate that you can do the work.

So get off the “framework” train and try this instead. The person across the table from you isn’t looking for your framework. They’re trying to understand if you can do the job.

That’s why you should answer this question instead:

What would I do if this was my job?

And when you answer, make sure you answer questions questions like:

• What steps would you take? Why would you do those things?
• Who would do those steps? What resources would you need for each?
• How would you know when to move from one step to another?
• How would you know when you’re done?

For example, here’s how I’d start my answer to the Gmail question:

First, I’d get aligned with my team goals — what metrics, objectives, or user groups are we targeting? I’d research that goal with users — usability tests, surveys, and interviews — to learn more about the problem and develop hypotheses. Then I’d work with my team to brainstorm, prototype, and test potential visions for the product. I’d build out an MVP, confirm my hypotheses, then work towards shipping the final version of the product.

That was my off-the-cuff answer for how I’d do the work. No framework. No memorizing. I barely even thought about it.

If you’re thinking, “wow that’s a great framework,” then you’re on the wrong track. The point is — this isn’t a framework. These are really the steps I’d take to do this if it was my job.

I can give that answer spontaneously, without a framework, because I fucking know how to be a product manager. It works for every question.

Let’s go a little deeper though. With an answer like this, you’re showing your product management capabilities to the interviewer. As a PM, you’ll be working alone with very little management or peer oversight, so your peers and managers need to know you’re capable of doing the job. You can do that in your answer by telling them that how you’d really the work.

As a bonus, you don’t have to memorize anything. You only have to think about how you’d do the job. This works for any kind of interview question. Extra points if you can drop in a quick story of a time you really did this.

You’re probably wondering how you can cover all those topics — goals, research, design, vision, MVPs, etc — in one interview. Easy — you don’t. Instead, just make reasonable assumptions to help get you from one step to the next.

For example, you can’t do research in the interview, but you could make two or three guesses about what your research would uncover, then pick the most reasonable one. It’s not about being “correct” — there are no right answers. It’s about showing how you’d do the work.

So that’s it. If you want to be the best candidate — if you really want the job — drop the frameworks. Focus on communicating how you’d do the work. That’s the only “framework” you need.