There’s a common issue I've seen in PM candidates with lots of practice behind them, where they find themselves at a certain plateau. When given a product design question, they know they need to start by defining the user, then list their pain points, prioritize, find solutions, etc. Looking at their answer as a whole though, they find that their approach didn’t generate any particularly great insights. When given a question that’s outside the box, they might struggle with how to structure it. It can feel frustrating—they’re doing exactly what they’ve learned, but for some reason, it’s not working.
Oftentimes, the problem turns out to be an over-reliance on frameworks. Yes, frameworks—those stalwart friends of PM interview prep have some downsides we need to talk about. If not corrected, they can interfere with you really engaging with the question and your interviewer. Let’s say a few good words about frameworks first, though, so we can understand why we need to move past them.
Frameworks are great, for a specific purpose.
When you’re just starting out and learning how to interview, frameworks get you to decent answers quickly. Instead of just jumping directly to a solution, a framework forces you to consider what’s actually important and helps you explain it in an interview-friendly way. This helps both in practice, where it ingrains what’s important, and in interviews, where it serves as a handy checklist in case you forget something.
Frameworks also reduce complexity. They give you a ready-made structure. Given a question, which in many interviews is wide open for answering any way you might want, a framework gives you direction—talk about users, talk about pain points, etc. Check each box and you’ve got an answer. Herein lies the danger.
In an interview, your goal is not to use a framework well. Your goal is to answer the question. However, it’s easy to get tunnel vision and focus so much on the framework that the actual question becomes second-hand.
You want to demonstrate your insight/skills/experience and communicate effectively. If you focus on checking each box of your framework, it’s easy to lose sight of what matters, and it’s easy to miss where else you could have mined deeper insight.
Let’s consider one of the common elements of product design framework: Understanding the User. Listing a few user segments and talking about the market of each so that you can say you checked off the “talk about the user” box will not get you a great answer. Mentioning a few facts about the user so you can move into listing pain points that may or may not be related to those facts will not get you a great answer.
We need a deep understanding of the user in order to really hone in on their needs and what solutions make sense, but frameworks don’t actually tell us what those aspects are, or what that meaningful understanding is, or how to get it, or when to move on—spoiler alert: they can’t. It’s dependent on the question, the users, the company, the product, and an unending list of other possible factors. We’re going to have to make some judgement calls.
It’s worth pointing out—your interviewer is not looking for what framework you used. In fact, unless they’ve spent a lot of time interviewing recently themselves, they probably aren’t thinking about frameworks at all (and may not be familiar with the many of them that are floating around).
Similarly, they won't mind if you use a framework when it applies—it’s just rare for it to apply perfectly. If you only point out the things that your framework tells you to and not other important factors, they’ll notice the missing pieces. If you approach in a way that doesn’t make sense for what they’ve asked you (but does fit a framework), they’ll notice you took a strange path.
In the meantime, spend some time thinking about what struggles you’ve faced with framework-based answers and where they might be lacking. As coaches, we’d love to hear what challenges you’ve had to deal with and how you’ve overcome them.