How to Interview Customers on Alternatives They Have Tried

Every question in the script below points backward in time. You are not asking what someone would do. You are asking what they did, in what order, and what it cost them. This is the jobs-to-be-done stance: customers hire products to get a job done, and the useful question is what they hired before yours existed (HBS Online on value propositions and jobs to be done).

The distinction is worth stating plainly, because it changes how you write questions.

Notice that each pair keeps the topic the same and moves the tense. You are not adding cleverness, only facts.

Run the interview in 35 to 45 minutes. Do not skip block one, and do not read questions in a flat list; the script is a ladder, and each block only works if the one before it produced detail.

Block 1: Set the frame (3 minutes). Tell the person you are researching how people handle a problem, that you are not selling anything, and that you will not describe your product. Wilcox's first rule covers this: do not talk about the idea, because the interviewee will unconsciously help you confirm it (Customer DevLabs).

Block 2: The timeline of the last attempt (15 minutes). This is where most of your data comes from.

1. "Take me back to the last time you had to deal with this. When was it, roughly?"
2. "What happened first? And then what?"
3. "Where were you doing this, and who else was involved?"
4. "What did you use to get through it?"
5. "How long did that take, start to finish?"

Push for artifacts. Ask to see the spreadsheet, the checklist, the Slack thread. Alyssa Haman's short list of five interview questions includes exactly this move: what does your current process look like, what challenges come up, and why do you bother doing it at all (Five GREAT Customer Interview Questions). The "why do you bother" question is the one that surfaces the job underneath the task.

Block 3: The alternatives inventory (8 minutes). Now widen the lens.

• "Before this last attempt, what had you tried? Walk me through each one."
• "Which of those did you pay for, and roughly how much?"
• "Did you build anything yourself? A sheet, a script, an internal process?"
• "Was there anything you looked at and rejected? What made you reject it?"
• "Did you ask anyone for help, and what did they suggest?"

The rejection question is the one teams skip and the one that pays best. A rejected alternative tells you about a fear or a constraint, not a competitor.

Block 4: The trigger and the swap (7 minutes). Why did the last attempt happen when it did?

• "What happened just before you went looking?"
• "What was the cost of not solving it?"
• "What almost stopped you from trying something new?"
• "What made you finally commit?"

The trigger is your campaign targeting and your sales opener. The near-miss is your objection-handling doc.

Block 5: What they settled for (5 minutes). "What are you still doing by hand today?" and "What have you given up on entirely?" This is your roadmap, written by the customer, and it maps directly to the pains and gains language in Strategyzer's value proposition work (Strategyzer on value propositions).

Block 6: The close (2 minutes). "Is there anything important about how you handled this that I didn't ask about?" The open close catches what your script missed, which is the point of Haman's fifth question as well (Five GREAT Customer Interview Questions).

Suppose you are building a tool for contract review at mid-size companies. You run 12 interviews using the script. Here is a plausible tally you could construct from your notes, kept in a simple sheet with one row per alternative mentioned and a count per interview:

Read the table the way a positioning team would. The real competitor in this sample is not a contract tool; it is the legal team's calendar plus someone's private checklist. That changes the pitch: the comparison a buyer is making is "my internal review versus this software," not "your software versus the other vendor." It also changes the roadmap: the spreadsheet with 40 rules is a spec for an import feature, and the 3 buyers who abandoned the general document tool are your warm list. For a full positioning exercise built on those facts, the five-step structure Dunford uses starts by letting go of the market you came from and ends with a frame of reference your buyers already use (A Product Positioning Exercise).

Three artifacts come out of a batch of interviews.

A ranked alternative list. Count how many interviews each alternative appeared in, and how many people paid for it. The alternative that appears in the most interviews is your real comparison set, even if it is a spreadsheet. Cornell's guidance on positioning statements insists the frame of reference and reason to believe must be meaningful to customers, not just to the company (Cornell on market positioning statements). The interview count is how you check the "meaningful to customers" part rather than assuming it.

A switching map. For each interview, note the trigger, the first workaround, the candidate alternatives considered, the objection that nearly stopped the switch, and the reason for committing. The objections cluster. If six of twelve said a security review almost stopped them, you have found a sales asset to build, and a website section to write.

A message test. Write one sentence per interview in the customer's words: "Before [trigger], I used [alternative], and what I still had to do by hand was [gap]." If you cannot fill the gap with a concrete task, the interview was too abstract and you should re-ask block two. Salesforce's write-up on value propositions puts the same point in sales terms: buyers are more likely to buy when they feel their goals are understood, and the interview is where you earn the right to state those goals back (Salesforce on customer value propositions).

One caution: do not let the interviews become a search for a new category name. For most products, the right move is to position within an existing category that buyers already search for, or to carve a specific position inside a crowded one, rather than to invent a category, because category creation is a multi-year investment justified only when the market genuinely lacks a frame (10louder on defining your category). The interview data tells you which frame people used when they went looking, and that frame is usually the one to adopt.

The hypothetical trap. Any sentence that starts "would you" is asking about a person you invented. Replace it with "did you."

The compliment trap. Customers are polite, and a confident founder is hard to say no to. Wilcox's warning about the interviewee becoming an unwitting accomplice is the mechanism to watch for (Customer DevLabs).

The single-source trap. One vivid story is not a pattern. Ten to twelve interviews per segment is a working number for reaching pattern clarity, and you extend the batch if themes are not repeating (Haman describes the same approach: about ten 30-minute interviews, then another ten if clarity is missing) (Five GREAT Customer Interview Questions).

The confirmation trap. If you already have a positioning deck, interview someone who has never seen it and do not show it to them afterward. Their unprompted description of the alternatives is the data.

The founder-only trap. The person who built the product is the worst person to run this interview, because the temptation to explain is strongest there. Send someone who has to learn the answer.

Transcribing and tagging interviews used to be the bottleneck that kept teams to five calls. Now the bottleneck is recruiting the right people and pushing hard enough in block two. A practical setup: record with consent, transcribe, then extract one row per interview with columns for trigger, alternatives, money spent, abandoned alternatives, near-miss objection and remaining manual work. Manual coding of a dozen interviews is fine, but doing it by hand for a second segment or a second language is where teams stop.

If you are running a program of interviews across several segments and want the analysis to be consistent, a tool-agnostic layer for summarization and extraction helps. Quanta Inference offers text, audio, video and embedding models through one API key, which is enough to batch transcribe recordings and embed the notes so you can search them by theme later (https://quantaintelligence.ai/inference). When you have the analysis and need to turn it into a positioning page, a sales deck or a comparison page, describe the deliverable to Quanta and let a specialist build it with you (https://quantaintelligence.ai/).