Mckenzie Lock

The candidate must “spike” (“8/10” or higher) in all of these areas, in order of importance: 1. Critical Thinking Given how many decisions and complex problems are thrown at PMs, this the #1 most important attribute I screen for. They don’t need to be a rocket scientist (top 0.5% of population) but they should be exceptional at this (top 5%). Good looks like: * Take large ambiguous problems and break them down into smaller pieces * Uses logic to convince others * Gets to the root of the issue: Think about things from multiple angles but then focuses on what matters (this is key and hard to find). The more senior a candidate the more critical thinking/problem solving looks like: starting the why and bigger picture, being principles-based, helping others to structure their thinking (good frameworks, simplifies and structures conversations etc.). I usually test for this both in the initial phone screen and through a product thinking interviews (case questions, panels) 2. Drive PMs have a lot of responsibility, get very little direction, and get too much credit and blame, so they need to a) self start and b) be motivated to keep trying even when faced with obstacles. Good looks like: * Ownership over outcomes vs. just doing the activities? A former manager of mine once called this “an insatiable desire to ship” * Self starter - Can we throw them at a problem and trust them to figure it out without hand holding? * Vigilance - do they generally think ahead to the outcome they are trying to achieve? Do they proactively address what may get in the way? This is very hard to screen for in an interview but you can get signals from behavioral questions, their questions to you, and follow ups. 3. Bridge Building There are two parts of bridge building 1. EQ - not easily coachable 2. Communication - this includes both written and verbal communication skills and both the quality and frequency of comms. Verbal and written comms are usually coachable. It’s ok if someone isn't a perfect communicator because people improve on this over time. But it’s not ok if they don’t have sufficient EQ. Good looks like: * Self aware - seeks to know (and improve on) their own strengths and weaknesses, self reflects without defensiveness * Situationally aware - skillfully navigates people situations and figures out how to influence others towards an outcome * Concise and clear answers that are easy to follow, verbally and written. I usually test for written and verbal comms in the panel exercise and interview questions. I test for self awareness and situational awareness in behavioral interviews.

I’ll skip the obvious things - pay well, set a vision, growing company, skill building, career pathing - and highlight some under-rated ones: * Hire well and have high talent density. Most people who choose a career in Product Management are motivated by self improvement - being around other talented PMs who they admire and who push their thinking is motivating. * Stay lean. This may seem counterintuitive - isn’t it good to have enough PMs? Honestly, no. If you hire well you want to give people room to grow and stretch. The worst thing you can do is to staff up too quickly, only to have frustrate your stars who are ready for more in a year (or worse yet, sudden shift in the business which requires you to scale back projects). Having too many PMs will also lead to more work being generated, you then need to resource. It’s far better to have PMs that have 20% too much to do than 20% too little. My rule of thumb is: everyone should be just uncomfortable enough with their scope that they drop a few things, but not so uncomfortable that they burn out. * Autonomy. People choose a career in product management because they want to make or be at the center of product decisions. Allowing them to do so is one of the most important things you can do to keep them motivated. As a people leader your jobs is to set goals, give context, guide, and identify blindspots. It’s not to operate the product for the PMs on your team. At Netflix we have a value, “Context over control” - leaders should focus first & foremost on setting context so others can make decisions vs. making decisions for them. * Actually care about them. When I think about the best managers I’ve had they have one intangible thing in common - I felt on a deep level that they actually, genuinely cared about me. This had a ripple effect on every part of my job because I felt supported, was calmer, and did better work. Caring looks like regularly thinking about the growth & success of another person without being asked to. It looks like advocating for or elevating behind the scenes, especially if they are in a disadvantaged position. It’s something that you can’t fake.

The most important thing you can do as a new head of product is to align with the founder/s and/or your manager on what your role is. Most people assume they did this in the interview process. Yet, misalignment on this question are the most common reasons heads of product fail. You want to know: 1. How will I be evaluated? “In 1 year, what evidence will tell you I’ve been successful?” Make sure they are specific. For example, if they say something like, “customers are happier,” follow up with: “what’s an example of something that would give you confidence customers are happy” This tells you what outcomes you’re being evaluated against. 2. How much autonomy will I have for which product decisions? The best piece of advice I've received is to ask a new manager or founder, "What decisions do you want to make? What decisions do you want me to make but run by you first? What decisions do you want me to run with entirely?" This tells you how much autonomy you have on what. Once you understand these things create a 6 month plan that incorporates a few things: 1. Quick wins - ask your manager, their manager, your team, and your peers, “what do you need most from product management?” Use this to identify a few quick wins you can deliver to build trust. 2. Start with the low context decisions - a lot of new Heads of Product make the mistake of trying to define a product strategy too early. This is often a mistake because such decisions require product context, organizational context & an intuition for the space. Instead start by making decisions you don’t need a lot of domain context to make - who to hire, how to uplevel the team, how to improve your product process, etc. For product decisions, start small by picking a few projects/or areas to go deep on before building out a larger strategy. In all of this, setting expectations is your best friend. Once you’ve aligned with your manager on your plan, be sure to set expectations with the organization about what you’ll be focused on in what order.

The good news is that you have an engineering team that is excited about the product & generating ideas. That’s huge. Over the long term, this will make your product more successful....so long as you can channel that excitement towards features that are also exciting to customers. Your goal is to help your team fall in love with problems, not solutions. I’ve seen over and over again how this simple mindset shift can be a game changer for more user focused decision making. Here are some approaches to consider: 1. Expose your team to users - have engineers shadow user research sessions, share clips and quotes, or simply talk about your customers constantly. Bake user feedback into the development process if it isn’t there already. I’ve found that teams get most inspired when we ground their work on real humans. Use this to your advantage. 2. Tweak your process with one pagers & “problem kick offs.” For every non-trivial project you take on, write a simple, one page description of the people problem, hypothesis, success criteria, and “skeleton of a solution.” By skeleton I mean, just enough to start thinking about solutions: e.g. "the ability upload a pin to a board" vs. "an upload button on the profile." Schedule a kick off to discuss and debate the problem, refine your hypothesis, brainstorm potential solutions - even before getting into requirements. 3. Perfect your problem statement. Below are some best practices for writing problem statements. You may even encourage your engineering team to write these for their ideas! Here's what makes for a good problem statement: * Is ONE sentence * Gets as close to the actual human behavior as possible. Avoid sayings like “the industry is changing” or “our systems are disconnected” those are just facts not problems in and of themselves. * Does not hint at a solution. Example of hinting at a solution: “We don’t have a common place for users to come…” * Is as specific as possible. Example: “drive efficiency” often isn’t specific enough - what does that mean exactly? * Is written in plain & simple language. “Project managers don’t have data tracking mechanisms built into their current workflows” => “Project managers don’t know what’s on track and what isn’t” * Includes WHO it’s a problem for (preferably a human being) * Is meaningful - describes the impact/negative outcome

Common challenges are: * Fear that the PM will slow the team down or add too much process * Another function has stepped in to fill the PM shoes and is reluctant to give their role up * There is a solutions-first (vs. problem-first) mindset * Founders have trouble letting go of product decisions as the company grows * Talent mismatch - PMs were reporting into other functions which did not know what to look for in PMs