Lizzy Masotta

There are 2 main types of interviews for Product Management roles: 1. Product case interviews 2. Behavioral interviews (by cross functional partners like UX or Engineering, or by the hiring manager) With either interview type, the surest path to failure is when a candidate shows up and waits to be asked questions. A one-way dialogue doesn’t expose enough about a candidate to make a strong impression. Engaging in an interactive, two-way dialogue helps the interviewer get to know what it would be like to work with you – it exposes how you think and communicate in a real world context. The most impressive interviews I’ve conducted are ones when a candidate can interweave their experiences throughout the conversation and have a two-way conversation with me. The purpose of an interview for the candidate is to tell their story, share their product learnings, and expose who they are in order for the interviewer to assess their candidacy. The purpose of an interview for the interviewer is to assess if the candidate is qualified for the job and if they would be successful in the role. You make the interviewer's job much easier the more you open up and engage. And, the more you engage, the more memorable this interview will be for the interviewer when they have to write up their recommendation and discuss it in a meeting with the other interviewers weeks later. To avoid this common pitfall, you can do two things: 1. Put yourself in the shoes of your interviewer 2. Come up with a list of 2-3 things you want to make sure the interviewer knows about you For #1 - Who is your interviewer? What role do they have? What do they care about? If you had to guess - what are they trying to get out of this interview? Use these insights to better connect with them live. For #2 - How does your current work connect to the work of the role you’re interviewing for? What success have you had that you want to make sure is known?

There are 2 exercises I use to evaluate bringing differentiation into the products I'm building. 1. What sucks? 2. User value mapping Where they originated I came up with these frameworks in collaboration with Paul Pedrazzi (SVP, Salesforce) while we were working on a 0 → 1 product for small business. We repeatedly re-visited the artifacts of these exercises throughout the product development lifecycle. What sucks? What the outcome will be A list of the Top 3 issues for your target user. How to do it 1. It’s as simple and cathartic as it sounds: get in a room with a diverse group of stakeholders – Product Marketing, Support, Engineering, Sales, Product, Design, Solution Engineering, etc. You should not have more than 10 people participating. 2. Have everyone individually brainstorm on sticky notes (or a Google Jam Board) “What sucks about _____?” In the Salesforce example, we brainstormed, “what sucks about being a small business owner”? In my current role at Shopify, I lead Product for Checkout. Our prompt would be “what sucks about checking out online?” 3. Share 4 things with your group before they begin writing stickies (1) Remind them to put themselves in the shoes of the user (2) Share snippets from customers you’ve spoken to recently to get the juices flowing (3) Share an overview of the range of personas and industries you cover (4) Think big and broadly; do not think about specific issues created by our existing product or company. In the Salesforce example of “what sucks about being a small business owner” our stickies ranged from ‘finding new business’ to ‘not being able to take vacation easily’. 4. Once everyone has created at least 5 stickies, begin a grouping exercise. Groups should be created based on similar dimensions and each group should be given a name. An example group could be ‘getting started’ or ‘finding new business.’ Seeing the quantity of stickies per group gives you a general sense of where the problems live. Groupings will also show you things like where other competitors are focused and where there are gaps in the market. 5. Once groups are finalized, give each person in the group 3 votes. The 3 votes are used to mark what each person believes to be the 3 most important and impactful issues from the user’s POV. Votes can be cast by putting a dot next to a specific sticky. 6. Bubble up the stickies with the most dots next to them. Facilitate a conversation around where the group thinks we could focus to have the most success in differentiation and providing user value. Example question prompts: -Which sticky is our company best positioned to deliver value against? -Where do we have the expertise to deliver value against? -What issue would users expect us to solve for them? -Where is there the least competition? -Where is there the most competition? -What issue, if solved, would be the most compelling to attract new business? -What issue, if solved, would be the most compelling for users to stick around? User value mapping You can do this exercise in conjunction with ‘What Sucks?’ or own its own. What the outcome will be A map of the most valuable, most unmet needs in the market. This can serve as your menu of options for where to focus on differentiating your product. How to do it Choose a grouping from the “What Sucks?” exercise. For example, ‘Finding New Business.’ If you’re doing this exercise on its own, select a ‘Job to Be Done’ category. 1. Create a Kanban board in your tool of choice (Miro, Trello) 2. The column headers should be steps in the user journey for that category (ex: ‘Finding New Business’ or ‘Checking Out Online’) 3. The cards within each column should be desired outcomes for that step in the user journey (ex: ‘Successful purchase’) 4. Cards within each column should be ordered based on highest priority to lowest priority. Priority as defined as what is the most valuable to the user. 5. Cards should be color coded either red, yellow or green based on how unmet / met this need is in the market today. Red = no one in the market is solving this today. Yellow = some competitors address this. Green = Lots of people address this need today. 6. At the end of the exercise, find the top 5 cards. These areas should be the highest in their column and color coded red or yellow. This is your biggest area of opportunity for differentiation. Closing thoughts Many teams do some version of these exercises early on in the product development lifecycle and then forget about them as they’re building the product. Timelines get tight, resources get shuffled and often the scope that can get cut is the differentiation you aimed to achieve. Every Product Manager should call out and protect differentiation. It doesn’t need to be available in the first release of your product, but you should always be working towards some differentiation that can help you acquire new customers, a new market or retain existing customers.

