Product Design Framework (think Google)
Photo by Dayne Topkin on Unsplash
When you study PM interview frameworks, they can start to feel like alphabet soup. (I love you Lewis Lin but couldn’t ever remember what CIRCLES stood for when I got nervous.) Rather than trying to memorize mnemonics, I highly recommend setting out a simple framework, that includes pauses to gather your thoughts. It may seem long at first but a few mock interviews later it will be second nature.
Practice it. Feel free to move a few things around or add slight modifications. Whatever you do, make it your own and something you are comfortable with. Be able to rattle it off with ease. Try practicing it in the mirror every morning for a week just after you brush your teeth.
Note: Google interviewers are looking for strategic insights where Facebook is more execution-focused.
Our Framework
Clarify | Ask for details around question/prompt || time: ~2 mins
Pause | Gather your thoughts || time: 2 mins
OPTIONAL: If very ambiguous prompt (not company-related product) try to narrow down by selecting one of many possible definitions of the space. (i.e. Disaster App - Pick Fire, Flood, Tornado, etc. You need to focus quickly.)
Share Framework | Tell the interviewer how you will approach the problem || time: ~2 mins
State Goal/Mission | Set the stage for prioritization calls || time: ~1 min
Strategic Acknowledgement | Identify key strategic issues in the space and at least essential stakeholders. || Select your primary stakeholder to focus on. || time: ~1 -2 min
OPTIONAL Jobs-to-be-done | what is a crucial ‘job’ or ‘task’ this user needs to complete. (Thinking about this will help you decide user groupings)
Users | List 3 (ideally, mutually exclusive) user groups/people with jobs-to-be-done. | think about small, medium and large or rare, infrequent or frequent users || time: ~2 mins
Prioritize | Rank H/M/L based on Impact and Mission. Select 1 user type || time: ~2 mins
User Journey | Walkthrough day-in-the-life of user = Storytelling || time: ~2 mins
Needs Identification | List major pain points identified in the User Journey and establish a general problem statement to tackle | you can proceed with more than 1 pain point if you have an overarching problem statement || time: ~2 mins
Pause | Gather your thoughts || time: ~2 mins
Solutions | List 3 || time: ~5 mins
Optional for some: Mockup | Wireframe user experience || time: ~2 mins
Prioritize | Pick the solution you would implement || time: ~2 mins
Metrics | List 3 - prepare to pick a North Star Metric from your 3 and acknowledge a counter metric || time: ~2 mins
Summarize | Do a quick run-through of what was discussed and decided on || time: ~2 mins
Note: Rough times are listed to help you sense check. If you only have 30 mins, you should know where you can keep it brief and shave off a few minutes.
Things to remember throughout:
Rule of three
Tell a good story. Nailing the user and the user journey are key.
Acknowledge the flaws in your reasoning.
Slow down. To be understood.
Slow down. Give the interviewer the opportunity to converse or ask questions.
A Few More Hints
In this article, we dive a little more into some helpful hints around the above list.
Clarifying Questions
Don't Rush or Underestimate their Value
Experienced interviewers can get a strong signal from your clarifying questions. Do NOT rush through them or think that they are window dressing. Clarifying questions let you narrow down broad prompts but just by asking the questions, you signal how you are thinking.
User Journey vs Use Case vs Pain Point Prioritization
User Journey
I personally prefer the User Journey approach. I take a moment to walk in the shoes of my users and tell the story of a day in their life to your interviewer. Taking note of key pain points as you move through the journey. Don’t get so caught up in the story you forget to jot down your great pain point ideas.
Use Cases
Some people feel uncomfortable walking through the user journey and just want to jump to use cases. If that is the case, I found the tried-and-true use case mad lib format is best: As a ____, I want to ______ so that I can _______. The ‘so that I can …’ is just another way of expressing the users paint or job to be done that they desperately want solved.
Pain Points
Some people prefer listing pain points out and picking one to focus on with or without the user journey or use cases to support them. If this works for you, I say go for it. Just be careful that you don’t limit yourself too much and end up with only one or two goo ideas. That good old rule of three should be followed when you get to the solutions section.
In Summary
Throughout, remember the rule of three. Periodically, acknowledge the limits or flaws in your approach. But don’t let the limits get you hung up.