AMA: Shopify Senior Product Lead, Lizzy Masotta on Product Development Process

To answer this question, I’m going to put my PM hat on. Why is the engineer “rogue”? What is driving them to want to “slip in this feature”? 1. First, I’d talk to them, understand their frustrations, and where they’re coming from. 2. From that conversation, I would expect to learn a bunch of stuff I probably didn’t realize about how frustrating it is to build in our codebase. The engineers and designers on your team are a key persona you must also serve as a PM. If you can make their lives better, easier, more efficient – do it. 3. Then, I'd come up with a plan to make sure we allocate a portion of our development efforts to internal improvments. The best execution I’ve seen around making non-customer facing improvements is an approach Salesforce used called the “Trust rotation.” Each sprint 1 engineer was dedicated to “Trust.” There was a “Trust Backlog” the team maintained, prioritized and agreed upon. And, any other burning sev0 issues would go to this eng too.

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.

“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.

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

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.

It is the Product Manager’s job to identify, prioritize and shape the problems the team is tackling. We’ll break this into two parts 1) finding problems 2) shaping problems. Finding Problems You need to have ongoing sources that you’re plugged into to find problems. Common sources are 1) customer research 2) exec requests 3) support tickets or user feedback 4) product usage data. In my experience, I’ve found the most fruitful source of problems and opportunities is customer research. Be careful with exec requests - the common behavior is to blindly execute on them. You must ask questions. Where did this idea come from? Why do they think it’s important? Support tickets tend to be a gold mine for problems, but typically more miniscule ones. It’s important here to find greater trends and patterns that point to bigger problems. And finally, data is a great signal, but tends to require interacting with the user to understand the broader problem at play. Follow up on the signals you see in data with talking to users. Prioritizing Problems This should be done transparently with your Product Squad (ie UX, Eng, Data). Each week you should review the prioritized backlog of problems you’re shaping (actively researching and defining). Your squad should provide their feedback and input on the problem backlog (add / edit / remove items) and align on the prioritization. Shaping Problems Before the squad can work on a problem together it needs to be shaped (ie talk to customers, dig into the product, look at data and answer these 7 questions below): 1. Why is it a problem? 2. Who is it a problem for? 3. When does it happen? 4. What does the current (broken state) journey look like? 5. What workarounds or hacks are used today? 6. How many customers is this impacting today? 7. Is this a problem worth solving? Why? A shaped problem should always have a 1-pager that concisely summarizes the answers to the above questions. At the start of each sprint, the PM picks a shaped problem from the top of the backlog to focus on. This is when Discovery and Prototyping begins.