Engineers are part of your squad. They should be in the room for Problem Shaping, Live Prototyping, and Fresh Eyes. You should review your problem backlog regularly with your engineers and get their input and feedback. —Influence is the curiosity to get to the best solution— and engineers will undoubtedly think about things differently than you - leverage this to find the biggest problems and get to the best solutions. More about influence here: https://medium.com/@lizzymasotta/product-management-is-not-about-influence-e3004c12f44f

I don’t believe in a universal end-to-end product development process. I believe there are key rituals and elements that should be present on every team to ensure great outcomes, but each team needs to tailor the development process to their unique situation. My must-have product development elements & rituals: 1. Common Language - Your company should have a common language for the product development process. This is not a prescribed way to do product development for every team at the company (this needs to vary team by team for good reason). At Shopify, we call it GSD (get sh*t done). The base elements are a common language around Product Development stages: 1) Proposal 2) Prototype 3) Build. We have an internal system at the company where you can look at all development projects and the stage that they’re in, how long they’ve been in that stage, when they’re expected to go to the next stage. We also have a common calendar of 6 weeks sprints that is used by the company wide. This helps when you’re having a discussion around when do you think you will have x? This transparency and common language is key. 2. “Agile Research” - This is a term I coined to describe the act of always conducting user interviews. The problem with well-designed research projects is that they take too long and tend to deliver the insights after you’ve started building the thing. Advocate for a “rolling recruit” of your key personas so that you can tap into talking to users *every week.* This ensures you have feedback and insight in the moment you need it most before the product is built and decisions are made. Alternatively, you can create a type of Customer Advisory Board where members opt into research questions, providing feedback, etc on an ongoing basis. 3. Continuous Product Discovery - A common misconception around PMs is once a project is kicked off and being prototyped their discovery work is done. Discovery is a never-ending job. There is a lot of work to be done up front to define the problem and opportunity more broadly, but throughout the development lifecycle there are endless sub-problems that need to be found, defined and shaped. 4. Unstructured Live time with the Product Squad - At Shopify, we refer to this as "Jamming." This is the schedule I tend to implement on my teams: Monday - Problem Shaping, Wednesday - Live Prototyping, Thursday - Fresh Eyes, Friday - Demo. Monday and Wednesday sessions are unstructured live time with the Product Squad. PM, Eng, UX, and Data get on a call and stare at the Problem or Prototype together. PM guides the Problem Shaping meeting and UX guides the Live Prototyping meeting, but the purpose is to tap into all the brains on the team to get to the best outcomes. It can be terrifying for a lot of people. It’s like getting in the car without a destination in mind. You need to create a culture on your team where it’s ok to not have all the answers. To prepare, the PM can have “intended outcomes”, “problem definition” or “options” prepared. During the meeting, the PM facilitates getting insights from the group around what else to consider, what’s missing, etc. 5. Progress every week - Another cultural thing - you need to have rituals on your team to encourage and ensure progress is made in some way, shape or form every week. My favorite way to do this is the weekly demo AND ensure that not only eng presents, but also folks from PM, UX, etc.

Work in the open. Create a culture on your team that encourages sharing unfinished work and working live together. This will drive the highest quality bar for your team. If you wait until the end of development to QA too many problems will be compounded. Some rituals I use to encourage a high quality b ar throughout the entire product development lifecycle: 1. Fresh Eyes - Once a week anyone in the Product Squad can demo unfinished work for the purpose of getting feedback mid-build. The phrase and concept of “Fresh Eyes” comes from Shopify - it’s part of their culture to value feedback throughout development and actively seek it. 2. Weekly Demos - Every Friday anyone in the Product Squad can demo near complete work (PM, UX, Eng, Data). The purpose here is to celebrate progress and create a shared understanding of what the product will be. There can be great feedback that comes in these sessions, but typically more minor edits around design elements (padding, text, etc) vs fundamental functionality changes. 3. Journey Checking - All too often, I’ve seen great product visions and phenomenal products not live up to the dream. When work gets broken up into bits and pieces for engineering you easily lose sight of the journeys. It is the job of the PM to define and educate the group on the key personas and journeys they will take in the product. In the weekly demos, the PM should choose one journey every week to show where you’re at with it. Individual bits may work in isolated demos, but when you string a journey together you will quickly find a lot more gaps and issues. 4. Prototype as Requirements - The UX prototype is a living, breathing requirements document that provides incredible detail beyond what a written doc could. This is the bar that is referenced and should be actively referenced by eng as they’re building. Things that cannot easily be seen in a prototype should be written as requirements by PM.

