# Product management, from strategy to launch — Summary 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]() Transcript: [Full Chat Transcript]() Work group: [Product Leaders]() ## Questions ### [The choices a good product strategy has to make]() A good strategy names a customer problem, makes one clear choice about the value to deliver first and says what the team will set aside, clearly enough that teams can use it in daily decisions. - **Start from a customer problem.** Shaun Clowes's test is whether the team can explain who has the problem, why it matters now, how the market is changing and why the company's strengths give it a credible way to win. Tamar Yehoshua starts with which problem the team is solving, why it can solve it well and how it will know the customer is better off. - **Choose what comes first, and what waits.** Ami Vora would make one clear choice about the value to deliver first. At WhatsApp, calls and messages had to go through, for free, every time, before more features. Jiaona Zhang writes down the choices set aside: at Linktree, a strategy FAQ said which creator groups to focus on and how much attention mobile apps, mobile web and desktop would get. - **A strategy should explain a 'no'.** Shaun says a strategy earns its keep when it lets the team explain a specific 'no' to an important customer and keep their trust. Tamar would reopen a 'no' when customer conversations and observed use show the job is widespread and a prototype shows the core product can stay simple. - **Name the buyer and the shared costs.** Jiaona would make the buyer and the budget explicit before committing to a roadmap. At Webflow, the team chose a professional tool over a small-business site builder. For a multi-product strategy, Yuhki Yamashita would say which experiences should feel connected and fund the shared work alongside each new product. Figma's FigJam decision exposed the cost of building each product in isolation. - **Check that the org funds it.** Jiaona checks whether teams and goals reflect the chosen areas; if the org keeps funding work outside them, the strategy is not yet an operating decision. Shaun adds that the growth model has to support the value choice: at Atlassian, a human-help prompt late in the trial lifted purchases by double-digit percentages, and the team still chose to keep improving self-service. Ami would keep customer time on the calendar after the strategy is set, so the team can revise its assumptions. ### [Telling a real product strategy from a dressed-up roadmap]() A strategy shows up as decisions about who the team builds for, which requests it declines and where people are staffed, made before the results are certain. - **Look for choices that rule work out.** Jiaona Zhang looks for decisions that change what the team builds, who it builds for and where people go. Webflow chose professionals replacing developer work on marketing sites over small businesses, which gave the team a reason to pass on work aimed at the first group. - **Check that headcount carries the choice.** Jiaona expects a priority area to have a team staffed to go deep, with fewer people on work being maintained. Tamar Yehoshua notes that a stated choice alone can't show this. She would look at which problems earned a staffed team and which requests were declined or delayed before the roadmap was final. - **Name the behavior the plan should change.** Noah Desai Weiss would ask what customer behavior the plan expects to change, why this approach should change it and how the team will learn whether it was right. At Slack, after hundreds of small onboarding experiments while growth had plateaued, the team rebuilt the whole first-day experience. - **Ask what the team would stop.** Noam Lovinsky would ask which staffed project the team would stop to make room for the bet it says matters most. At YouTube he argued that roughly 50 engineers on the rebuild he led would do more for the business elsewhere, and leadership wound the project down. - **A strategy changes the customer conversation.** At Figma, the goal of helping the whole product team work around design gave Yuhki Yamashita a reason to invest in collaboration while customers asked for individual features and offline use. When a customer brought ten requests, he would set them beside the other work under consideration and ask which mattered more. ### [Customer interviews that lead to a different build]() Interviews change the build when they feed a decision someone owns, test a working prototype with realistic data, and are read against the segment and the job each customer came from. - **Start from the decision and its owner.** Shaun Clowes would name the product decision the interviews could change, then put the accounts beside usage data and market context. After splitting a design problem among teams before anyone owned discovery, he named cross-team discovery owners. Jiaona Zhang would have that owner challenge the problem definition first: at Dropbox, Project Harmony framed collaboration too narrowly. - **Ask why twice.** Yuhki Yamashita asks why a customer needs a feature, then why that problem exists, which can reveal a bigger opportunity. At Figma he would also ask customers whether their request mattered more than work already planned. Sometimes they chose the planned work. - **Show a working prototype with realistic data.** Tamar Yehoshua would watch customers use a working prototype and note where they pause; Slack's UI revision ran on disposable prototypes turned around daily. Ravi Mehta starts with a data model and realistic test data, so customers judge the experience against their own task and not the placeholder layout. - **Check the segment before the roadmap.** Ravi would put each account next to its segment and job. If a problem recurs among target customers, he would revisit the investment. If it comes mainly from customers you chose not to serve first, he would record the evidence and keep the current priority. Tamar would ask whether the fix belongs in the core product, an enterprise requirement or an integration. - **Interview the people who dropped off.** Shaun would recruit people who abandoned setup and watch them try the first task. At Atlassian, a two-screen Confluence setup that suggested spaces drove a double-digit increase in people succeeding and purchasing, and interviews with people who got through setup would have missed the people it helped. ### [What to cut from an MVP, and the one part to build well]() Decide how high the bar for viable is, cut breadth until one segment does one job on one surface, and build the moment the test depends on well enough that the result means something. - **Market maturity sets the bar.** Kevin Yien says an MVP in a new market only has to show the problem exists, while a crowded category needs much more, unless you come at it from the side. He writes down the simplifying assumptions that let the team ignore everything else. Ravi Mehta would also enter a crowded consumer category from the side, raising the bar on one dimension, as Swipe Night did at Tinder. - **Don't serve burnt pizza.** Jiaona Zhang cuts to one or two features and builds them well enough for the test to mean something. She would leave operations, scale and what users take for granted rough, and never the core interaction. Dropbox's presence-only Project Harmony tested a weaker idea than real-time co-editing. - **Cut breadth before quality.** Kevin writes four constraints into the PRD before design starts: one named segment, usually one pathway to the job, one surface and a short list of principles. If a date forces cuts, he would cut segments and surfaces first and the quality of the tested path last. - **Write the thesis, then test the extremes.** Lane Shackleton's team at Coda spent about a month on a core thesis doc before most customer research, then put it in front of users as paper prototypes. At YouTube, a tiny skip button in one arm and a giant one in the other gave directional data within weeks. - **Write the stop result before launch.** Nikhyl Singhal would name the five to ten users, the one assumption and the result that would make you stop, written as behaviors, such as six of ten coming back on their own by week three. A second line asks whether the bet can get big enough to matter. Ravi would judge a crowded-category wedge by whether people return when the incumbent is one tap away. ### [Handling feature requests without letting them write the roadmap]() Give every request a home, rank only the near-term work, and judge each ask by the problem behind it and the segment it comes from rather than by how often it is repeated. - **Route requests by source.** At Slack, Tamar Yehoshua ran separate channels for support escalations, enterprise gaps from the field and the community. A sales ops owner attached pipeline to each enterprise gap for a quarterly review with product leads. Yuhki Yamashita adds that each source is biased: support tickets lean dissatisfied, and Twitter is a vocal minority. - **Keep the problem, drop the proposed fix.** Kevin Yien warns that teams overfit. In his hypothetical, a team ships 11 custom fields for customers worth 40% of revenue, and those customers churn anyway. He would write down the problem behind each request, weight it by segment and ICP fit instead of volume, and, when a dozen requests are variations on "let me add a field", probably build one flexible primitive in place of a dozen point features. Tamar's Huddles at Slack came from the problem under customers' requests for video. - **Rank only what is close.** At Foursquare, Noah Desai Weiss's team sorted requests into \#now (2 to 4 weeks), \#next (1 to 3 months) and \#later, which needed no careful ranking. He would set a portfolio split up front so incremental requests can't crowd out bigger bets, and Tamar would protect capacity for reliability too. - **Make stakeholder priorities visible.** Lane Shackleton runs major stakeholders through a $100 voting exercise, which leaves a record of each person's early stance. Kevin would require each row to state the problem, the segment and ICP fit, links to raw evidence, a count of distinct customers, and whether it is a segment-wide capability or a per-customer customization. - **Treat an accepted request as a hypothesis.** Noah would ship the smallest version that tests it and decide quickly when a choice is easy to reverse. At Slack, pillars reviewed their own smaller features so exec reviews could spend their time on one-way doors and the overall portfolio. ### [Judging a new feature against the bar set before launch]() Decide what a win looks like before the feature ships, read the result against that bar on a date set in advance, and check that the product as a whole gained. - **Write the bar down before launch.** Yuhki Yamashita asks teams to write the headline they want to claim, then grade themselves against it with a letter and an explanation. Jiaona Zhang writes success as a branch on a KPI tree, from business outputs down to the product metrics a team can move. Nikhyl Singhal would add concrete examples of a win and a loss, and a date when the metric gets read. - **Read the results in layers.** Jiaona reads adoption first, then sentiment, then behavior change such as churn, retention or activation. Output metrics come back last, so she counts early reactions to an alpha as data too. - **Pair a self-grade with harder checks.** Ravi Mehta says a self-graded headline misleads when the team grading it needs the feature to have worked. He would add retention on the feature and a written link from the metric to the strategy. Where a clean A/B test is possible, he says the test decides. - **Accept a miss only with a diagnosis.** Yuhki accepts a missed metric when the team names a specific cause and a fix, and rejects it when the team finds a different number that went up. Figma kept the original bar for branching and merging, whose slow start came from performance, an unfamiliar workflow and gaps found in customer rollouts. Nikhyl looks at users who finished setup: if even they drop off, more time won't help. - **Check that the whole product gained.** On a crowded surface like Facebook Feed, Nikhyl would use a holdout, since a new unit can pull usage from its neighbors. Without one, Jiaona watches the top of the KPI tree, such as subscriptions, churn or whether sales can sell it. Kevin Yien watched payment volume per merchant at Square for Restaurants, and for the Stripe Dashboard he borrows a Stripe practice of counting merchant 'bad days', such as a late payout. ### [Getting stakeholders to agree on scope, and keeping it agreed]() Write the scope decisions where everyone can see them, make every addition a choice with a cost, and check that agreement is real before the team treats scope as settled. - **Put a draft in front of people.** Kevin Yien suggests a PRD that sets the bounds: the user and their job, the surfaces to support and a real trade-off. He would run a 20-minute silent read where stakeholders comment on the draft, then record the decisions in the PRD. - **Make the cut list visible.** Ravi Mehta would write down non-goals beside the chosen work and keep committed work and deferred requests in one decision record. At Linktree, Jiaona Zhang asked teams to plan against a fixed staffing limit and list what they couldn't do, and she would question a tiny cut list. - **Give every addition a cost.** When someone proposes an addition, Ravi would ask which agreed item moves or whether the outcome has changed. Kevin adds one more question: does the date move? He pushed a strict Square launch date three times after decisions about what had to ship. - **Draw out disagreement before scope is settled.** Lane Shackleton has given stakeholders an imaginary $100 to spread across candidate problems, and at Coda asks for a Pulse score on the write-up. He wants to hear a low scorer's objection before scope counts as settled. Tamar Yehoshua suggests asking each stakeholder to explain the decision back in their own words. - **Name who makes each call.** At Webflow, Jiaona's engineering counterpart led the 'how' and she led the 'why'. She suggests writing the decision owner beside each open trade-off. Before calling scope settled, Kevin would ask the people who explain the release to customers to write its promise in one sentence and compare it with the PRD. ### [Giving a delivery date for a project still full of unknowns]() Give a range and the decisions that move it, resolve the unknowns on the path to customer value first, and re-forecast as each milestone comes back with real input. - **Check that the team understands the problem.** Shaun Clowes treats pushback on a date that quotes the time, scope and resources triangle as a diagnostic. Usually the team doesn't understand the problem, doesn't believe it's worth solving, or is afraid of what it doesn't know. He spends the early part of a big project getting the team close to the customer and the hard technical parts, then asks for the estimate. - **Start with a range and the levers that move it.** On day one Kevin Yien gives stakeholders a wide range and the decisions that set the date: segment, job, pathways and surfaces. The range narrows as each is decided. He would resolve the unknowns on the path to customer value first and cut the hard edge case nobody asked for. - **Re-forecast at each milestone.** Tamar Yehoshua forecasts against milestones that each produce something people outside the team can react to. For long infrastructure work at Slack, the team tracked one metric, such as the share of code migrated, and read the end date from its slope. - **Commit to this quarter only.** At Coda, Lane Shackleton moved to 'quarterly plus' OKRs: commit to this quarter's work, list the milestones, decisions and risks already visible for the next one without dates, and re-plan each quarter. He also warns about hidden drains on capacity, such as a support rotation. - **Prototypes narrow only part of the range.** Ravi Mehta says AI prototypes settle customer questions in days but hide integrations, scale, edge cases, migrations and security. He would give each of those a time-boxed spike, keep the range wide until the spikes come back, and state the date as a probability to score afterward. ### [How AI is changing who sits on a product team]() It depends on the company and the stage of the bet. Small pods with wide roles suit new bets, while large products keep their specialists and run into new limits on judgment and code review. - **Small pods for new bets.** Nikhyl Singhal has seen a pod of one PM and one engineer, given a specific customer problem and four weeks, usually outperform bigger teams, and calls over-hiring the most common mistake right now. Noam Lovinsky says AI lets a team of three or four take on a problem that used to need a full pod. - **Large companies look different.** Tamar Yehoshua says small and large companies are moving in different directions. Ami Vora says a surface with many users and dependencies keeps its specialists, and the hard part is judgment and review. As agents write more code, Tamar's most experienced engineers carry the review load, and she plans for that when staffing teams. - **Hiring profiles are shifting.** Noam asks for product-minded designers who like to build, and calls writing the most underrated skill. Before a backfill, Ami Vora now asks whether automating repetitive work would let someone on the team grow into the role. Nikhyl points to people with years in sales or operations as strong user voices in a small pod. - **Keep someone pushing for the user.** Yuhki Yamashita warns that a one-person pod tends to negotiate with itself and settle on whatever is feasible. He checks that someone on each team pushes for the user, the business and feasibility. Nikhyl would screen PMs for user advocacy at hiring and judge a pod on whether the customer's problem went away. - **Prototypes come first, and reorgs name their trade-offs.** At Figma, a designer or PM can go straight to a working prototype with Figma Make before engineering commits. Yuhki expects a generalist product builder role surrounded by a smaller group of specialists. For any reorg, Ami says out loud which constraint it optimizes for and what it gives up. ### [Writing a product brief the team can build from]() A useful brief lets engineers and designers make good decisions without the PM in the room. It says who has the problem, the outcome wanted, the trade-offs already made and what is still open. - **Write it for decisions made without you.** Ami Vora would put the customer's problem, the audience, the evidence behind that choice and what success looks like up front, then the hypotheses, constraints and choices set aside. She wants customer detail concrete enough to judge a design against a real person's day. - **Keep it short and near the design.** Jiaona Zhang suggests roughly two pages: who has the problem, the outcome, the trade-offs and what remains open. At Linktree, the team put the key problems beside the designs in Figma. Her test is whether the engineer and designer can explain why a flow exists. - **Name the first test.** Tamar Yehoshua wants the brief to name the first thing the team can show someone outside it and what it needs to learn. At Slack, the team prototyped a major UI revision daily. She also wants the technical work visible, so product sees infrastructure needs and engineering hears what customers say. - **Show why a design changed.** Beside the design, Yuhki Yamashita would put the user situation behind it, the assumption the prototype tests and the constraint shaping this version. After each test he would update them, so an engineer can see why the flow changed. - **Label each constraint and who decides.** Noah Desai Weiss would label each constraint with its reason and status. A legal or security requirement names its owner; a date or scope choice says what keeping it gains and what evidence would reopen it. For a hard-to-reverse call, the brief names the decision maker, and the PM structures the trade-off. ## 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 --- Copyright © 2026 Super Me Network, Inc. All rights reserved. | [Terms of Service](https://www.superme.ai/terms) | [Privacy Policy](https://www.superme.ai/privacy)