PM Frameworks: to each their own
Collaboration is a key PM skill. Customers, engineers and company leaders are just a subset of the people you need to address. The PM must hold conversations with each group and build shared mental models over time in order to drive decisions, build consensus, get buy-in and build trust. Shared mental models enable product managers to have the most efficient conversations.
ICE, Eisenhower Matrix, MoSCoW, are all terms you must’ve come across when you search product frameworks. I often see product managers trying to apply these frameworks in a silo. When asked to share priors during an interview, PM candidates often end up re-sculpting their experience into a perfect box that portrays their knowledge of a framework. Their strategy is totally ok if their previous team did in fact use the same framework. But what if they didn’t? Or what if your current team doesn’t use (and doesn’t understand) the framework you are trying to shoe horn?
We forget, most frameworks are just shared mental models. Their purpose is for you to hold meaningful conversations with others, efficiently. If a certain framework is not internalized and used by your larger (product) organization, then its effectiveness will be limited. The model you would be using to communicate will not help expedite understanding of your ideas and slow down the entire feedback loop. If the interviewer is not familiar with (let’s say) HEART and that is the model you are using to communicate, the consumers of your communication will first have to understand the constructs of HEART before they can understand your proposal.
What about those interview candidates? Well, I would mention to the interviewer the exact mental model my last team used for — let’s say — prioritization and then ask what model the existing team — the one I am interviewing for — uses. Based on the response, I would use a solo mode framework like STAR and reframe my answer showing I understand that some frameworks cannot be applied without having a squad. Maybe a good interview package companies can provide to candidates can include mention of frameworks and shared mental models they use? I think I will run this by my Product leads.
Building products is all about identifying the biggest customer problem at hand, de-risking and strategizing towards the fastest solution and capturing learnings for the next iteration. We should try not to bury ourselves under acronyms and unwanted complexity – unless of course these acronyms have been internalized by the larger team.
Speaking of frameworks, solo mode frameworks help you form clearer thoughts and I will surely post about them in the future but this post was about squad mode frameworks – which help you communicate your ideas, define priorities and establish trust with your collaborators.
Thank you Calvin French-Owen, Kevin Niparko and Daphne Gray-Grant for early feedback.