Prioritizing Users, Pain Points & Solutions

Most product case frameworks, including my S.U.S.S. framework, require the candidate to prioritize user segments before proceeding to pain point identification.  

Some people have three criteria and then a five point scale for those three criteria. Just stating the structure makes me scream K.I.S.S. please! (Keep it Simple Stupid) 

I advocate a simple two criteria framework with a L, M, H grading system. My approach requires no complex averages to be calculated while under extreme stress.  

How you deliver your prioritization varies depending on the company you are interviewing at: Meta/Facebook requires more obvious structure (clear framework) to be displayed while Google is looking for comfort with the concept that is better displayed through concise verbal communication. 

I recommend always prioritizing in your notes, even if you don’t show your work. It helps you present your ideas clearly. BUT if you don’t show the visual, don’t painstakingly read each line and ranking one-by-one. Present your conclusion and then share the logic. 

Here are what my prioritization grids look like: 

User Prioritization Grid

I like impact because it can be used to mean different things, just make sure you define impact to your interviewer based on the nature of the case. Typically, most user segments you select are highly aligned with your mission, but it is nice to sense check it and force yourself to remember what mission you are driving towards.

Pain Point Prioritization

While I typically swear by The Rule of Three, sometimes you have more than than 3 pain points. I prefer the Frequency and Severity approach. Sometimes you only need one to rank them, but other times both will do. For example, productivity apps might be more about frequency than severity. Test it out to see what works for you. 

Solutions Prioritization

Again, I like impact (define as is appropriate for the case) and effort. You want to use effort to show you are thinking about the engineering effort for your solution. This is more relevant for Meta/Facebook than Google. It is also more important for those without traditional PM experience to show they know how important it is to consider engineering effort. I don’t have to pick the lowest effort option, in fact most of the time I shouldn’t, but I need to discuss it as a consideration.

Remember, the grids help you maintain structure and clarity of thought. But don’t sound frameworky or robotic. It is a tool not a crutch.