Interview Red Flags 1. During a Product Case Interview – If your interviewer is having to guide you through each section or prompt you with several follow up questions, that’s not a good thing. 2. If a candidate clearly has never used the product (hint: always sign up for the product, do the free trial, or watch YouTube videos / demos). 3. If one of the candidates questions at the end is something along the lines of “how do promotions work here?” 4. If a candidate is unable to draw connections between their past experiences and the current role / company More specifically, in a Product Case Interview: 1. Forgetting about Product Discovery If you are given a prompt like “design a product that does X” you must always question if X is worthwhile. Many candidates will just immediately dive in without doing the Product Discovery to find out - is there a problem here? Is this worth building? What are the pain points today? Why build this? A more tangible example: “Design a personal shopping assistant.” You must first ask: What do people use today for shopping? What do we currently offer? Is it frustrating? Would people use this? What problems would it solve? Would this help our business? 2. Lacking Opinions Continuing with the case example above (“Design a personal shopping assistant”), candidates need to assert their assumptions and hypotheses throughout the case. For example, “Launching a personal shopping assistant will increase sales” → this is a hypothesis - state it aloud. “The personal shopping assistant must be digital, not a physical human being” → this is an assumption - state it aloud. 3. Random Ideation When you get to the part of the case where you're coming up with product solutions (ie: roadmap) it’s important to flex your creativity but also your strategic thinking. Your ideas should always be rooted in solving the problem you identified from the beginning of the case. They should be focused on the things that are most painful for customers today. 4. Forgets about metrics Your metrics should always be tied to the question “why should we build this?” In other words, what metric will tell you that this was a worthwhile investment? I like to call this ‘the north star metric’. There are also ‘counter metrics’ or 'trip wire metrics', which are the metrics that indicate this is going in the wrong direction or not worth building. And then there are ‘leading indicator metrics’ like adoption or usage that tell you if it’s headed in the right direction or not. 5. Asks cookie cutter questions When an interviewer asks “do you have any questions” it’s an opportunity to showcase your strategic thinking (by asking questions that show you understand the product / company / business model) but it’s also an opportunity for you to gauge if you want to work for this company. If you were about to make a billion dollar investment in this company and you were given 1 question to ask, would you ask, “what’s your favorite part about working here?” No. You’d ask something like “why can’t x, y or z competitors replicate what you have?”

I love this question. Through my work at both Salesforce and Shopify this is something that comes up regularly because of our platform and healthy partner ecosystem. 1. Do the majority of my users need this? 2. Are there problems with the partner meeting the needs of users today? 3. Do we have the expertise and staffing to build this? 4. Would building this natively unlock new value, new opportunity or a new market? If the answers to questions 1-3 are yes, then it warrants a discussion with your team. The key question that decides the outcome here is #4. Is it worthwhile for you to invest time and resources into building this thing? Does it unlock new value or strategic advantage that you do not have by offering this through a partner?

1. Tell the interviewee what they want to hear up front Who are you? What type of interview is this? How long will this last? Will I be able to ask questions? What's the next step after this? 2. Don’t ask leading questions. For example: “How do you work with engineering” gives away that you’re interested in their collaboration style with engineering. They will always answer this question with something like “I am really communicative with them and do all the right things!” To get the real answer here you want to ask an open-ended question like “tell me about x product you launched” and in their response see how they naturally bring up engineering. Or, they may not bring them up at all and you may have your answer or something to dig into more. 3. Dig deep in 1-2 areas. With a product case I like to dig deep in 1-2 ideas on their roadmap or challenge the metric they’ve come up with. The purpose of doing this is to see how the candidate reacts to being challenged and to see how deep their thinking was behind something. I’m looking for density of thought when I dig. In a behavioral interview, I dig deep on 1 past experience or feature they built. Why did they build x feature? How did they come up with the idea to build it? What was the launch strategy? How did it do? What was the design process?

There’s a ton of literature published on PM interviewing - frameworks, types of questions, types of interviews, etc. Your time is best spent introspecting, not obsessing over all the interviewing content. Memorizing frameworks won’t help you ace an interview. The more you know yourself, your strengths, and the takeaways from your prior experiences, the better you will do. Make sure you have answers to the following questions: * Why do you want to leave your current role / company? Why do you want to join this role / company? * Explain what you do now in a way that any stranger on the street could understand. * What were your biggest learnings from your current role? * How have your past experiences set you up for success at this new role / company? You should have a base understanding of the case interview framework and what they look for - but my advice is to not overdo it. For individual contributor PMs - If you were to read one book, I’d recommend “Inspired” by Marty Cagan. For people leader PMs - I’d recommend “Empowered” by Marty Cagan.

1. They teach you something in the interview I once interviewed a woman who had extensive experience working for a telecommunications company. I have zero experience in telco – aside from being a customer of Verizon Wireless. I walked out of that interview having learned so much about telco companies, their business model, what they optimize for, how they segment their customers, etc. In the stories the candidate told about her work experiences she concisely weaved in the basics of the telco in a digestible way and was very aware of the learnings and insights she had from her product launch successes and failures. As a product manager you’re responsible for the “what” and the “why.” What should we build and why should we build it? If you’re able to succinctly describe the what and the why of your current or previous roles -- no mater the industry -- that’s a great indication of a strong PM. 2. They make it a two-way conversation. (See answer to “What are the most common mistakes you see candidates make” question above)