Customer interviews that lead to a different build

The Product Leaders work group on who to interview, what to show them and who carries the findings into the build.

Updated October 13, 2026

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.

Group chat with Tamar, Yuhki, Jiaona, Shaun, Ravi — the Product Leaders work group

Question:

How do you run customer interviews that change what you build?

Shaun ClowesGeneral Manager, Confluent and Data at IBM. Former CPO of MuleSoft and Head of Growth at Atlassian

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.

shaunclowes

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.

shaunclowes

Yuhki YamashitaChief Product Officer at Figma. Former Head of Design for New Mobility at Uber

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.

Spotify

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.

Spotify+1

Jiaona Zhang (jz)Chief Product Officer at Laurel. Former SVP of Product at Webflow and CPO at Linktree

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.

review.firstround

Tamar YehoshuaChief Product and AI Officer at Atlassian. Former CPO of Slack and President of Product and Technology at Glean

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.

saastr

Shaun ClowesGeneral Manager, Confluent and Data at IBM. Former CPO of MuleSoft and Head of Growth at Atlassian

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.

shaunclowes

Yuhki YamashitaChief Product Officer at Figma. Former Head of Design for New Mobility at Uber

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.

Spotify

Tamar YehoshuaChief Product and AI Officer at Atlassian. Former CPO of Slack and President of Product and Technology at Glean

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.

saastr

Ravi MehtaProduct advisor. Former Chief Product Officer at Tinder and VP Consumer Product at TripAdvisor

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.

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)Chief Product Officer at Laurel. Former SVP of Product at Webflow and CPO at Linktree

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.

Apple Podcasts

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 YamashitaChief Product Officer at Figma. Former Head of Design for New Mobility at Uber

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.

Spotify

Shaun ClowesGeneral Manager, Confluent and Data at IBM. Former CPO of MuleSoft and Head of Growth at Atlassian

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.

YouTube

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 YehoshuaChief Product and AI Officer at Atlassian. Former CPO of Slack and President of Product and Technology at Glean

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.

saastr

Ravi MehtaProduct advisor. Former Chief Product Officer at Tinder and VP Consumer Product at TripAdvisor

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.

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 ClowesGeneral Manager, Confluent and Data at IBM. Former CPO of MuleSoft and Head of Growth at Atlassian

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.

YouTube

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 YamashitaChief Product Officer at Figma. Former Head of Design for New Mobility at Uber

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.

Spotify

Jiaona Zhang (jz)Chief Product Officer at Laurel. Former SVP of Product at Webflow and CPO at Linktree

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.

review.firstround

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 YehoshuaChief Product and AI Officer at Atlassian. Former CPO of Slack and President of Product and Technology at Glean

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.

saastr

Ask a follow-up

Product Leaders

220

Product Leaders

3M+ insights

Product leaders from Google, Airbnb, Stripe & 7 more

by Lenny Rachitsky

Frequently Asked Questions

What goes into a good product strategy?
A customer problem the team can describe, one clear choice about the value to deliver first, the work set aside, and the evidence that would show the bet is working. It should let the team explain a specific 'no' to an important customer.
How do you tell a product strategy from a roadmap?
A strategy changes decisions: who the team builds for, where people are staffed and which requests get declined. Noam Lovinsky's test is which staffed project the team would stop to make room for its top bet.
How do you scope an MVP?
Set the bar for viable, then cut breadth to one segment, one job and one surface. Keep the core interaction at full quality, leave operations rough, and write down the result that would make you stop before launch.
How should a product team handle feature requests?
Route them by source, write down the problem behind each one, rank only near-term work, and protect capacity for bigger bets and reliability so the request queue can't fill the whole roadmap.
How do you tell whether a new feature worked?
Write down what a win looks like and when you'll read the metric before launch. Read adoption, then sentiment, then behavior change, and check that the whole product gained rather than usage moving from one feature to another.
How do product managers keep stakeholders aligned on scope?
Put the scope decisions and the cut list in one shared record, ask what moves whenever someone adds work, name who owns each call, and check that agreement is real, for example by asking stakeholders to explain the decision back.
How do you forecast delivery for a project full of unknowns?
Give a range and the decisions that set it rather than one date, resolve the unknowns on the path to customer value first, and re-forecast at milestones that get feedback from outside the team.
How is AI changing the way product teams are organized?
New bets increasingly go to small pods with wide roles, while large companies keep specialists and find code review and judgment becoming the bottleneck. Either way, someone on the team still has to push for the user.
What makes a product brief useful?
It lets the people building decide well without the PM in the room: the customer problem and evidence, the outcome, the trade-offs made, what is still open, and which constraints the team can challenge.

All product management questions →

Frequently Asked Questions

Customer interviews that lead to a different build

Product Leaders

Frequently Asked Questions

What goes into a good product strategy?

How do you tell a product strategy from a roadmap?

How do you scope an MVP?

How should a product team handle feature requests?

How do you tell whether a new feature worked?

How do product managers keep stakeholders aligned on scope?

How do you forecast delivery for a project full of unknowns?

How is AI changing the way product teams are organized?

What makes a product brief useful?

Your ideas, super powered.

Customer interviews that lead to a different build

Product Leaders

Frequently Asked Questions

What goes into a good product strategy?

How do you tell a product strategy from a roadmap?

How do you scope an MVP?

How should a product team handle feature requests?

How do you tell whether a new feature worked?

How do product managers keep stakeholders aligned on scope?

How do you forecast delivery for a project full of unknowns?

How is AI changing the way product teams are organized?

What makes a product brief useful?

Your ideas, super powered.