How to interview customers who chose another product

A lost-deal interview should explain a buying decision, including the alternatives the buyer considered and the constraints they faced. It should not become an attempt to prove that your product was better. Start by reconstructing the sequence, then examine which events changed the decision.

“Too expensive” or “missing a feature” may be a useful opening answer. Neither tells you enough by itself to choose a roadmap change. You still need to understand what the buyer was trying to accomplish, what they compared, who participated, and what happened after the choice.

This guide offers a decision-timeline worksheet. The worked example concerns a fictional training software purchase and is illustrative, not a reported customer story.

Define which decision you are investigating

Separate prospects who selected a competitor from prospects who renewed an existing contract, postponed the project, or abandoned the purchase. Each is an alternative, but they are not the same outcome.

Write the question you want the research to answer. For example: “Does our implementation process prevent teams with a fixed training deadline from adopting?” That is more actionable than “Why do we lose?”

The SBA’s market research guidance includes direct research and the alternatives competing for customers. Use that broader view so a no-purchase outcome remains visible. Read the market research guidance.

Do not mix learning with a surprise win-back pitch. Explain the purpose in the invitation, and let the participant decline. If you also want to discuss a new offer, make that a separate, explicit request.

Recruit people who participated in the decision

An enthusiastic product evaluator may know the demonstrations but not the final approval discussion. A purchasing contact may know contract terms but not why users preferred one workflow.

Ask what part the person handled. Record whether they evaluated options, recommended a choice, approved spending, managed implementation, or heard about the decision afterward. When a key step is outside their knowledge, identify the missing perspective instead of asking them to infer it.

Keep the buying period and product version in your notes. Feedback about an earlier offering can still be useful, but it should not silently describe the current one.

Reconstruct the decision before asking for reasons

Begin with the event that started the search: “What was happening when the team first decided to look for a different approach?” Then follow the purchase through time.

GOV.UK’s interview guidance supports using a prepared discussion guide while exploring relevant experience. The timeline below is an original application to a buying decision. Read the in-depth interview guidance.

Stage	What to capture	Neutral prompt
Trigger	Event that made action necessary	“What changed?”
Starting approach	Existing tool, process, or workaround	“How were you handling it before?”
Search	Options that entered consideration	“How did each option come up?”
Evaluation	Activities and people involved	“What did the team actually compare?”
Turning point	Event that changed the preferred option	“When did the choice become clearer?”
Approval	Conditions required to proceed	“What still had to happen before a commitment?”
Afterward	Implementation and present use	“What happened once the decision was made?”

Allow the participant to correct the order. Real decisions may loop back, add an approver, or pause. The worksheet should preserve that complexity without becoming a transcript of every meeting.

Separate requirements from retrospective explanations

When someone names a missing feature, ask when it became important and what task required it. Was it an initial requirement, a concern raised during evaluation, or an explanation offered after the decision?

These distinctions do not make one account dishonest. They help you identify what the participant actually observed.

For a price objection, ask what was being compared: subscription cost, implementation effort, contract commitment, migration work, or the broader project budget. Do not assume a discount would have changed the decision. Ask about the approval process and alternatives rather than presenting an imagined cheaper offer.

Avoid asking the participant to share a competitor’s confidential proposal or another company’s private information. You can investigate the evaluation process without collecting documents they are not permitted to share.

Work through a fictional loss

Imagine a training team that selected its existing vendor after evaluating a new platform. The initial explanation is “We needed better reporting.” During the fictional timeline exercise, the buyer describes an upcoming training cycle, a required migration review, and insufficient time to complete that review before launch.

There are now at least three hypotheses: reporting was decisive, migration uncertainty was decisive, or the fixed deadline made any vendor change impractical. The account does not establish which one applies to other buyers.

The next useful action could be to examine a completed purchase with a similar deadline, interview the implementation owner, or test whether a clearer migration plan answers the concern. Building a reporting feature is only one possible response.

Use an evidence worksheet after the call

Create one row for each meaningful claim:

Claim: What the participant said influenced the decision.
Event: Where it appears in the reconstructed timeline.
Basis: Direct participation, a document they can discuss, or secondhand knowledge.
Other explanation: What else could account for the same outcome.
Missing perspective: Who or what could clarify the uncertainty.
Potential action: A change or test that would address the specific issue.

Distinguish the buyer’s account from your team’s sales notes. If the records disagree, preserve the disagreement. You may have different viewpoints, different dates, or an incomplete record—not a reason to choose the explanation you prefer.

Compare decisions without counting every mention as a vote

Group accounts by relevant context: a fixed deadline, an existing contract, a required integration, or a particular buying role. A reason that matters in one situation may have little relevance in another.

Track who declined the interview and who you could not reach. People willing to explain a decision are not automatically representative of all lost prospects. Do not turn a small voluntary sample into a percentage of the entire pipeline.

The output should name a decision you can now make more carefully: change the qualification criteria, investigate implementation friction, clarify positioning, test a feature, or leave the product unchanged. Attach the evidence and limits so the next team member can understand why.