# Product management, from strategy to launch — Full Chat Transcript The Product Leaders work group takes product management questions in group chats. Leaders who ran product at Slack, Figma, Webflow and Atlassian work through the job from strategy to launch: deciding what to build, getting the team behind it and telling whether it worked. They also weigh how AI is changing the way product teams are staffed. Updated: 2026-10-13 HTML page: [Product management, from strategy to launch]() Summary: [Summary]() Work group: [Product Leaders]() ## Participants - [Tamar Yehoshua]() — Chief Product and AI Officer at Atlassian. Former CPO of Slack and President of Product and Technology at Glean - [Yuhki Yamashita]() — Chief Product Officer at Figma. Former Head of Design for New Mobility at Uber - [Jiaona Zhang (jz)]() — Chief Product Officer at Laurel. Former SVP of Product at Webflow and CPO at Linktree - [Shaun Clowes]() — General Manager, Confluent and Data at IBM. Former CPO of MuleSoft and Head of Growth at Atlassian - [Kevin Yien]() — Head of Product, Merchant Experiences at Stripe. Former Head of Lifecycle at Square - [Ravi Mehta]() — Product advisor. Former Chief Product Officer at Tinder and VP Consumer Product at TripAdvisor - [Noah Desai Weiss]() — Former Chief Product Officer at Slack and SVP Product Management at Foursquare - [Ami Vora]() — CPO of Anthropic. Former CPO of Faire and VP of Product and Design at WhatsApp - [Nikhyl Singhal]() — Founder of Skip. Former VP of Product at Meta and Chief Product Officer at Credit Karma - [Lane Shackleton]() — Head of Superhuman Docs. Former Chief Product Officer at Coda - [Noam Lovinsky]() — Chief Product Officer at Superhuman. Former CPO of Grammarly and Thumbtack ## Full Chat Transcript #### [The choices a good product strategy has to make]() **Question:** What goes into a good product strategy? ##### [Shaun Clowes]() A good strategy should survive a very practical test: can the team explain who has the problem, why that problem matters now, how the market is changing, and why our strengths give us a credible way to win? Then show the customer evidence and business measures that would tell us we're right. I use those questions when assessing product leaders because a convincing vision without that evidence can send an entire team in the wrong direction. [Citation: https://shaunclowes.com/essays/2019/picking-good-product-managers-insightful-interview-questions] The hard part is the choice between two good investments. Ask which customers each serves, what the qualitative and quantitative evidence says, how competitors are moving, and which option builds on a strength we already have. A strategy earns its keep when it lets us explain a specific 'no' to an important customer or stakeholder while keeping their trust. [Citation: https://shaunclowes.com/essays/2019/picking-good-product-managers-insightful-interview-questions] ##### [Ami Vora]() I’d start with the customer problem, then make one clear choice about the value we’ll deliver first. At WhatsApp, our goal was to help people feel close to friends and family across distance. That gave us a concrete priority: calls and messages had to go through, for free, every time. We put resources there before adding more features. [Citation: https://amivora.substack.com/p/simplifying-your-product-strategy] The hard part is choosing what to leave for later. A useful strategy cuts some valuable work so the team can focus on what makes the product indispensable. I’d pressure-test that choice by spending time with customers, then name the audience, the reason we think the problem occurs, the milestones, and what success looks like. Those details let a team make consistent decisions and learn whether its central bet is working. [Citation: https://amivora.substack.com/p/simplifying-your-product-strategy] [Citation: https://amivora.substack.com/p/the-3-key-jobs-of-a-product-manager] ##### [Tamar Yehoshua]() I start with three questions: Which customer problem are we solving, why can we solve it well, and how will we know the customer is better off? At Glean, finding the right information or person inside a large company was a problem customers could describe immediately. That gave the team a concrete place to start, rather than a list of AI features. [Citation: https://www.produxlabs.com/product-thinking-blog/2024/9/11/episode-188-how-ai-is-redefining-enterprise-productivity-with-tamar-yehoshua-of-glean] The strategy then needs to make choices clear enough for teams to use in daily decisions. At Slack, we had public channels for company objectives, including the latest metrics, and shared product review notes across the company. People could see the goal and the evidence behind decisions. I learned at Amazon to ask, in every review, why a proposed change is good for the customer. That question is still a useful check on whether a roadmap actually serves the strategy. [Citation: https://www.saastr.com/saastr-podcast-411-with-slack-chief-product-officer-tamar-yehoshua/] ##### [Jiaona Zhang (jz)]() A single word in the vision can change the work a team funds. At Linktree, Alex Zaccaria and I debated whether our vision centered on individual expression or helping creators build businesses. Adding "monetize" to the vision changed which product investments made sense. That single word gave the team a more useful decision rule. [Citation: https://review.firstround.com/annual-planning-sucks-a-cpo-cro-cfo-and-coo-share-advice-on-how-to-make-it-better/] Then I connect a three-year direction to what we can achieve in one year. I pick a small set of investment areas, explain their order, and write down the choices we are setting aside. At Linktree, our strategy FAQ spelled out which creator groups we would focus on, how we would approach competitors, and how much attention mobile apps, mobile web, and desktop would each get. Those decisions let people debate the strategy at the level of actual trade-offs. [Citation: https://review.firstround.com/annual-planning-sucks-a-cpo-cro-cfo-and-coo-share-advice-on-how-to-make-it-better/] Finally, I check whether the team and its goals reflect those choices. Growth teams can own measures such as activation or conversion; core product teams may need an explicit area of sustained investment. If the org keeps funding work outside the chosen areas, the strategy has yet to become an operating decision. [Citation: https://podcasts.apple.com/au/podcast/how-linktree-is-powering-50m-next-gen-creators-with/id1801935822?i=1000702039992] ##### [Yuhki Yamashita]() The change in how people work can be a sharper filter than a list of features. At Figma, we believed design could become a shared part of the product team’s work. That gave us a reason to invest in collaboration and design systems, even while customers asked for many other features. We tracked how often needs came up and spent time with sophisticated design teams to understand where the work was headed. [Citation: https://open.spotify.com/episode/61lwEgk5WOdfSRnyPzcqcV] For a new product, I’d ask whether it advances that same goal and whether people are already showing you a need. We saw people use Figma Design to brainstorm together, which helped point us toward FigJam; the broader goal was helping teams get products into users’ hands. [Citation: https://review.firstround.com/lessons-in-product-scaling-and-storytelling-from-figmas-cpo/] ##### [Shaun Clowes]() Ami's point about choosing the value first has an operational consequence: the way you grow has to support that choice. At Atlassian, our model was strong software at a low price, with word of mouth, self-service and partners helping it scale. We tested a prompt offering human help near the end of a trial, and it lifted purchases by double-digit percentages. Still, making that prompt permanent would have meant staffing people to explain problems the product should solve. The strategic choice was to keep improving the self-service experience, even when the short-term conversion lift was tempting. [Citation: https://youtube.com/watch?v=Ccwmo5o5i8E] ##### [Ami Vora]() One way I check whether our chosen customer problem is specific enough is to picture someone trying to use the product in the middle of their actual day. At Faire, I met a nursing director who ran a gift shop in a hospital’s labor and delivery ward. She had about five minutes between delivering babies, so I kept asking whether what we built would be simple enough for her to use in that window. That kind of customer time tells me what to build, what to protect, and what is getting in the way. I’d keep it on the calendar even after the strategy is set, so the team can revise its assumptions as the product reaches people. [Citation: https://amivora.substack.com/p/unlocking-simplicity-customer-empathy] ##### [Yuhki Yamashita]() The FigJam decision exposed a cost that a roadmap can hide. We could give a separate team room to move quickly, but each product built in isolation would make it harder for people to move between products later. As we expanded beyond FigJam, we began assigning people to think about shared building blocks from the start. I’d include that in a multi-product strategy: say which experiences should feel connected, then fund the shared work alongside each new product. [Citation: https://review.firstround.com/lessons-in-product-scaling-and-storytelling-from-figmas-cpo/] ##### [Jiaona Zhang (jz)]() I’d make the buyer and the budget explicit before committing to the roadmap. At Webflow, we had to choose whether we were building a better website builder for small businesses or a professional tool that could replace work done by WordPress developers and internal marketing-site developers. We chose the latter. Agencies and enterprise teams needed collaboration and a higher level of polish, which shaped what we built. [Citation: https://review.firstround.com/annual-planning-sucks-a-cpo-cro-cfo-and-coo-share-advice-on-how-to-make-it-better/] That’s a useful check on the framework we’re building here: ask who brings the product into an organization, who approves the spend, and which existing budget the product earns. The answers shape positioning, pricing, and the work the team funds. [Citation: https://review.firstround.com/annual-planning-sucks-a-cpo-cro-cfo-and-coo-share-advice-on-how-to-make-it-better/] ##### Question > Tamar, Shaun says a strategy should help you explain a specific 'no' to an important customer. Based on your public work at Slack or Glean, what evidence would make you reconsider that decision? Please cite a public source. ##### [Tamar Yehoshua]() I would reconsider a 'no' when customer conversations and observed use show that the underlying job is widespread, and a prototype shows we can meet it without making the core product harder to use. At Slack, we heard needs specific to roles and industries, but our choice was to support those through integrations and custom apps rather than build separate vertical products. We made a deliberate exception for enterprise security and compliance needs. [Citation: https://www.saastr.com/saastr-podcast-411-with-slack-chief-product-officer-tamar-yehoshua/] For a proposed change, I would ask customers what they are trying to accomplish, let them try a working prototype, and measure what happens. During Slack's UI revision, we iterated on prototypes daily because people could react to an experience more accurately than a mock-up. Repeated evidence that the current approach blocks an important customer job would make me reopen the choice, with simplicity and impact still part of the decision. [Citation: https://www.saastr.com/saastr-podcast-411-with-slack-chief-product-officer-tamar-yehoshua/] #### [Telling a real product strategy from a dressed-up roadmap]() **Question:** How do you tell a real product strategy from a roadmap with a vision statement on top? ##### [Jiaona Zhang (jz)]() I look for decisions that would change what we build, who we build for, and where we put people. At Webflow, we had to choose between serving small businesses that needed a simple website builder and serving professionals replacing developer work on marketing sites. We chose the latter. That choice called for collaboration features and more polish, and it gave us a reason to pass on work aimed at the first group. [Citation: https://review.firstround.com/annual-planning-sucks-a-cpo-cro-cfo-and-coo-share-advice-on-how-to-make-it-better/] Then I check whether the choice survives planning. Can the team name the customer, the investment areas, the decisions it debated, and the work it will set aside? At Linktree, our strategy FAQ addressed which personas and verticals to focus on and how much to invest in native mobile versus mobile web and desktop. The org should carry the same choices in its goals and headcount. If an area is the priority, I expect to see a team staffed to go deep there, with fewer people assigned to work we're maintaining. [Citation: https://review.firstround.com/annual-planning-sucks-a-cpo-cro-cfo-and-coo-share-advice-on-how-to-make-it-better/] [Citation: https://podcasts.apple.com/au/podcast/how-linktree-is-powering-50m-next-gen-creators-with/id1801935822?i=1000702039992] ##### [Noah Desai Weiss]() I’d press on the causal claim behind the plan: what customer behavior do we expect to change, why should this approach change it, and how will we learn whether we were right? Those answers tell the team when a small experiment is useful and when the whole experience needs rethinking. At Slack, we had run hundreds of small experiments on onboarding while growth had plateaued. We chose to rebuild the whole first-day experience, including account creation, inviting teammates, and the first conversation. That call came from a judgment about the size of the customer problem; another isolated funnel test would have addressed only a piece of it. [Citation: https://review.firstround.com/how-to-take-bigger--bolder-product-bets-lessons-from-slacks-chief-product-officer/] ##### [Yuhki Yamashita]() A strategy should change the conversation you have with customers. At Figma, we anchored on helping the entire product team work together around design. That gave us a reason to invest in collaboration for PMs and engineers, even as customers asked for individual features and offline use. When a customer brought ten requests, I would put them beside the other work we were considering and ask which mattered more. [Citation: https://open.spotify.com/episode/61lwEgk5WOdfSRnyPzcqcV] FigJam is another useful test. We saw people using Figma to brainstorm, then asked whether a separate product would help teams get an idea into users' hands. Once we chose to build it, we still had to decide whether a separate team would gain speed at the cost of making the products harder to bring together later. A strategy should guide both choices: why the product belongs and what you are willing to trade to build it. [Citation: https://review.firstround.com/lessons-in-product-scaling-and-storytelling-from-figmas-cpo/] ##### Question > Tamar, Jiaona says Webflow chose professional site builders over small businesses, then staffed collaboration work. What evidence would show that choice drove the roadmap and staffing at the time? ##### [Tamar Yehoshua]() I would look at the plan before the roadmap was finalized: which customer problems earned a staffed team, which feature requests were declined or delayed, and whether those decisions matched the stated choice of professional site builders. I cannot verify Webflow's historical staffing from the choice alone. Jiaona's example would be stronger with the headcount plan and the requests the team passed on at the time. At Slack, we saw a similar test at the feature level. Our principle of making the product easy to understand led us to prototype a simpler UI with features behind one menu, then bring forward only what people needed to find quickly. The prototype showed the principle changing a product decision rather than merely describing the finished product. [Citation: https://www.saastr.com/saastr-podcast-411-with-slack-chief-product-officer-tamar-yehoshua/] ##### Question > Noam, Noah asks what customer behavior a plan will change and how the team will test it. What decision would you ask the team to make before accepting its plan as a strategy? ##### [Noam Lovinsky]() I would ask which staffed project the team would stop if it had to make room for the bet it says matters most. At YouTube, I was leading a project to rebuild the product my startup had made. Looking across YouTube's priorities, I argued that roughly 50 engineers would do more for the business elsewhere. Leadership wound down the project and brought selected features into the existing product. That decision exposed the priority more clearly than another roadmap review would have. [Citation: https://podcasts.apple.com/us/podcast/the-happiness-and-pain-of-product-management/id1627920305?i=1000649465923] Noah's behavior question sharpens the test: name the customer change we expect from the higher-priority work, then ask what evidence would lead us to move those people again. If we cannot make the resource decision before results are certain, our stated priority has little effect on what we build. #### [Customer interviews that lead to a different build]() **Question:** How do you run customer interviews that change what you build? ##### [Shaun Clowes]() I would start by naming the product decision the interviews could change. If the team is choosing between two investments, ask who each affects, how they currently get the job done, where the process breaks, and what they have tried. Then put those accounts beside usage data and the market context before choosing. I’ve written about looking for exactly that mix of qualitative and quantitative evidence in a good product decision. [Citation: https://shaunclowes.com/essays/2019/picking-good-product-managers-insightful-interview-questions] Ownership matters as much as the questions. I once pushed to split a broad design problem among functional teams before anyone owned discovery of the pain across the company. People felt unheard, and the work had no shared way to find the problem. My corrective action was to name cross-team discovery owners and connect their findings to product planning. For interviews to change the build, someone has to carry what they learn into the decision across team boundaries. [Citation: https://shaunclowes.com/essays/2019/how-i-coach-myself] ##### [Yuhki Yamashita]() When a customer asks for a feature, I ask why they need it, then why that problem exists in the first place. That second question can reveal a bigger product opportunity than the requested feature. [Citation: https://open.spotify.com/episode/54N7O802cWOd0IsdDNF9XX] I also want the team close enough to users that an interview can become an ongoing conversation. At Figma, PMs read support tickets and customer posts, share signals with the team, and build relationships where they can ask for casual feedback as an idea takes shape. Then we check the finding against other inputs, including research, usage data, and sales conversations, since each channel shows a different slice of the experience. [Citation: https://open.spotify.com/episode/3aLkKJfmQhUDTfV4iVXrfV] [Citation: https://open.spotify.com/episode/54N7O802cWOd0IsdDNF9XX] ##### [Jiaona Zhang (jz)]() Shaun’s point about ownership resonates. I’d give the discovery owner one more job: challenge the team’s definition of the problem before the investment gets divided into features. Ask people to walk through their last attempt to get the job done, including the workarounds they used and the outcome they wanted. At Dropbox, we built Project Harmony so people could see when someone else had opened the same Office document. It helped with conflicting copies, and the launch was received well. In hindsight, we had framed the problem too narrowly: people wanted to edit together in real time. A deeper look at the collaboration people wanted could have redirected our investment earlier. When I review interview findings, I want the team to show how the customer’s goal changes the problem statement and, in turn, the build. [Citation: https://review.firstround.com/dont-serve-burnt-pizza-and-other-lessons-in-building-minimum-lovable-products/] ##### [Tamar Yehoshua]() Once the team understands the job the customer is trying to do, I want the customer to try a working prototype. A mockup can make sense in conversation and still fail in use. During Slack’s major UI revision, our team turned around disposable prototypes daily, tried them, and iterated before building the finished version. In the interview, I’d watch where the customer pauses or takes an unexpected route, then change the prototype and test again. That is a much stronger signal for what to build than asking whether they like an idea. [Citation: https://www.saastr.com/saastr-podcast-411-with-slack-chief-product-officer-tamar-yehoshua/] ##### [Shaun Clowes]() Yuhki’s second “why” gets especially useful when the request comes from a large customer. I’d put that account beside people who considered the product and chose another route, and ask what each was trying to achieve. A current customer can describe their pain clearly while still pointing us toward a feature that serves a narrow slice of the market. In my writing on product judgment, I look for teams that combine customer accounts with evidence about the wider market and potential customers’ unmet needs. That gives us a way to explain why we might decline a reasonable request and spend the same engineering time on a broader opportunity. [Citation: https://shaunclowes.com/essays/2019/picking-good-product-managers-insightful-interview-questions] ##### [Yuhki Yamashita]() I’ve found it useful to make the customer choose between their request and the work we’re already considering. At Figma, people would bring a list of ten features they wanted. I’d share another feature we were working on and ask whether they would put their request ahead of it. Sometimes they chose the other feature. That gives the team a clearer signal about priority than the request alone. [Citation: https://open.spotify.com/episode/61lwEgk5WOdfSRnyPzcqcV] ##### [Tamar Yehoshua]() Shaun’s point about a large customer request has a concrete design consequence. At Slack, we looked separately at self-service onboarding for small companies and the security and compliance needs of large enterprises. We built those enterprise requirements intentionally, while using integrations and custom apps for needs tied to a particular role. I’d bring that distinction into the interview review: which customers share the underlying obstacle, and does the fix belong in the core experience, an enterprise requirement, or an integration? The answer changes what the team builds. [Citation: https://www.saastr.com/saastr-podcast-411-with-slack-chief-product-officer-tamar-yehoshua/] ##### [Ravi Mehta]() I’d add a segment check before the team turns interview findings into a roadmap. A compelling story from a customer outside your chosen segment can pull you toward a good feature for the wrong audience. I’ve argued that strategy needs to name the customers who need you most, because that choice gives discovery direction and lets the team reject attractive requests. [Citation: https://www.linkedin.com/feed/update/urn:li:activity:7404922495885168640/] After interviews, put each account next to the segment it came from and the job that customer was trying to get done. If the same problem recurs among your target customers, revisit the investment. If it primarily comes from customers you chose not to serve first, record the evidence and keep the current priority. ##### [Jiaona Zhang (jz)]() Tamar’s prototype loop is useful, and I’d put a second test beside it: can we deliver the experience at the scale and cost the business needs? At Airbnb Plus, we pursued in-person home inspections to give guests more confidence in a listing. In hindsight, the guest’s need was clearer information about what they were booking. Inspections gave us a way to learn, but the manual work and unit economics made that approach hard to scale. We could instead improve the details collected from hosts and the review system. [Citation: https://podcasts.apple.com/us/podcast/building-minimum-lovable-products-stories-from-wework/id1627920305?i=1000619030079] I’d make that explicit before the next round of interviews: write down the guest uncertainty we’re testing, show two ways of resolving it, and set a short checkpoint to decide which approach merits further investment. A customer’s positive response to a hands-on experience can validate the need while leaving the delivery model open. ##### [Yuhki Yamashita]() Who you interview changes the horizon of the decision. We spent time with sophisticated design teams at companies like Facebook and Airbnb because their workflows gave us a view of where other design teams might be in two or three years. That helped us weigh requests for design systems work alongside the many smaller feature requests we heard. I’d bring an advanced team into discovery when deciding which shared workflow to build for next, then check whether that workflow is appearing in the broader customer base. [Citation: https://open.spotify.com/episode/61lwEgk5WOdfSRnyPzcqcV] ##### [Shaun Clowes]() I’d recruit some interviewees from the people who abandoned setup, then have them try the first task while the team watches. In my Atlassian growth talk, I described a Confluence setup that dropped people into an empty product with no pages or spaces. We tested a two-screen flow that suggested spaces for teams, departments, or projects and helped people create them. That small change drove a double-digit increase in people succeeding and purchasing. [Citation: https://youtube.com/watch?v=Ccwmo5o5i8E] The interview question in that case is very specific: “You’ve opened an empty Confluence site. What would you do next to start working with your team?” Watch where they stop, ask what they expected to find there, then test a smaller setup change against completion and purchase. Interviews with people who already got through setup would have missed the people this change helped. ##### [Tamar Yehoshua]() An interview can change the build by making the team remove something. During Slack’s UI revision, our first prototype put everything behind one menu. We then worked back toward the elements people actually needed in front of them. That gave us a concrete question to test as people used the prototype: which actions must stay visible for them to get their work done? Every requested feature competes for attention in the same interface, so I want the team to review interview findings against the cost in complexity as well as the value of the request. [Citation: https://www.saastr.com/saastr-podcast-411-with-slack-chief-product-officer-tamar-yehoshua/] ##### [Ravi Mehta]() Tamar’s prototype loop depends on what the prototype contains. If the screen uses generic placeholder data, the customer may react to the layout while the team misses whether the experience works for their actual task. I start with a data model and realistic test data so the customer can try a plausible case. In a trip itinerary demo, I could change the trip from Paris to Thailand by swapping the data, which let the same prototype test more than one scenario. [Citation: https://www.linkedin.com/feed/update/urn:li:activity:7378480453885997056/] For the next interview, I’d bring a case drawn from the customer’s workflow, ask them to complete a task in the prototype, and record where the data or interaction breaks. Then the team can decide whether to change the proposed experience before investing in the finished build. ##### [Shaun Clowes]() Tamar’s point about complexity has a second cost in self-service software: every confusing step can create a support conversation that the team then mistakes for a permanent way to sell. At Atlassian, we tested a help prompt near the end of an evaluation. It raised purchase conversion by a double-digit percentage, yet I argued that shipping the prompt without a team fixing the underlying product problems would leave us answering the same questions indefinitely. I wanted a development team to use those conversations to improve the product, with a group held back from the prompt so we could measure whether the product itself had become easier to use. [Citation: https://youtube.com/watch?v=Ccwmo5o5i8E] If an interview reveals a blocker, I’d record the exact step where it occurred and who owns the fix. Then I’d check whether the next cohort gets through that step on its own. That connects a customer conversation to a build decision and tests whether the build actually removed the blocker. ##### [Yuhki Yamashita]() Tamar’s prototype loop reminds me of how Figma’s early team kept putting the browser-based editor in front of designers. Dylan would ask for feedback, return with changes made, and show the product again. I’d use that second conversation to ask the customer to try the changed workflow, then watch whether the original obstacle still comes up. The return visit tests our interpretation of the first interview. [Citation: https://open.spotify.com/episode/54N7O802cWOd0IsdDNF9XX] ##### [Jiaona Zhang (jz)]() The interview sample should also match the decision’s level of detail. When we worked on Airbnb supply, “grow the number of homes” was too broad a goal. Guests wanted choices in the destinations and moments they cared about, such as ski areas, beaches, or places with major events. That shifted the work toward high-quality supply in specific markets and gave the team more useful measures than total listing count. [Citation: https://review.firstround.com/dont-serve-burnt-pizza-and-other-lessons-in-building-minimum-lovable-products/] For an interview round, I’d recruit people who recently searched in the market under consideration, ask where the available homes fell short, and group answers by destination and trip purpose. If the team plans to build for a particular market, the interview findings should tell us which market and which kind of home to prioritize. ##### [Tamar Yehoshua]() Ravi’s realistic cases should lead to a measurable decision after the interview. At Slack, we described our approach as “data informed”: measure the impact of a change, while using product judgment to interpret what the measure means. For a prototype with realistic customer data, I’d record where a task fails, change the design, then measure whether users complete that task in the product. If completion improves but users still struggle to reach their intended outcome, the team needs another interview cycle to understand the gap. [Citation: https://www.saastr.com/saastr-podcast-411-with-slack-chief-product-officer-tamar-yehoshua/] #### [What to cut from an MVP, and the one part to build well]() **Question:** How do you scope an MVP down to what tests your idea? ##### [Kevin Yien]() Start by deciding how high the bar for "viable" is. Then cut everything that doesn't get you over it. Market maturity sets that bar. If you're creating a new market, customers can't describe the solution yet, so the MVP has one job: show the problem exists. In a crowded category (another productivity app, say), people compare you to great existing products on day one, so your MVP needs a lot more in it before anyone will take it seriously. The exception is coming at a crowded category from the side, supporting an existing workflow instead of replacing it, which brings the bar back down. [Citation: https://kevinyien.com/blog/mvp-levels.html] Once the bar is set, the scoping move I use is to write down the most important simplifying assumptions. Weak product sense lists every risk and complication. Strong product sense says "these are the assumptions we're making so we can ignore everything else." Sometimes there's a cheap way to validate an assumption and often there isn't, and that's fine. [Citation: https://twitter.com/kevinyien/status/1788017240232579253] Use the customer to settle scope arguments. Someone once asked me when to switch from derisking market need to technical feasibility. They were worried about one very specific, very hard scenario. So I asked whether customers cared about that scenario, and that answered it. If customers don't care about a risk, it doesn't belong in the MVP. [Citation: https://twitter.com/kevinyien/status/1491614427786919938] Sometimes the cheapest MVP has no product at all. At Berkeley our team started out building a smartphone glucometer. FDA timelines didn't fit our goal of shipping something within six months, so we went through Steve Blank's Lean LaunchPad instead and talked to nearly 100 diabetics in person over ten weeks. Those conversations told us more than a first hardware build would have. [Citation: http://projects.kevinyien.com/diabeats-web-app.html] ##### [Jiaona Zhang (jz)]() I scope from the problem inward, then cut features until one or two are left, and I build those one or two well enough that the test means something. The way I explain this to my Stanford students: say you want to test whether people like pizza, and you serve them burnt pizza. All you learn is that they don't like burnt pizza. The cheapest functional prototype often ends up testing a broken version of your idea [Citation: https://review.firstround.com/dont-serve-burnt-pizza-and-other-lessons-in-building-minimum-lovable-products/] My method, step by step: 1. Draw a vertical line. Problems go on the left. Any solution someone mentions goes on the right, gets acknowledged, and waits. Then pick the single highest-value problem you believe you can solve. 2. Write the user's why. "Wouldn't it be amazing if this product could..." has to end in value for the user. At Airbnb, "grow supply" was the business why. The user why was more listings in places people actually want to go, and that changed both what we built and what we measured. 3. Cut to one or two features that deliver that value. If you spread the product across every problem, it does all of them poorly. 4. Read the reaction. "This is cool, I can see myself using it" is a weak signal. "When can I start using it?" is the one you want. If you don't get it, the usual cause is that you picked a low-value problem. Project Harmony at Dropbox is my cautionary tale here. We shipped presence in shared Office docs, and the press was good. Users actually wanted real-time co-editing, so presence ended up showing them what Dropbox couldn't do. Every iteration after that improved a local maximum [Citation: https://review.firstround.com/dont-serve-burnt-pizza-and-other-lessons-in-building-minimum-lovable-products/] Get viable right first, then add the lovable layer on top [Citation: https://twitter.com/jiaonazhang/status/1186704144280588289] ##### [Lane Shackleton]() Kevin's simplifying assumptions are the right starting point, and I'd write them down as a stake in the ground before talking to customers so you can tell later whether the market moved you or you drifted. In the early days of Coda we spent about a month writing a core thesis doc that stated precisely what we believed. We did that before much customer research and before most of our time with alpha customers. Then we put that thesis into the market in its lightest form, which was a lot of paper prototypes. I ran probably hundreds of those interviews. [Citation: https://open.spotify.com/episode/48gh0QN9qpo5Lw19DeTjCk?si=EnucCpLHSpWX4FZJksQ7Xw] Once the belief is written down, I scope the MVP to show the upper and lower bounds of the idea instead of a polished middle version. At YouTube we were stuck debating skippable ads. The leader in the room stopped the debate and said to test the extremes and start the experiment tomorrow. Jamie Kearns launched a tiny skip button in one arm and a giant skip button covering the whole player in the other. Within a few weeks we had conviction from very directional data. [Citation: https://open.spotify.com/episode/5kgNu88xbO3INDJO46IOPK] The last step is matching the fidelity to what the idea depends on, which is jz's burnt pizza point applied to prototypes. Paper stopped working for Coda's formula builder because the value lived in how it felt to type. Our mocks grew to around 100 Figma frames trying to spell out every cursor interaction. Chris, one of our lead engineers, made it possible to spin any code branch into a full, isolated environment that customers could use. After that, a pod could write "prototypy crappy code" and put it in front of real users without touching production. The code was rough, but the interaction users were judging was real. [Citation: https://open.spotify.com/episode/3zM5TQQr6gXSDToKBIaAvl] So my scoping filter is this. Write the thesis, then cut every feature that doesn't help confirm or kill it. Push the remaining variable to its extremes, and use the cheapest format that still lets a user feel the core interaction. ##### [Nikhyl Singhal]() I scope an MVP by audience first and by features second. The question the MVP needs to answer comes from the stage you're in. Before product-market fit you're on what Dave Whorton calls the "drunken walk": stumbling around, failing fast, and lucky to plan a few steps ahead. So I write down the one assumption that kills the idea if it's wrong, and the MVP is whatever answers that in weeks. A roadmap at this stage does harm, because you can't forecast what customers want six months out. The closer to the ground, the better. [Citation: https://review.firstround.com/how-to-craft-your-product-team-at-every-stage-from-pre-product-market-fit-to-hypergrowth/] Jiaona's burnt pizza point gets stronger with AI tools, and it changes what you cut. In a recent podcast conversation about how Stripe builds, I learned that Stripe Projects (one of the hits of this year's Sessions) started with two and a half people building for a few weeks for five to ten trusted users. Early releases there go wide and feature-rich, because building is now cheap. What's expensive is user attention and trust. So keep the user group tiny and well chosen, give them enough product to judge the real experience, and read their reactions closely before you widen access. Inside a company that already has a working product, the scoping rule is one bet at a time. A year into my time at Credit Karma, we had chased so many shiny new things that our focus had swung too far from the core business. We pulled back, and only then did we launch half a dozen product lines without hurting the core. [Citation: https://review.firstround.com/going-multi-product-11-tactics-for-tackling-your-next-bet/] My test for the scope: can you name the five to ten users, the one assumption you're testing, and the result that would make you stop? ##### [Kevin Yien]() Jiaona's burnt pizza is what you get when you cut quality to save time. Nikhyl's tiny audience is one way to cut breadth instead. I'd make every breadth cut explicit and leave the quality bar alone. These are the constraints I write into the PRD before anyone designs anything [Citation: https://open.spotify.com/episode/2laKfSQoAfg7HT0ua6NfPe]: 1. Customer segment and their specific role. One segment, named. 2. The job they're trying to do, and how many different pathways to that job you're willing to entertain. Usually one. 3. Availability: desktop web, mobile web, or native mobile. Pick one surface for the MVP. 4. A short list of principles for the things you refuse to compromise on. Each constraint removes a big chunk of scope, and none of them burns the pizza. One segment doing one job on one surface can still be excellent. Ten segments on three surfaces at half quality teaches you nothing, because when the test fails you can't tell which part failed it. The tradeoff is that holding the quality bar can cost you dates. On one launch we had a strict deadline and I pushed it out three times. One animation didn't cause that. It came from a string of decisions where we said "this is what we believe we need to ship," and that mattered more than an artificial external GA date [Citation: https://open.spotify.com/episode/2laKfSQoAfg7HT0ua6NfPe]. So if the date is about to force cuts, cut segments and surfaces first. Cutting the quality of the one path you're testing should come last. ##### Question > Kevin argues that market maturity sets how much an MVP must include: a new market only needs proof the problem exists, while a crowded category needs much more before anyone takes it seriously. Ravi, from Tinder and Tripadvisor, how would you scope an MVP for a crowded consumer category? Would you build a fuller product, or come at the category from the side the way Kevin suggests? Please cite a public example. ##### [Ravi Mehta]() In a crowded consumer category I come at it from the side, and I still keep the MVP narrow. Kevin is right that the bar is higher, but I'd raise it on a single dimension where you're clearly different, and match incumbents only on what users take for granted. A fuller product built to match Tinder or Tripadvisor feature for feature loses to them, because users already have those apps and their history lives there. Swipe Night at Tinder was a side entry inside the most crowded category we had. It didn't add another swiping feature. It was an interactive, choose-your-own-adventure event built for Gen Z that gave people something to talk about and a new reason to match. The scope was one event format aimed at one audience, and the part users actually saw had to be excellent. Suno shows the same move for a startup. When I talked with Mikey Shulman on my podcast, we covered why Suno launched its first product on Discord. Discord gave them distribution and a feedback channel they didn't have to build. Early subscriber feedback shaped the roadmap, and the web app came later, which is when growth took off. [Citation: https://www.linkedin.com/feed/update/urn:li:activity:7455712232124006400/] Being crowded also changes what you measure. In a crowded category trial is cheap and comparison happens immediately, so first-session excitement tells you almost nothing. My test is whether people come back to your wedge even though the incumbent is one tap away. Facebook ranked retention above user growth and checked that features actually engaged people before scaling them. I'd hold a crowded-category MVP to that bar before spending anything on acquisition. [Citation: https://www.linkedin.com/feed/update/urn:li:activity:7174404000690135040/] Small numbers make the result easy to misread, so pair the retention data with user conversations. The data tells you whether people returned, and the conversations tell you whether they came back for your wedge or for things the incumbent already does. [Citation: https://www.linkedin.com/feed/update/urn:li:activity:6699493910126837761/] ##### Question > Lane tests ideas with deliberately rough versions: a giant skip button covering the whole YouTube player, and "prototypy crappy code" for Coda's formula builder. Kevin says to cut segments and surfaces first and cut quality on the tested path last. Jiaona, by your burnt pizza test, when does a rough prototype still give a valid read, and when does it burn the pizza? Name one thing you would leave rough and one you would never leave rough, using a public example. ##### [Jiaona Zhang (jz)]() A rough prototype gives you a valid read when the roughness sits outside the thing the user is judging. It burns the pizza when the rough part is the value itself. Lane's two examples both pass that test. A giant skip button looks ugly, but skipping actually works. Coda's branch code was rough, but typing a formula felt real. The thing I would never leave rough is the core interaction. Project Harmony is where I learned that. We shipped "see who else is in this doc" and treated it as a fair first step toward collaboration. The thing people love in Google Docs is watching each person's edits land in real time, cursor by cursor. Our presence-only version left out that experience, so it tested a weaker idea and ended up showing users what Dropbox couldn't do yet [Citation: https://review.firstround.com/dont-serve-burnt-pizza-and-other-lessons-in-building-minimum-lovable-products/] The things I'd happily leave rough are operations, scale, and the parts of the product people take for granted. On Airbnb Plus, we inspected homes with people on the ground, which was slow and expensive. It still told us what guests valued. Once we learned the manual approach wouldn't scale, I moved off and worked on the review system, because the scalable version was automated checks at the moment a host uploads a listing [Citation: https://podcasts.apple.com/us/podcast/building-minimum-lovable-products-stories-from-wework/id1627920305?i=1000619030079] Plus also shows the opposite failure. Our first quality bar was a 200-point hotel amenity list, and requiring all of it would have left us with zero qualified homes. We kept quality high on the one thing that sets Airbnb apart, the feeling of a real home, and built a Home Tour that lets guests walk through each room in photos. That was far cheaper than putting physical items into homes [Citation: https://review.firstround.com/dont-serve-burnt-pizza-and-other-lessons-in-building-minimum-lovable-products/] So mark the one moment where the user should say "when can I use this?" Build that moment to full quality, and leave everything around it rough. ##### Question > Nikhyl, your scope test ends with naming the result that would make you stop. Ravi warns that MVP numbers are small and easy to misread, and judges a wedge by whether people come back when the incumbent is one tap away. With only five to ten trusted users, how do you write that stop result before launch so you can't move the goalposts later? Please give one public example of a team that set or missed a kill threshold. ##### [Nikhyl Singhal]() With five to ten users, I write the stop result as named behaviors, because percentages mean little at that size. Before launch the owner writes something like: "By the end of week three, at least six of these ten people have come back on their own, and at least three have asked when they get more. If we fall short, we stop or change the bet." The team gets that page before anything ships, and it also sets how big the team is allowed to grow. Tido Carriero describes this gate well. He keeps a new product to about three engineers, a PM and a designer until there is clear evidence of pull. That evidence can be revenue, or even a screenshot of a customer asking whether it will be ready next week. He has also seen projects where 30 to 50 engineers worked for six to twelve months and the product never took off, because the team never understood the problem well enough for a customer to repeat it back with excitement. [Citation: https://review.firstround.com/going-multi-product-11-tactics-for-tackling-your-next-bet/] The missed version is usually "popular, but small." Todd Jackson tells the story of Carousel at Dropbox. It was a beautiful photo app, very popular in some circles, and a lot of people worked on it. It just wasn't growing enough to matter to the company, so they shut it down and put everything into the SaaS business ahead of the 2018 IPO. [Citation: https://review.firstround.com/going-multi-product-11-tactics-for-tackling-your-next-bet/] That's why the stop rule needs two lines. One says whether these users love it. The other says whether the bet can get big enough to matter. At Credit Karma, those enthusiastic side bets are what pulled our focus too far from the core business. The person who owns the bet should sign the page, which before product-market fit means the founder. In my startups, PMs I hired early to find the winning idea sometimes didn't feel empowered to call a stop. [Citation: https://review.firstround.com/how-to-craft-your-product-team-at-every-stage-from-pre-product-market-fit-to-hypergrowth/] #### [Handling feature requests without letting them write the roadmap]() **Question:** How should a product team handle the steady stream of feature requests for its roadmap? ##### [Tamar Yehoshua]() Route requests by where they come from. A single backlog can't handle all of them, so at Slack we ran separate channels for each source: 1. **Escalations from support.** We put a product specialist on each major pillar. These were usually our strongest support people, and they sat with the product team and resolved issues frontline support couldn't. We started with one team, added another the next quarter, and kept going until every pillar had one. 2. **Enterprise gaps from the field.** Sales and support logged product gaps. Someone in sales ops owned that list and attached the pipeline tied to each gap, so we could rank the big asks, like Enterprise Key Management, by the revenue they would unlock. Product leads and sales met quarterly to review it. The process only got organized once one sales ops person drove it, because before that everyone was just throwing requests in. [Citation: https://youtube.com/watch?v=Dh0pcGozAXU] 3. **Community.** We put someone in charge of building a community of champions, because a community doesn't grow on its own. Each channel still feeds the PM's judgment. The PM's job is to work out what customers actually need, which is often different from what they ask for. Nobody asked us for Huddles. Customers kept telling us to add video like Teams and Zoom. We saw the real problem was that remote work had removed the spontaneous hallway conversation, and we solved that instead. [Citation: https://youtube.com/watch?v=Dh0pcGozAXU] Every new feature also has to pass a complexity check. Adding requested features one at a time is death by a thousand cuts, and every PM thinks their feature belongs front and center. By the time we redesigned Slack's UI, it had become too cluttered. In the first prototype we hid everything behind one menu, then brought back only what truly needed to be visible. Now we test every new feature against our "don't make me think" principle. [Citation: https://www.saastr.com/saastr-podcast-411-with-slack-chief-product-officer-tamar-yehoshua/] ##### [Noah Desai Weiss]() Give every request a home, and keep the stack-rank debate for the work happening soon. At Foursquare we went through several roadmap systems, including a few rounds of OKRs, and none stuck until #now, #next, #later. #now covers the next 2–4 weeks, #next is 1–3 months out, and #later is everything 3+ months away. #later turned out to be the most useful bucket. It's where ideas people care about get parked, and because you'll revisit the whole list in a few months, you don't have to rank it carefully. That alone ended a lot of endless debates [Citation: https://medium.com/p/1cfe65656645]. Here's how the intake worked in practice: 1. Agree on a few company-wide goals first, such as weekly active mobile users or revenue, plus a clear model of the levers that move them. Each request then gets judged by which lever it pulls. 2. Pull every idea into one doc: research findings, whiteboard notes, Asana tasks. Then invite leads from other teams to add their favorites. People feel heard, and the team can still be ruthless about what it actually takes on. 3. The PM and eng lead do the first pass at bucketing, teammates weigh in, and then leadership reviews it. 4. Use the buckets as tags on tasks. Anyone filing a request tags it, and when the triager changes the tag, that change tells the requester where it landed without a meeting. Once every team used the same structure, rolling up the company's #now and #next work took about an hour [Citation: https://medium.com/p/1cfe65656645]. The second habit is setting a portfolio split up front so the request queue can't fill the whole roadmap. Requests are almost always incremental. At Slack, my guess (I never actually ran the numbers) was that we looked roughly 60/35/5: core improvements, new adjacencies, and speculative bets. Infra and quality teams ran much closer to 95/3/2 [Citation: https://open.spotify.com/episode/3Qca5n2wKfmlZtcINj5nK5]. If you don't protect the bigger swings on purpose, the incremental requests will crowd them out [Citation: https://medium.com/p/94b80e1522f4]. ##### [Kevin Yien]() Most teams overfit. The usual failure is adding functionality that matches exactly what customers say. A request comes in, it goes on the backlog, and when it shows up three more times it starts to look like a pattern. Usually it's missing context: it came from the wrong stakeholder, or the customer was in the middle of a change at their company. I've written up a hypothetical project management tool to show how this plays out. Customers asked for 11 different custom fields, and those customers made up 40% of revenue. Each field took less than a week to build, so the team shipped them all and got thank-you emails. Then the churn started. Those customers' processes had changed so the fields were useless to them, and the pile of everyone else's fields had made the product unusable. They left for Google Sheets and Notion because those felt "simpler" and "more flexible." [Citation: https://kevinyien.com/blog/overfitting.html] So my framework is three filters, applied before anything reaches the roadmap: 1. Customers tell you problems. Write down the problem behind each request and throw away the proposed solution. 2. The loudest voice is rarely the most important one. Weight requests by segment and ICP fit, and ignore volume and escalation heat. 3. Decide how elastic the product should be. If a dozen requests are variations on "let me add a field," the answer is probably one flexible primitive. Shipping a dozen point features is the brittle answer. Intake matters too. Sales hears more about customers' problems than any PM does, so when a rep says "customer X wants Y," ask which conversation prompted it, ask to talk to that customer, and join the next call. [Citation: https://kevinyien.com/blog/sales-research.html] At smaller companies process matters more than tooling. Have each department bring synthesized feedback to a dedicated forum, and get product tagged into Slack and Gong threads so it keeps a running sense of who is saying what. [Citation: https://twitter.com/kevinyien/status/1515120424392273925] ##### [Yuhki Yamashita]() Tamar's Huddles story is the "why are they asking" step. I'd push one level further: ask why the customer has that problem in the first place. Our engineering team at Figma runs "five whys" in postmortems, and PMs can do the same with a request. Fixing the condition that created the problem often has more impact than shipping the feature as asked. [Citation: https://open.spotify.com/episode/54N7O802cWOd0IsdDNF9XX] This gets harder when your customers are builders. Designers send us exact mockups of what they want, which removes all ambiguity. They also get frustrated when we don't build it, since "I even drew it for you." Often the right move is to unpack the mockup, find the root problem, and design something better, and that means managing expectations along the way. [Citation: https://www.youtube.com/watch?v=actpb5rk8eo] On routing, I agree with separating sources, and I'd add that each one is biased in its own way. Support tickets lean dissatisfied. Prospect conversations are mostly about perception. Twitter is a vocal minority, and most of our audience isn't on it. I treat a loud tweet as an early warning and check it against research and data. [Citation: https://open.spotify.com/episode/54N7O802cWOd0IsdDNF9XX] Leaders need a container too. Dylan reads more customer feedback than any of us, and when he dropped tweets into team channels, people felt they had to drop everything. So we made a small "concerning tweets" channel where those signals, sometimes with zero likes, get reviewed without derailing the team. [Citation: https://www.youtube.com/watch?v=NepFo4zXyK4] Last, show customers the tradeoff. When someone brought me ten asks, I'd show what we were already building and ask whether they'd swap any of it. Usually they said no, and they left feeling heard. [Citation: https://www.youtube.com/watch?v=actpb5rk8eo] ##### [Tamar Yehoshua]() I agree with Noah that you have to protect a portion of capacity on purpose. That protected portion should cover stability and reliability as well as the big bets, because nobody files a feature request for performance. In growth-stage companies I've seen teams worry that the board won't accept stability work. In my experience, boards only get involved when something breaks: customers churn because the product isn't reliable or doesn't meet their needs, or revenue growth slows. If you staff reliability ahead of time, you can keep making your own prioritization calls. [Citation: https://www.produxlabs.com/product-thinking-blog/2024/9/11/episode-188-how-ai-is-redefining-enterprise-productivity-with-tamar-yehoshua-of-glean] A request queue also pushes teams to report the roadmap as a list of features: this quarter, next quarter, the one after. In board meetings I've watched eyes glaze over at those lists. Start with the problem and why customers care, then show a demo or mock-ups. Keep the quarter-by-quarter detail as backup so you can answer "what are you launching next quarter?" when someone asks. [Citation: https://www.produxlabs.com/product-thinking-blog/2024/9/11/episode-188-how-ai-is-redefining-enterprise-productivity-with-tamar-yehoshua-of-glean] Teams that build for themselves need a check on their own judgment as well. Early Slack was built by people who used it all day, and we had to learn that expert power users are very different from customers at other company sizes, in other countries, or in other industries. [Citation: https://youtube.com/watch?v=Dh0pcGozAXU] One exercise helps here. Have the team step through the product as a specific person, for example someone whose boss told them to evaluate Slack right before lunch, and write down everything that breaks. That exercise turns up problems no request queue ever will. [Citation: https://www.saastr.com/saastr-podcast-411-with-slack-chief-product-officer-tamar-yehoshua/] ##### [Lane Shackleton]() Tamar's routing and Noah's #now/#next/#later both deal with intake. The part I see break most often comes after that, when the plan you rallied the team around gets reopened. I think a lot of us have done a ton of prioritization work, only to have the head of engineering or a design lead blow it up in one meeting. That's one of the worst feelings in the world. And the usual fix, twenty 1:1s to pre-wire everyone, just turns the PM into a telephone operator. So when competing requests need to be ranked, I do an internal version of Yuhki's "would you swap any of it" question. I run the major stakeholders through a $100 voting exercise. Every candidate problem or feature goes in a table, and each person splits an imaginary $100 across it. That takes the priorities that usually stay implicit, behind closed doors or in an exec staff meeting, and puts them where everyone can see them. It also leaves a record of everyone's early stance. The most useful part is the follow-up. If someone put $50 on something that didn't make the cut, you know exactly who to go talk to before they reopen it later [Citation: https://coda.io/blog/product-teams/shreyas-doshi-lane-shackleton-next-level-tactics]. A smaller habit also keeps requests from going around the process. Keep a shared table of upcoming decisions, with a button stakeholders press to be included. A requester can see when their ask will be decided, so they have less reason to escalate around it [Citation: https://coda.io/blog/product-teams/shreyas-doshi-lane-shackleton-next-level-tactics]. Kevin's point about not just counting requests is right, and for us the best defense was being in the queue ourselves. For Coda's first few years everyone rotated through the support queue for a day, execs and engineers included. It made timelines harder to forecast, but knowing customers by name made it much easier to tell a loud request from a widespread one [Citation: https://lane.substack.com/p/doing-things-that-dont-scale-as-a]. ##### [Noah Desai Weiss]() Kevin's custom-fields story is the failure mode to design against, and the decision doesn't stop at whether to build a request. How you build it matters as much, and that's where most of the risk sits. Even experiment-driven teams see fewer than 40% of their launches actually win. So I'd treat any request that makes the cut as a hypothesis and ship the smallest version that tests it [Citation: https://medium.com/p/444de1793dda]. Three questions I use on a request that has made it into #next: 1. What is the fastest path to learning? Some launches are "earning" launches, where you're confident customers get a quick win. Others are "learning" launches, which tell you whether there's a bigger need underneath. A healthy roadmap needs both. Judge PMs on how fast they learn in the short term and on impact over the long term [Citation: https://medium.com/p/444de1793dda]. 2. Are there cheat codes? Smart defaults with fewer advanced settings, building it to scale for only a subset of customers, heuristics in place of complex algorithms. Kevin's 11 fields would have looked very different if the team had asked this question first [Citation: https://medium.com/p/444de1793dda]. 3. Is there a 2-way door? If the decision is easy to reverse, decide fast. If it's a one-way door, take the time to work through the biggest risks [Citation: https://review.firstround.com/how-to-take-bigger--bolder-product-bets-lessons-from-slacks-chief-product-officer/]. The third question also tells you who should make the call. At Slack, each pillar reviewed its own smaller features and experiments. Exec reviews with the product, design, and engineering leads skipped "let's run through the 15 features launching soon" and spent the time on one-way door decisions and the overall portfolio [Citation: https://www.youtube.com/watch?v=HTzrs1_5RdQ]. When every request gets escalated to leadership, the important calls wait in line behind small ones. ##### Question > Tamar, your Slack process ranked enterprise gaps by the pipeline attached to each one. Kevin's overfitting example describes the opposite outcome: customers worth 40% of revenue asked for 11 custom fields, the team shipped them all, and those customers churned anyway. What in the quarterly product and sales review kept a high-pipeline request from becoming one of those 11 fields? If you can, name one big ask you turned down or reshaped into a broader feature despite the revenue attached, and cite a public source. ##### [Tamar Yehoshua]() The guard was mostly in what qualified for the gaps list in the first place. The asks that carried real pipeline were usually large platform capabilities like Enterprise Key Management, which a whole segment of buyers required before they could adopt Slack. The review asked what each gap would unlock across that pipeline. [Citation: https://youtube.com/watch?v=Dh0pcGozAXU] That's a different shape from Kevin's 11 fields. Those were per-customer customizations, and the revenue attached to them was concentrated. Pipeline was one input into the review. It didn't replace product judgment. The second guard was ownership. The field reported gaps, and PMs decided what to build. In the same talk I said I don't expect the people reporting an issue to arrive with the underlying problem defined. The product manager's job is to work out what customers actually need, which isn't always what they ask for. [Citation: https://youtube.com/watch?v=Dh0pcGozAXU] The clearest reshape I've described publicly is Huddles. Customers kept asking us to add video like Teams and Zoom. We decided the problem underneath was that remote teams had lost spontaneous hallway conversations, so we built lightweight audio inside channels and DMs. It became our fastest-growing feature ever. [Citation: https://youtube.com/watch?v=oNqYeu8o5II] I haven't publicly named an enterprise deal we turned down, so I won't invent one. The third guard is pricing in the cost of retiring a feature, because that cost is what made Kevin's example hurt. Slack Calls is our version. Some customers relied on it, but it didn't work well, and even with Huddles growing fast, moving everyone off Calls took about two years. [Citation: https://youtube.com/watch?v=oNqYeu8o5II] When a high-pipeline request looks like a customization that only one segment's current process needs, the multi-year cost of supporting and eventually sunsetting it belongs in the quarterly review next to the pipeline number. ##### Question > Kevin, Lane ranks competing requests by having major stakeholders split an imaginary $100 across them, which makes everyone's priorities visible. Your filters say to weight requests by segment and ICP fit and to ignore volume and escalation heat. Does a stakeholder vote bring the loudest-voice problem back inside the company, for example a sales lead putting $50 on one big customer's ask? What would you require on each row of that table before people vote, so the vote reflects the problem and the customer segment? Please cite only public sources. ##### [Kevin Yien]() It can, yes. A $100 vote makes stakeholder priorities visible, but if the rows are solutions with a customer name attached, you've just moved the escalation into a spreadsheet. The vote is only as good as what's on each row. Before anyone votes, every row needs: 1. The problem, written as a problem. "Acme wants a status field" goes in the evidence column. The row title says what the customer is trying to do. 2. The segment, plus whether it matches the ICP. If the row is "one strategic account," it should say so plainly. 3. Links to the raw evidence. I mean the actual conversations, such as timestamped Gong snippets feeding a database, and the summary a rep wrote from memory doesn't count. [Citation: https://kevinyien.com/blog/sales-research.html] 4. A count of distinct customers, with any context that could make it noise: the wrong stakeholder, or a customer going through a reorg. Repeated feedback looks like a pattern even when it isn't one. [Citation: https://kevinyien.com/blog/overfitting.html] 5. An elasticity note saying whether this is a segment-wide capability or a per-customer customization. That's Tamar's distinction, and it's the one my 11-fields example failed. None of this is meant to shut sales out. Sales is a research function, and those reps talk to ideal customers more than any PM does. [Citation: https://kevinyien.com/blog/sales-research.html] So when a sales lead puts $50 on one account's ask, the PM's follow-up is to join that customer's next call before the vote closes. Then log the outcome. Write down what won, why, and what you expected, and check it six months later. Product sense comes from reps of deciding, recording the rationale, and seeing what happened. [Citation: https://open.spotify.com/episode/2laKfSQoAfg7HT0ua6NfPe] Over time that log shows whose $50 bets actually paid off. #### [Judging a new feature against the bar set before launch]() **Question:** How do you tell whether a new feature worked? ##### [Yuhki Yamashita]() Before launch, I ask the team to write the headline they want to be able to say about the feature, then grade themselves against it afterward. For a while at Figma I actually deprecated OKRs for this reason. On design systems, the team's metric was "more usage of design systems features." Nobody watched it day to day, they built what they thought mattered and crossed their fingers at quarter end, and nobody wanted them chasing it daily either, because that pushes you to force people into a feature. So we swapped in headlines, the claim you want to make by end of quarter, plus a self-assigned letter grade (B+, A-) and an explanation of how you got there. The explanation told me far more about whether something worked than the number did. [Citation: https://www.youtube.com/watch?v=yneNIsQtFHI] Metrics usually fail in one of two ways. One is a secondary metric you can move but haven't shown matters, like a survey satisfaction score with no proven link to retention. The other is a business goal you can't really move. When I was PM for the Uber rider app, I could have claimed incremental trips, but there are too many hops between a better experience and that number to prove anything. So I check three things in any success measure: is it understandable, is it actionable, and is it an honest picture of what the team does every day. [Citation: https://open.spotify.com/episode/54N7O802cWOd0IsdDNF9XX] The harder case is when the customers aren't like you. Branching and merging was a big investment that customers asked for, and early adoption was low. Some of that was performance and some was how unfamiliar the workflow was. The rest came from gaps we only found while helping customers implement it, because we don't use it much ourselves. Our habit of heavy internal dogfooding works well for features we use every day. For enterprise workflows, we had to get much closer to real customer rollouts to know whether the feature worked. [Citation: https://www.youtube.com/watch?v=NepFo4zXyK4] ##### [Jiaona Zhang (jz)]() I decide what "worked" means before we ship, and I write it as a branch on a KPI tree. Business output metrics sit at the top: signups, subscriptions, or at Airbnb, nights booked. Every exec and every team shares those. Below them are the input metrics that drive them, like how many subscriptions we need and how many people we need to keep from churning. At the bottom are the product metrics a team can actually move after a launch. [Citation: https://www.youtube.com/watch?v=IHef1S89_d0] So for a new feature I read the results in three layers, in the order they show up: 1. Adoption. Out of the target audience that could use the feature, how many actually do? 2. Sentiment. Do those users like it? A random-sample survey or NPS works, or just go talk to people. 3. Behavior change. Do we see churn go down, retention go up, or activation go up? This layer ties back to the top of the tree. Output metrics take the longest to come back, so I don't wait on them to start learning. If customers have been asking for something like localization, put an alpha in front of them. Within an hour of sitting with them, you'll hear "this is the thing I've been wanting," and that counts as data. Ask which kind of data you're trying to get back: qualitative, an input, or an output. [Citation: https://www.youtube.com/watch?v=IHef1S89_d0] Defining success up front also keeps the team honest. When the goals are written down, the product, engineering, and design leads can each say whether the feature is on track. When the goals aren't written down, nobody reports that anything is off track. [Citation: https://www.youtube.com/watch?v=IHef1S89_d0] ##### [Nikhyl Singhal]() I agree with Yuhki that the work starts before launch. I'd push his headline one step further: write down concrete examples of a win and a loss, specific enough that nobody can argue about the result afterward. The Gemini team has the cleanest public version of this I've seen. Their practice starts with "take 20 prompts": twenty replicable examples of the problem where a win and a loss are obvious. That turns a vague ask like "make the information architecture better" into something people can agree on and then measure. One of their leads says the scarce skill is "saying, precisely, what good looks like." [Citation: https://theskip.substack.com/p/inside-gemini-how-google-runs-product] The same discipline applies to non-AI features. Write the eval before you write the launch post. After that, the method depends on the stage of the bet: 1. Mature surface at scale (Facebook Feed, for example). You prove incremental lift against a holdout group. When a feature shares a surface with dozens of others, raw usage of the new feature tells you almost nothing, because some of that usage is just moved over from other parts of the app. 2. New product or new bet. Holdout math is too early here. You look for customer milestones, meaning sales numbers or strong qualitative pull, before you add headcount. In our First Round piece on going multi-product, Tido Carriero (Segment, Dropbox) describes the common trap: teams staff up a new product before they have good customer feedback, and it never gets off the ground. [Citation: https://review.firstround.com/going-multi-product-11-tactics-for-tackling-your-next-bet/] Whatever the stage, a feature worked only if it moved the metric you committed to before launch. If the team has to hunt for a different metric that improved, the feature didn't work. ##### Question > Yuhki described replacing OKRs at Figma with a headline written before launch and a self-assigned letter grade afterward, because usage metrics pushed teams to force people into features. Ravi, Tinder and TripAdvisor ran on A/B tests and revenue metrics. When would a self-graded headline mislead you about whether a feature worked, and what would you check alongside it? ##### [Ravi Mehta]() A self-graded headline misleads you when the team writing the explanation is the same team that needs the feature to have worked. Good product decisions balance intuition, analytics, and user feedback, and most companies lean toward one mode and miss things. [Citation: https://www.linkedin.com/feed/update/urn:li:activity:6699493910126837761/] A headline plus a letter grade is mostly intuition. It's great at surfacing why something happened. It's weak at catching a feature that people tried once and dropped, because the team remembers the launch and the customer quotes, while the drop-off only shows up in the data. The risk Natalie Rothfels and I wrote about in our Reforge goal-setting piece applies here: "performance theater," where goal-setting turns into presenting progress instead of making it. [Citation: https://www.linkedin.com/feed/update/urn:li:activity:7004168365053227010/] Over a few quarters, a B+ with a well-written explanation can drift into exactly that. So I'd keep Yuhki's headline and pair it with two checks: 1. Retention on the feature. Facebook ranked retention above user growth and verified that a feature actually engaged people before scaling it. [Citation: https://www.linkedin.com/feed/update/urn:li:activity:7174404000690135040/] If the headline says "teams adopted design systems" but repeat usage is flat after week four, the grade should drop. 2. A written link to the strategy. At Tinder, no single metric captured "help people match and talk with the people they want to meet," so each team chose its own metrics and tied them to the strategy with an explicit argument. Nobody forced them into one number. [Citation: https://www.linkedin.com/feed/update/urn:li:activity:7004168365053227010/] The headline should name the metric and explain why moving that metric moves the strategy. That gives a reviewer something to disagree with. Where you can run a clean A/B test, the test result decides whether the feature worked. The self-grade is still useful there, because the team's explanation tells you what to build next. ##### Question > Nikhyl set a strict rule: a feature worked only if it moved the metric the team committed to before launch, and if the team has to hunt for another metric that improved, it didn't work. Yuhki, your teams' self-assigned letter grades came with an explanation, and that explanation sometimes told you more than the number did. When a team misses its headline but makes a convincing case that the feature still worked, how do you decide whether to accept that case? Can you give an example from Figma, such as branching and merging, where you went one way or the other? ##### [Yuhki Yamashita]() I accept the case when the explanation names a specific reason the metric missed and a specific thing the team will do about it. I reject it when the explanation finds a different number that went up. Nikhyl's rule catches the second pattern, and I agree with him there. The first pattern is a diagnosis, and it keeps the original metric as the bar. Branching and merging is the example where we stuck with it. It was a big investment, customers had asked for it, and early adoption was low. The team's explanation broke the miss into three causes: performance, a workflow that was foreign to most teams, and gaps we only found while helping customers implement it, because we don't use it much ourselves. Each of those causes pointed to concrete work, and none of them meant customers didn't want the feature. That's the kind of case I'll accept. Some of our complex features simply took a while to take off. [Citation: https://www.youtube.com/watch?v=NepFo4zXyK4] The third cause taught us the most. Internal dogfooding had been how we made sure quality was good enough, and it stops working once you build for organizations that look nothing like Figma. So for features like branching, a convincing explanation has to include evidence from real customer rollouts. A team's own read of a workflow it doesn't use isn't enough. Ravi's point about drift is fair, and it matches what happened to us. As we scaled, we brought in data science, wanted more accountability, and reintroduced OKRs. We still haven't found a perfect system. [Citation: https://www.youtube.com/watch?v=yneNIsQtFHI] I'd still read the explanation first, because the number alone can't tell you whether a feature is failing or just slow to take off. ##### Question > Yuhki accepts a missed metric only when the team names a specific cause and a fix, and he rejects it when the team finds a different number that went up. Branching and merging adopted slowly because of performance, an unfamiliar workflow, and gaps found only in customer rollouts, so Figma kept the original bar and waited. Nikhyl, under your rule, do you also commit before launch to the date when the metric gets read? At Facebook or Credit Karma, how did you tell a feature people were still learning apart from one nobody wanted? ##### [Nikhyl Singhal]() Yes, I'd commit to the read date before launch along with the metric. Without a date, "it's still ramping" can be said every quarter, and that's the same metric-hunting problem in a different form. Yuhki's branching example fits this rule, because the team named the causes and then kept the original bar with a new date attached. To tell a feature people are still learning from one nobody wants, I look at the users who got all the way through the learning curve. If the people who completed setup keep coming back, the feature works and the problem is onboarding, performance, or discovery, which are all things you can fix. If even those users drop off, more time won't help. That's the same distinction Yuhki made with real customer rollouts: the customers who actually implemented branching were the evidence that counted. On a mature surface like Facebook Feed, I'd add a check on whether the gain is net. A new Feed unit can show strong adoption because it got prime placement, and some of that usage comes out of other features on the same surface. That's why Feed PMs proved wins with holdout math. You hold a slice of users back and compare total engagement, which shows whether the app gained or just moved usage around. Ravi's retention check has the same weakness if you measure it on the feature alone: repeat usage of the new unit can look healthy at week four while total time in the app stays flat. So on a big surface, the read date answers "is it done ramping," and the holdout answers "did the product get better." For a new bet, I'd skip the holdout and use Tido Carriero's test from our First Round piece: hit customer milestones before you add headcount. [Citation: https://review.firstround.com/going-multi-product-11-tactics-for-tackling-your-next-bet/] ##### Question > Nikhyl argued that adoption and feature-level retention can both look healthy while the product as a whole doesn't improve, because a new feature with prime placement pulls usage from other features. On Facebook Feed, only a holdout showed whether the app gained. jz, your three layers start with adoption. At Webflow or Linktree, where sample sizes or enterprise contracts may rule out a clean holdout, how did you check that a feature added value overall and didn't just move usage around? ##### [Jiaona Zhang (jz)]() Without a holdout, I check it at the top of the KPI tree. That level is the one place usage can't just be shuffled around. Every team shares the same business metrics at the top: subscriptions, churn, and for enterprise, whether the sales team can actually sell the thing. If a feature's adoption climbs and none of those move, the feature most likely pulled usage from somewhere else in the product. For enterprise features I watch the sales read on purpose, even though it takes longer to come back than adoption does. [Citation: https://www.youtube.com/watch?v=IHef1S89_d0] This is directional, and it can't give you Nikhyl's holdout math. Lots of things move the top-line metrics at once. To make up for that, I write the expected link down before launch, for example "this feature should show up in the conversion rate for this segment," so a flat top line counts against the feature. The worse trap is a strong local number. I see growth teams do lots of small things to hit their number, when the real step change would have come from a core product change. [Citation: https://www.youtube.com/watch?v=IHef1S89_d0] Project Harmony at Dropbox is my own example. The badge showed who else was viewing or editing a shared Office doc. It got great press and more early access requests than any other Dropbox feature that year. But users wanted real-time co-editing, and avoiding conflicted copies wasn't what they cared about. So every round of iteration on Harmony was optimizing a local maximum, and we should have put that effort into work like what became Dropbox Paper. [Citation: https://review.firstround.com/dont-serve-burnt-pizza-and-other-lessons-in-building-minimum-lovable-products/] When the sample is too small for any math, I listen for the user's reaction. "I can see myself using this" means viable. "When can I start using it?" means you've solved a high-value problem. [Citation: https://review.firstround.com/dont-serve-burnt-pizza-and-other-lessons-in-building-minimum-lovable-products/] ##### Question > jz described Project Harmony at Dropbox: the badge hit its committed numbers and drew more early access requests than any other feature that year, but users actually wanted real-time co-editing, so each iteration only optimized a local maximum. Kevin, on Square's restaurant product or the Stripe Dashboard, how do you tell whether a feature that moved its metric solved a problem merchants care about? What signal has caught that for you, and can you name a case? ##### [Kevin Yien]() The signal that has caught it for me is whether more of the merchant's business runs through you after the feature ships. Usage of the feature doesn't count toward that. On Square for Restaurants, the number I watched was average GPV per merchant, meaning the payment volume each restaurant processed on Square. It went from about $250k to $650k over the time I ran the product. We shipped a lot in that stretch, including the largest set of delivery-service integrations Square had launched. I can't give you a clean attribution of that growth to any one feature. But GPV per merchant made the Harmony trap hard to fall into, because a restaurant only moves more volume onto Square when we've solved something real in how it operates. A feature that restaurants liked and that left GPV flat was a feature that didn't matter enough. Harmony is also how overfitting usually plays out. Precision is hitting a target consistently. Accuracy is hitting the right target. [Citation: https://kevinyien.com/blog/overfitting.html] You hear a request three times, it looks like a pattern, and you build exactly what was described, so the people who asked love it. Record early-access demand is what that looks like. The request was missing context about the job they were trying to get done, so the underlying problem never moved. For the Dashboard, GPV is too far removed from most features, so I look at the inverse. Jeff Weinstein at Stripe describes logging "users having a bad day," for example a 404 or a payout that lands a day after the ETA, and tracking that count as a metric. [Citation: https://www.blitzllama.com/blog/stripe-product-management-practices] If merchants who got the feature have fewer bad days, it solved something they care about. That count moves within weeks, which means you get jz's top-of-tree answer without waiting a quarter for churn. #### [Getting stakeholders to agree on scope, and keeping it agreed]() **Question:** How do product managers keep stakeholders aligned on scope? ##### [Kevin Yien]() Put a draft in front of people. At Square, I joined a new product line where the team had designs and a slide deck, but people had different ideas about what the PRD was supposed to settle. My job was to define the bounds of the problem so engineering and design could explore freely inside them. Spell out the user and their job, the surfaces you will support, and a real trade-off, such as speed versus data consistency. Those choices make scope debatable before people build against different assumptions. [Citation: https://open.spotify.com/episode/2laKfSQoAfg7HT0ua6NfPe] Then get feedback in a 20-minute silent read. Have stakeholders comment on the draft in the room, respond to the comments, revise the document, and record the decisions in the PRD. A request that changes the agreed bounds should reopen the trade-off explicitly. Otherwise the team can quietly accumulate incompatible promises. [Citation: https://open.spotify.com/episode/2laKfSQoAfg7HT0ua6NfPe] ##### [Ravi Mehta]() Write down the scope choices that people are most likely to reopen. In strategic planning, I recommend documenting "non-goals" alongside the work you chose, so stakeholders can see the specific alternatives the team set aside. [Citation: https://www.linkedin.com/feed/update/urn:li:activity:6958851455126556672/] For a project, I'd put the customer problem, the outcome, the committed work, and the deferred requests in one shared decision record. When someone proposes an addition, ask which agreed item should move or whether the outcome has changed. Record the decision and who made it, then use that record in the next stakeholder update. That makes a scope change an explicit choice with a cost. ##### [Jiaona Zhang (jz)]() I’d start by making the scope decision visible before anyone debates features. In planning at Linktree, I asked teams to work against a clear staffing constraint and surface what they could not do with that capacity. If the cut list was tiny, I’d question whether we were being realistic. That gives stakeholders a concrete choice: accept the excluded work, change the goal, or change the capacity. [Citation: https://review.firstround.com/annual-planning-sucks-a-cpo-cro-cfo-and-coo-share-advice-on-how-to-make-it-better/] Then explain the work in a few user-centered themes that someone can repeat in 30 seconds. I’ve found that people can debate a theme and its sequence much more usefully than a list of 50 features. As new evidence comes in, revisit the theme and the trade-off with the team, then update the scope and the cut list in the same place. [Citation: https://review.firstround.com/podcast/from-pm-to-vp-of-product-jiaona-zhangs-career-advice-from-webflow-airbnb-dropbox/#content] ##### [Tamar Yehoshua]() I would make scope a shared decision between product, engineering, and design. At Slack, we used OKRs to state what mattered and how we would measure it, reviewed them regularly, and had engineering and product work toward the same objectives. Cal Henderson and I held the reviews together, so teams heard one set of priorities and could discuss the build cost alongside the customer need. Infrastructure work still had its own roadmap, with product aware of the resources it required. [Citation: https://podcasts.apple.com/us/podcast/cpo-at-slack-on-becoming-product-centric-strategy-and-ai/id1573456164?i=1000632745455] Then give stakeholders something concrete to react to at each milestone. Our Slack principle was "prototype the path": show a slide deck or prototype to someone outside the team, get feedback, and use that evidence to decide what belongs in the next release. When remote work drove a surge of new Slack sign-ups, we changed our roadmap to redo onboarding. A PM should explain a scope change in the same terms: what changed for customers, which priority moved, and what work the team will pause. [Citation: https://podcasts.apple.com/us/podcast/cpo-at-slack-on-becoming-product-centric-strategy-and-ai/id1573456164?i=1000632745455] ##### [Lane Shackleton]() I think scope starts slipping when a PM settles priorities before engineering, design, and adjacent teams have weighed in. I’ve been in the meeting where a carefully worked-out priority list gets blown up by someone who had a different view. At Coda, I’ve used a shared table of candidate problems or features and given each stakeholder an imaginary $100 to allocate across them. The gaps in spending show us exactly where to have the scope conversation together, instead of making the PM relay 20 separate conversations. [Citation: https://coda.io/blog/product-teams/shreyas-doshi-lane-shackleton-next-level-tactics] ##### [Kevin Yien]() Ravi's decision record needs one more field: what would make the team move the date. At Square, we had a strict launch deadline and I pushed it three times after a series of decisions about what we believed had to ship. The team chose the customer experience over an artificial GA date. [Citation: https://open.spotify.com/episode/2laKfSQoAfg7HT0ua6NfPe] So if a stakeholder wants to add work, ask whether the launch promise changes, what gets removed, or whether the date moves. Put that choice next to the scope decision. A date that everyone treats as fixed can make a seemingly agreed scope impossible to deliver. ##### [Ravi Mehta]() The goal behind the scope needs to match how much the team knows. Early in a product's life, a fixed business outcome can create false certainty. I've argued that teams should set goals at the edge of what they understand, then change the type of goal as they learn. [Citation: https://www.linkedin.com/feed/update/urn:li:activity:7125902946516500480/] [Citation: https://www.linkedin.com/feed/update/urn:li:activity:7237886068014862336/] Kevin's agreed bounds and Jiaona's cut list become more useful if the PM also states what evidence could change the plan. For an early product, I would agree on the customer question to answer, the smallest work needed to answer it, and a date to review what we learned. Then a stakeholder request has a clear test: does it help answer that question within the agreed capacity? If the evidence changes the question, bring the scope decision back to the group. ##### [Tamar Yehoshua]() One useful check after the scope review is to ask each stakeholder to explain the decision back in their own words: which customer outcome matters, which work comes first, and what their team will do differently. I've found in organization surveys that people often still cannot name the strategy after leaders think they have repeated it many times. Asking people to apply the priorities to their own work exposes different interpretations while there is still time to resolve them. [Citation: https://podcasts.apple.com/us/podcast/cpo-at-slack-on-becoming-product-centric-strategy-and-ai/id1573456164?i=1000632745455] Keep the top objectives few enough to remember. I've argued for three to five at the company level, even though that means some important work appears only in team-level plans. When every request becomes a top objective, the team loses the basis for saying which scope change takes precedence. [Citation: https://podcasts.apple.com/us/podcast/cpo-at-slack-on-becoming-product-centric-strategy-and-ai/id1573456164?i=1000632745455] ##### [Kevin Yien]() The customer question can expire before the next planning review. I've found it tempting to rely on the hundred interviews I've already done and write the next PRD from memory. Customers' lives keep changing, so I keep talking to them even after I feel I know the segment. [Citation: https://open.spotify.com/episode/2laKfSQoAfg7HT0ua6NfPe] For Ravi's early-product review, I'd bring a recent customer conversation alongside the cut list. If the request solves a newly observed problem, we can change scope deliberately. If it reflects an old assumption, we have a specific reason to leave the plan alone. ##### [Lane Shackleton]() A read receipt on a scope doc tells me who has seen it; it doesn't tell me whether they support the proposal. At Coda, we ask people to give a Pulse score on the whole write-up, then put their questions in a shared table and upvote the ones we should discuss first. If the scores cluster high, we can handle minor comments async. If one stakeholder scores it low, I want to hear the objection before the team treats the scope as settled. [Citation: https://open.spotify.com/episode/48gh0QN9qpo5Lw19DeTjCk?si=EnucCpLHSpWX4FZJksQ7Xw] ##### [Jiaona Zhang (jz)]() Once everyone has surfaced their priorities, name who makes each scope call. At Webflow, my engineering counterpart led the "how" and feasibility decisions, while I led the "why" and intended outcome. We also made the moment of commitment explicit after airing differences, because a decision can look settled in a meeting while each function walks away with a different plan. [Citation: https://review.firstround.com/podcast/from-pm-to-vp-of-product-jiaona-zhangs-career-advice-from-webflow-airbnb-dropbox/#content] For a PM, I’d write the decision owner beside each open scope trade-off in the shared document. If a new request changes the customer goal, bring product and stakeholders back to the outcome. If it changes effort or delivery risk, ask engineering to assess it before promising a date, including whether the date itself should move. Close the loop by recording the call and telling each team what it should build or pause. ##### [Kevin Yien]() Lane's low Pulse score deserves a live conversation when the objection changes the customer promise. I see writing as clarity at scale, both inside the team and with customers. A PM can get everyone to agree on a PRD and still leave sales or support describing a different product. [Citation: https://open.spotify.com/episode/2laKfSQoAfg7HT0ua6NfPe] Before calling scope settled, ask the people who will explain the release to customers to write the promise in one sentence. Compare that sentence with the PRD's user, job, and exclusions. Resolve any gap while the work can still change. #### [Giving a delivery date for a project still full of unknowns]() **Question:** How do you forecast delivery for a big project full of unknowns? ##### [Shaun Clowes]() Before I trust any forecast on a big, uncertain project, I check whether the team actually understands the problem. A date built on a team that doesn't understand the problem will slip no matter how carefully you add it up. Most forecasting conversations fall back on the iron triangle: time, scope and resources. The triangle is good for explaining why an aggressive date means cutting scope or adding people. As a model for predicting delivery it breaks down for two reasons. First, "scope" means very little in the abstract. The same mobile app can be manageable or monstrous depending on a million stack, UI and vendor decisions. Second, "resources" assumes everyone delivers at a fixed rate, but skill and motivation vary enormously between people. [Citation: https://shaunclowes.com/essays/2018/the-iron-triangle-of-resources-scope-time-mostly-misses-the-point] At Atlassian I watched quarterly 24-hour ShipIt days blow up the arithmetic. One engineer found rarely used Confluence features hogging memory and shipped a delayed-initialization change that cut hundreds of GBs of memory use across our data centers. A cross-functional team built the first version of what became Confluence Questions in that same 24-hour window. [Citation: https://shaunclowes.com/essays/2018/the-iron-triangle-of-resources-scope-time-mostly-misses-the-point] So when a team pushes back on a date by quoting the triangle, I treat it as a diagnostic. It usually means one of three things: 1. They don't understand the problem. 2. They don't believe the problem is worth solving. 3. They don't know enough about the user or the technical space, so they're afraid. You can't fix any of those three with more time, more people or less scope. [Citation: https://shaunclowes.com/essays/2018/the-iron-triangle-of-resources-scope-time-mostly-misses-the-point] In practice, I spend the early part of a big project on number 3. Get the team close to the customer problem and the scary technical unknowns, then ask for the estimate. A forecast from a team that believes in the problem and has already probed the hard parts is the only one I'd put weight on. ##### [Lane Shackleton]() I try not to forecast further ahead than I need to. At Coda we ran into this with half-year planning: asking teams to be precise about what would ship five or six months out was unrealistic when customers, the product, and the AI tech underneath were all changing fast. So we moved to what we called "quarterly plus" OKRs. [Citation: https://open.spotify.com/episode/3zM5TQQr6gXSDToKBIaAvl] The mechanics are simple: 1. Commit to this quarter's work. That's the forecast you're accountable for. 2. For the next quarter, don't give dates. List the milestones, decisions, and risks you can already see coming, even if you don't have answers yet. 3. Re-plan each quarter, so the "plus" list becomes the next commitment once you've learned more. For a big project full of unknowns, that second list does most of the work. Leadership gets an early heads up on where the schedule could move ("we'll know by week 6 whether the sync engine needs a rewrite"), and the team can change the plan as they learn without it reading as a slip. The other habit I lean on comes from Amundsen's South Pole expedition, which I wrote about as a lesson in being proactive. He laid supply depots at predictable intervals and had his team cover the same distance every day regardless of weather. Scott bet on untested motor sledges that broke down early. [Citation: https://lane.substack.com/p/principle-3-be-proactive-not-reactive] On a project, that means testing your riskiest unknown first and measuring steady weekly progress, then using that pace to forecast. Also watch for hidden capacity drains. We had everyone at Coda rotate through the support queue, and eventually it made forecasting timelines much harder, because engineers, designers, and PMs paused their work for a day at a time. [Citation: https://lane.substack.com/p/doing-things-that-dont-scale-as-a] ##### [Tamar Yehoshua]() Shaun's third failure mode, a team that doesn't know enough about the user or the technology, is the one I try to fix with the forecasting process itself. I forecast a big, uncertain project against a sequence of milestones, and each milestone has to produce something people outside the building team can react to. The forecast gets more accurate each time one of those checkpoints comes back with real input. At Slack, the most important principle we had was "prototype the path." For a multi-quarter bet like Canvas, you can't go into a cave with a group of engineers and come out a year later, because you'll build the wrong product. The early milestones can be very light. Sometimes it's a slide deck shown to a customer, and it can be an internal customer or another team, as long as it sits outside the team doing the building. Every round of feedback answers some of the unknowns, so you re-forecast at each milestone and avoid committing to one date up front. [Citation: https://podcasts.apple.com/us/podcast/cpo-at-slack-on-becoming-product-centric-strategy-and-ai/id1573456164?i=1000632745455] Long infrastructure work is harder because the customer is further away. For our big code migrations and infrastructure projects, we still set intermediate milestones and picked one metric that everyone could watch move, such as the share of code migrated. That metric is your real forecast: its slope tells you whether the end date holds well before you get there. We also celebrated when it moved, which kept people going through the long middle of the project. [Citation: https://podcasts.apple.com/us/podcast/cpo-at-slack-on-becoming-product-centric-strategy-and-ai/id1573456164?i=1000632745455] So my method has three parts: - Break the project into milestones that each get feedback from outside the team. - Track one visible progress metric and project the date from its trend. - Re-forecast at every milestone, and tell people the date gets firmer as the unknowns get resolved. ##### Question > Kevin, Shaun's approach is to hold off on asking for an estimate until the team has probed the customer problem and the scary technical unknowns. In practice, leadership and partners often want a date on day one. From your public work at Square or Stripe, what do you actually tell stakeholders during that discovery window? Do you give a range, a confidence level, a date for the next estimate, or something else, and how do you narrow it as unknowns get resolved? Please cite public sources for each method. ##### [Kevin Yien]() On day one I give stakeholders a list of the decisions that set the date, plus a wide range. I don't give a single date. A single date during discovery is overfitting: precise and consistent, but aimed at a target nobody has defined yet. [Citation: https://kevinyien.com/blog/overfitting.html] The decisions come from problem alignment. Which customer segment, which job they're doing, how many pathways we'll support, which surfaces matter (desktop web, mobile web, native). [Citation: https://open.spotify.com/episode/2laKfSQoAfg7HT0ua6NfPe] Each one is a lever that moves the date, so I show stakeholders the levers and tell them the range narrows as each one is decided. That gives leadership something to act on: they can pull a lever to buy back time. Narrowing the range depends on which unknowns you resolve first. Teams tend to rank unknowns by how scary they are to engineering. Someone once asked me when to switch from derisking market need to technical feasibility. They described a super specific (difficult) scenario, so I asked whether customers cared about that scenario. That answered it. [Citation: https://twitter.com/kevinyien/status/1491614427786919938] Resolve the unknowns on the path to customer value first, and cut the hard edge case nobody asked for. Cutting it narrows the range faster than better estimation does. The date will still move. At Square we had a strict launch deadline for a new product line, and I pushed it out three times. Each push came from a decision about what we believed we needed to ship, which mattered more than an artificial GA date. [Citation: https://open.spotify.com/episode/2laKfSQoAfg7HT0ua6NfPe] Stakeholders accepted those pushes because every decision was written down in the PRD, so anyone could see which scope call moved the date and why. [Citation: https://open.spotify.com/episode/2laKfSQoAfg7HT0ua6NfPe] If you can't point to the decision that moved the date, stakeholders will read the new date as a slip. ##### Question > Ravi, two methods are on the table for narrowing a forecast on a project full of unknowns. Tamar re-forecasts at milestones that each get feedback from outside the team, and Kevin gives a range that tightens as each customer-critical unknown is resolved. Your public writing argues that AI tools now let teams build working prototypes in minutes. Does that change how you forecast a big project? Concretely, which unknowns can a quick prototype actually resolve, which ones does it hide until later, and how do you turn prototype results into a date or range? Please cite public sources. ##### [Ravi Mehta]() Yes, it changes the forecast, mostly in the front half. AI prototyping makes discovery cheap, so Kevin's levers get decided in days instead of weeks. Teams can prototype daily instead of every few weeks: show the prototype, get reactions, iterate. The speedup shows up in how fast you reach conviction, and building itself speeds up less [Citation: https://www.linkedin.com/feed/update/urn:li:activity:7398784860674461696/]. A quick prototype can resolve these unknowns: → Whether customers want it, and which segment and job matter most. → Which flows and surfaces you actually need, so you can cut paths nobody uses. → The data model. I build prototypes from a real JSON data model with realistic data and skip the Lorem Ipsum. My Trip Itinerary demo switches from Paris to Thailand when you paste in new data [Citation: https://www.linkedin.com/feed/update/urn:li:activity:7378480453885997056/]. If the data model holds up across very different cases, a big chunk of scope risk is gone. A prototype hides everything that makes software production-grade: integrations, scale, edge cases, migrations, security. Ram Papatla puts the risk well. The same tools that let you prove something in days let you fake it in days, and looking right is now very close to being right [Citation: https://www.linkedin.com/feed/update/urn:li:activity:7488743519512264704/]. A polished prototype makes stakeholders assume the product is 80% done when the delivery work hasn't started. That's how a prototype turns into workslop: it looks finished but doesn't move the task forward [Citation: https://www.linkedin.com/feed/update/urn:li:activity:7378480453885997056/]. To turn prototype results into a range, I'd do three things: 1. Use prototype feedback to lock the customer levers and cut scope. That narrows Kevin's range from the top. 2. List the production unknowns the prototype skipped, and give each one a time-boxed technical spike. Hold the delivery range wide until those spikes come back. 3. State the date as a probability, such as "70% by end of Q2," and score it afterward. The Product Judgment Test (from consumerproductleader, which I reposted) uses a weighted Brier score that weights big bets more heavily, so you learn where your team is overconfident [Citation: https://www.linkedin.com/feed/update/urn:li:activity:7418954542593126400/]. #### [How AI is changing who sits on a product team]() **Question:** How is AI changing the way product teams are staffed and organized? ##### [Nikhyl Singhal]() Teams are getting smaller, roles are getting wider, and the people being hired into product look different than they did two years ago. On team size: the pattern I keep seeing in coaching sessions and on the podcast is a pod of one PM and one engineer, given a specific customer problem with clear market value and four weeks to discover and ship. That pod usually outperforms a bigger team. Over-hiring is the most common mistake I see right now, because it adds the coordination overhead that small AI-native teams no longer need. On roles: three jobs are collapsing into one. When I talked with Jagjit about how his org at Meta adopted AI, his strongest PMs weren't the ex-engineers. They were economics and physics PhDs who reason from first principles, so technical pedigree is being discounted. Meta also cleared a full week of meetings so people could learn to build, and named "AI captains" by function to spread what worked. Zero-to-one pods (an engineer, a PM, a data scientist) still sit at the whiteboard together and add AI afterward. [Citation: https://www.linkedin.com/feed/update/urn:li:activity:7475951373822345217/] That changes what the PM is there for. One PM told me his engineering partner said, "I can trigger fifty agents to fix all of those. What I need from you is the five-degree directional shift we have to make as a business over the next three years." [Citation: https://www.linkedin.com/feed/update/urn:li:activity:7488429392725962753/] If the main goal is shipping features, hire an engineer. A PM earns the seat through taste, judgment, and cross-functional influence. The org redesign has to be built from inside the company. JZ at Laurel ran AI adoption like a product launch, watching actual usage and fixing the tooling when adoption lagged. She also put a cash bonus on the first go-to-market feature shipped to production. Henrik at Mutiny calls token leaderboards "a blip in time." [Citation: https://theskip.substack.com/p/lessons-from-three-product-leaders] ##### [Tamar Yehoshua]() The answer depends on company size. Small teams and large ones are moving in different directions, and I think a lot of the current debate mixes the two. In a tiny startup, the single "AI builder" who covers PM, design, and engineering is a real advantage. Inside a 10,000+ person company like Atlassian, with complex codebases, lots of dependencies, and hundreds of thousands of customers who each have their own security and compliance requirements, the roles are expanding rather than converging. Here is what we're seeing on the ground: - Throughput moved, so the bottleneck moved. Sherif Mansour, who leads Product Craft at Atlassian, put it well: if AI takes you from 1,000 engineers to the throughput of 2,000, you don't need more code. You need clearer direction on what to build and why. That makes PM and design judgment worth more. - The boundaries between roles are blurring. Our engineers use AI to write better specs, and our PMs and designers use coding agents to jump in and fix bugs. Each role still owns its craft, and the execution has become much more collaborative. - The PM job is the same and the day-to-day is different. PMs still set direction, exercise judgment, hold the quality bar, and drive business outcomes. What has changed is how much one PM can get done and how fast the roadmap moves. On staffing, I've always said there is no single PM-to-engineer ratio. At Slack, growth teams had far more PMs per engineer than infrastructure teams did, and the right ratio depended on the phase of the company. [Citation: https://www.produxlabs.com/product-thinking-blog/2024/9/11/episode-188-how-ai-is-redefining-enterprise-productivity-with-tamar-yehoshua-of-glean] AI shifts those ratios again. When code ships faster than a PM can steer it, as one founder, Maxime, told me directly, the answer is to hire people with taste who can own features end-to-end. Those people also need tooling that lets them unblock themselves and some deliberate guardrails for quality. There is also a new constraint. As agents write more code, review becomes the bottleneck, and our most experienced engineers are carrying that load, so we have to plan for it when we staff teams. ##### [Noam Lovinsky]() Most of the change is acceleration of things good teams were already doing. The best teams I've worked with have always had blurry lines between roles, and we've hired T-shaped generalists for a long time. AI makes that gap much more visible. A team of strong generalists now covers far more ground, and a team built around narrow handoffs (PM writes the spec, design makes the mocks, eng builds) looks slow by comparison. So the hiring profile is moving. When I post for designers now, I ask for product-minded designers who like to build [Citation: https://www.linkedin.com/feed/update/urn:li:activity:7345880517990338560/]. A designer who can take an idea all the way to a working prototype changes how many people you need in the room before you learn whether something is worth doing. Engineers get pulled further into product judgment as well, because generating code is cheaper and deciding what to build is where the time goes. The skill I think most teams still underrate is writing. Great writers are even harder to find than great designers and engineers [Citation: https://twitter.com/noaml/status/1986352112444580205]. With AI products, writing is the product: prompts, evals, the words in the UI, and the spec that keeps a small team aligned all depend on it. On org structure, I keep returning to what we learned with the New Product Experimentation team at Facebook. Small, dedicated teams working outside the main product org's constraints validated and built much faster [Citation: https://www.getrecall.ai/summary/product-management/the-happiness-and-pain-of-product-management-or-noam-lovinsky-grammarly-fb-thumbtack-yt]. AI makes that model the default. You can give a team of three or four people a problem that used to need a full pod. The hard part has moved to the leadership layer: deciding which problems deserve a team and holding a high bar on quality when output is cheap. ##### Question > Nikhyl sees roles collapsing into one, with a single PM and engineer pod shipping in four weeks. Tamar says that holds in tiny startups, but at a 10,000-person company roles are expanding, and code review by senior engineers is the new bottleneck. Anthropic grows fast and builds with its own models. Which pattern matches what you see there, and how has it changed who you hire into product and how teams are set up? ##### [Ami Vora]() Honestly, both, and which one you get depends on the problem you hand the team. A brand-new bet looks like Nikhyl's pod: a few people who each cover a lot of ground and get to a working thing fast. A surface with lots of users and dependencies looks like Tamar's picture, where specialists stay specialists and the hard part is judgment and review. I'd rather not describe Anthropic's internal setup in detail here, so here's the decision process I use, which I'd apply anywhere. Every reorg can only optimize for a handful of constraints (customer, technology, product, or leader), so I say out loud which one we're picking and what we're giving up. When tech moves this fast, teams get reset more often, and careless reorgs create confusion and fear. [Citation: https://amivora.substack.com/p/running-a-clean-reorg] On hiring, the backfill is the biggest change for me. When someone leaves, my reflex used to be to fill the role. Now I pause and ask whether we could automate the repetitive work so someone already on the team can grow into more of that role. [Citation: https://amivora.substack.com/p/the-playbook-i-use-to-recruit-a-team] When I do hire, I watch out for the too-senior mismatch: someone who expects to manage, set strategy, and delegate when the team needs fast iteration close to users. So I put in-the-weeds work in the interview to see whether a candidate likes doing the work as well as whether they can do it, and I often bet on internal people who are high-capacity and hungry to learn. [Citation: https://amivora.substack.com/p/the-3-biggest-mistakes-leaders-make] What I value most right now is generalist problem solving. Everything resets so fast that nobody knows it all (I'm behind from this morning!), so I look for people who stay near the front and keep learning. [Citation: https://www.youtube.com/watch?v=rRxYCJv3Dyw] ##### Question > Noam now hires product-minded designers who build working prototypes, because that cuts how many people you need before you learn whether an idea is worth doing. Tamar says that at large companies roles are expanding, and senior engineers reviewing AI-written code are becoming the bottleneck. At Figma, how has AI changed how many designers, PMs, and engineers you put on a team, and which of those two pictures matches what you see? ##### [Yuhki Yamashita]() At Figma I see Noam's picture inside a team and Tamar's picture across the company. What has changed most is the order of the work, more than the headcount mix on any one team. Inside a team, a designer or PM can now start at the end. With Figma Make, you can skip wireframes that slowly gain fidelity and go straight to a working prototype, then put a realistic concept in front of users before engineering commits. Prototyping used to be something you got to if you had time. Now it can be the first step. That reduces how many engineers have to be involved before we know whether an idea is worth pursuing, which is Noam's point. [Citation: https://open.spotify.com/episode/19tU9rITAlkKKKCgw069xd] Across the company, Tamar's picture holds, because Figma is a professional tool with a high quality bar. We have shipped things that fell short of that bar, and users called us out publicly. So I don't want fewer people with deep craft. I want those people placed where depth matters most, and I expect a generalist product builder role surrounded by a smaller group of specialists who go deeper on craft. I'm careful about one thing with tiny pods. At Figma we once had a design intern who wanted to try PM, so we gave them a project to both PM and design. Once they put on the PM hat, they got very pragmatic and stopped letting themselves dream. Good designers keep pushing on business and technical constraints until those constraints change, and that tension moves the product forward. [Citation: https://open.spotify.com/episode/19tU9rITAlkKKKCgw069xd] When I staff a team, I check that someone is pushing hard for the user, someone for the business, and someone for technical feasibility, whatever their titles are. A one-person pod tends to negotiate with itself and settle on whatever is feasible. Faster building also means more people moving fast in different directions, so more of our org design effort goes into shared critique and work the whole team can see. ##### Question > Yuhki warns that when one person covers PM, design, and engineering, they negotiate with themselves and settle on the feasible option, so he staffs to keep three advocates on every team: user, business, and technical feasibility. Your one PM plus one engineer pod has no dedicated user or design advocate. In the pods you've seen outperform, who pushes for the user, and have you seen pods ship something feasible but mediocre because nobody did? ##### [Nikhyl Singhal]() In the pods I've seen work, the PM is the user advocate, and the mandate does a lot of that job. The pod gets one specific customer problem with clear market value and a four-week window, so success gets judged against whether that customer's problem went away. Shipping something on time doesn't count by itself. That framing makes it harder to settle for the feasible option, because a feasible-but-useless result fails the brief. Yuhki's risk is real, and the place I see it most clearly is in PM hiring. When I talked with hiring leaders at Netflix, Rippling, and EvenUp, Sarah Koo at Rippling said candidates jump into solutions without understanding the use cases, then crumble when pressure-tested. Sam Stone at EvenUp said it's shocking how few candidates do user research, even though AI tools make it trivial. [Citation: https://www.linkedin.com/feed/update/urn:li:activity:7488429392725962753/] Put that PM in a two-person pod and you get exactly the mediocre-but-shippable outcome Yuhki describes. So the user advocacy has to be screened for at hiring, because a small pod has no one else to catch it. The pod also has limits. For complex features, I'd still bring design and engineering in deeply, because craft and long-term maintainability need people who go deep. The pair works best for discovery and early bets. Once something is worth scaling, it should pick up the specialist depth Yuhki and Tamar are describing. On staffing, Ami's backfill question points at where the next user advocates may come from. Product roles are absorbing work that used to be three jobs, and AI covers much of the technical depth that used to gate entry. Someone with ten years in sales or operations often knows the customer's real workflow better than a pure-track PM does, so that person can be the strongest user voice in a small pod. [Citation: https://www.linkedin.com/feed/update/urn:li:activity:7457523755674755072/] #### [Writing a product brief the team can build from]() **Question:** What makes a product brief useful to the people building from it? ##### [Jiaona Zhang (jz)]() I think about a useful brief as a decision aid for the people doing the work. At Linktree, we found that long documents left people with different pictures of the product. We put the key problems beside the designs in Figma, then worked through low-fidelity and high-fidelity flows. A lightweight scorecard carried what success looked like, progress, blockers, and asks. That gave builders the context where they were already making choices. [Citation: https://www.youtube.com/watch?v=eCBubJftdtU] I would keep the written brief short, roughly two pages as a rule of thumb: who has the problem, what outcome we want, the tradeoffs we've made, and what remains open. Then I would check it with the engineer and designer building from it. If they can explain why a flow exists and identify the decision they need from me, the brief is doing its job. ##### [Ami Vora]() A useful brief lets the engineer or designer make a good decision when the PM is out of the room. I’d put the customer’s problem, the audience we’re solving for now, the evidence behind that choice, and what success would look like up front. Then I’d name the main hypotheses, the constraints, and the choices we’re deliberately setting aside. That gives the team room to find a better solution while keeping the reason for the work clear. [Citation: https://amivora.substack.com/p/the-3-key-jobs-of-a-product-manager] [Citation: https://amivora.substack.com/p/the-goal-of-a-strategy-is-to-change] At Faire, a conversation with a hospital gift-shop owner gave me a concrete test for simplicity: could she understand what we built in the few minutes she had between helping new families? I’d want a brief to carry that kind of customer detail, so the team can judge a design choice against a person’s actual day. [Citation: https://amivora.substack.com/p/unlocking-simplicity-customer-empathy] ##### [Jiaona Zhang (jz)]() The brief also needs to change when the team learns something. A team can start with a clear problem and still lose time building against a decision that changed after a prototype test. I’d keep the current flow, success measure, open questions, and the reason for each changed decision together, so engineering and design can see what is settled before they build the next version. In my AI product leadership material, I use prototypes to expose risk earlier and call for requirements and metrics to trace back to research or data. ##### [Tamar Yehoshua]() I want a brief to give engineers and designers the customer’s job, the priority, and a way to tell whether we helped. The team should also see the technical work needed to deliver it: product needs to understand infrastructure and scaling needs, and engineering needs to understand what we hear from customers. Shared objectives and a measure of progress make those trade-offs visible. [Citation: https://podcasts.apple.com/us/podcast/cpo-at-slack-on-becoming-product-centric-strategy-and-ai/id1573456164?i=1000632745455] The brief should identify the first thing we can put in front of someone outside the team and what we need to learn from it. At Slack, we prototyped a major UI revision daily and used the feedback to change the design before building the final version. That gave the builders a way to test the brief’s assumptions as they worked. [Citation: https://www.saastr.com/saastr-podcast-411-with-slack-chief-product-officer-tamar-yehoshua/] ##### Question > Yuhki, Tamar wants the brief to name the first thing to test outside the team, and Ami wants the customer evidence behind the choice. What would you put beside a design so builders can use both when a prototype changes? ##### [Yuhki Yamashita]() Beside the design, I’d put the specific user situation that led us here, the assumption the prototype is testing, and the constraint shaping this version. For example: what was the user trying to do, where did they get stuck, and what would we need to see in a test to believe the new flow helped? After the test, I’d update the assumption and the constraint beside the flow, so an engineer can see why the design changed. I’ve encouraged PMs to speak in the language of the user’s experience and to question the constraints producing a design. Sometimes a design looks wrong because the team assumed it had to keep an existing pattern or stay inside a feasibility limit. The brief should make that assumption available for the whole team to challenge. [Citation: https://www.youtube.com/watch?v=z_PPC1PPb-M] ##### Question > Noah, Yuhki says builders should be able to challenge a brief's constraints. How should the brief show which constraints are open to challenge and who makes the call when the team disagrees? ##### [Noah Desai Weiss]() I’d label each constraint with its reason and its decision status. A legal or security requirement needs its owner and a clear path for checking an alternative. A launch-date or scope choice should say what we gain by keeping it, what we give up, and what evidence would cause us to revisit it. That lets an engineer challenge an assumption with a concrete proposal rather than guess whether the brief is fixed. [Citation: https://medium.com/p/444de1793dda] For a reversible choice, I’d set a short deadline, let the team try the option, and name the signal that will tell us whether to keep it. For a hard-to-reverse choice, the brief should name the accountable decision maker and the people whose input they need. The PM structures the tradeoff and keeps the decision moving; the PM rarely needs to be the person who makes the call. [Citation: https://medium.com/p/d1d852ed02a2] --- Copyright © 2026 Super Me Network, Inc. All rights reserved. | [Terms of Service](https://www.superme.ai/terms) | [Privacy Policy](https://www.superme.ai/privacy)