B2B customer interviews: test your offer before building it

Your first question is not whether people like your idea. It is which decision the conversation needs to inform. For an independent professional considering a new service, that decision might be to keep investigating a problem, change the intended audience, or build nothing yet. Write it down before preparing a presentation. Otherwise, every positive comment can become another excuse to keep the project you already prefer.

Next, state a narrow hypothesis: “I think managers of small maintenance businesses lose track of requests arriving through several channels, and they are already trying to simplify that process.” This is a fictional example, not a market observation. It identifies a role, a situation, and a behaviour worth investigating. It assumes neither a budget, nor a need for artificial intelligence, nor a preference for your proposed solution.

Write down what would change your mind as well: requests are already centralised; missed requests are rare; the difficulty belongs to the customer rather than the service provider; or an internal constraint prevents any change. Look for these counterexamples as deliberately as you look for confirmation. Bpifrance Création recommends confronting an idea with its prospective customers. The method in this guide turns that intention into a documented decision. It does not certify that a market exists.

A friendly person is not necessarily an informative participant. Start with the role that actually performs the task, then identify who decides whether the process can change. In a very small business, these may be the same person. Elsewhere, an assistant knows the incidents while an owner controls the budget. Do not ask either person to guess the other person's daily actions or constraints.

Prepare observable inclusion criteria: the relevant activity, responsibility for the task, and recent experience of the situation. Exclude people who can only comment on the industry from a distance. However, include some participants who could contradict your hypothesis: a business with a satisfactory existing solution, or one that abandoned a similar project. They may explain why your service would be unnecessary or difficult to adopt.

To begin without an advertising budget, look for introductions people have agreed to, professional events, and communities where requesting an interview is appropriate. Do not turn a directory into a mass campaign. A list of businesses helps identify possible contexts. It establishes neither a need nor permission to contact anybody.

Keep one record per interview, including the participant's role, business context, and recruitment method. If everybody comes from your existing network, acknowledge that limitation. An openly described convenience sample is more useful than presenting those answers as representative of every small business.

Your invitation should explain why you are approaching this person and what you want from them. Do not describe the work as independent research if you are developing your own business. Do not promise a personalised report that you cannot produce. A clear request can remain simple: “I am exploring a service around handling customer requests. I want to understand how this task currently works in small businesses. Would you be open to a twenty-minute exploratory conversation, without a sales demonstration?”

This is a template to adapt, not a message that has been sent or permission that has already been granted. The duration is a practical choice, not a scientific standard. If the person agrees, confirm the subject and make it clear they can decline a question. If they refuse, thank them and do not push. No response does not prove your hypothesis is wrong: the timing, channel, or request may simply be unsuitable.

At the beginning, explain how you will take notes. A notebook containing only details relevant to the problem is usually sufficient for this exercise. Do not request customer records, passwords, or confidential documents. When a real example involves sensitive information, suggest an anonymised description. Never record the conversation secretly or publish an attributed quotation without explicit permission. These precautions support both the quality of the conversation and the relationship you are building.

Begin with a specific situation: “Could you walk me through the last time a request was difficult to keep track of?” Let the participant decide what was difficult. If they cannot remember an incident, do not immediately supply a list of problems for them to approve. Ask how the normal process prevents that difficulty instead. The absence of an incident can be useful information.

Follow the sequence of events. What triggered the task? Who received the information? Where was it kept? What did the person do next? When did they notice a difficulty? How did the situation end? These questions help separate a general impression from a process someone can actually describe.

Keep your proposed solution out of this part of the conversation. Showing a prototype immediately shifts attention towards colours, features, and the wish to encourage you. You may leave with a list of improvements to a tool whose usefulness has never been established.

If the participant asks what you intend to sell, answer honestly. You are still exploring the problem and can discuss a possible approach after understanding how the task works. Bpifrance's qualitative interview guide is presented as a resource for exploring expectations, motivations, and barriers. In this method, the account of a specific episode provides a concrete starting point for that exploration.

A question can manufacture the answer you want. “You waste a lot of time with spreadsheets, don't you?” already assumes a loss and identifies its cause. Replace it with “How do you use spreadsheets for this task?” followed by “What works well, and what works less well?” You obtain a description before asking for an evaluation.

Be equally careful with the future. “Would you buy a tool that solves this?” invites an imaginary purchase without real constraints. Ask instead what the person has tried, why they chose it, and what prevented another approach. When someone spontaneously requests a feature, return to its use: “In which situation would that have helped you?” The need may be real without the suggested solution being the only sensible response.

Prepare a few follow-up questions and use them sparingly:

• “What happened immediately before that?”
• “What do you mean by complicated in this situation?”
• “How did you decide what to do?”
• “When does this work without any difficulty?”
• “What have I misunderstood in that summary?”

Do not turn the list into an interrogation. A short silence sometimes allows the participant to complete their account. Your objective is not to fill every box during the call. It is to distinguish what you have genuinely learned from what remains unknown. If a question produces confusion twice, simplify its wording rather than explaining the answer you hoped to hear.

A problem can be annoying without justifying a purchase. Look for its concrete consequence. Does searching for information take time? Delay a service visit? Cause duplicate data entry? Has the participant changed the way they work to avoid it? Do not automatically convert inconvenience into lost revenue.

When somebody mentions a duration or a cost, ask how they estimated it. Label it as the participant's estimate unless you have a verifiable measurement. For example, “about an hour in some weeks” does not become “fifty-two hours wasted every year.” Frequency, quiet periods, and other activities performed during that time are still unknown. An attractive projection cannot replace those missing details.

Explore relative priority too: “Which other difficulties take precedence over this one right now?” A business may recognise the problem while focusing on hiring or moving premises. That does not make the account useless. It changes the commercial conclusion you can reasonably draw from it.

Finally, identify the costs of changing the process: learning, transferring information, depending on a supplier, or coordinating with another team. Your eventual service may need to reduce these obstacles rather than add features. In the interview summary, keep three separate lines for the inconvenience described, the consequence reported, and the current priority. Combining them into a single claim creates more certainty than the conversation supports.

In an exploratory interview, understanding buying does not mean requesting an immediate commitment. Ask how a comparable decision happened: who proposed the change, who assessed the solution, who approved the expense, and what delayed agreement. A previous purchase provides context. It does not guarantee that a future purchase will follow the same path.

Separate the person experiencing the problem, the person who would use the service, and the person authorised to decide. When these roles differ, do not assume a budget exists because the user sounds enthusiastic. You can ask whether somebody else would be better placed to explain the process. Do not demand their contact details or treat a suggestion as an introduction they have accepted.

CCI Lyon Métropole notes that market research also examines how customers buy, rather than only who they are. In your worksheet, translate that into concrete conditions: internal approval, decision timing, compatibility with existing processes, and the evidence expected. If the answer is unknown, write “unknown.”

Avoid turning the conversation into hidden sales qualification. A successful interview can produce better understanding without producing a sales opportunity. Filtering prospects before outbound outreach addresses a different decision: who to approach commercially once your service is sufficiently defined. Keeping those objectives separate makes your invitation more honest and your interpretation of the answers more reliable.

After the interview, complete this worksheet while the account is still fresh. A simple document or spreadsheet is sufficient. One record represents one person and one situation, not an entire business treated as if everybody had the same experience.

1. Context and experienced problem: role, task, most recent episode described, and triggering event.
2. Current approach: tools, people, steps, and why that approach remains in use.
3. Consequence: specific inconvenience, reported effect, known or unknown frequency, and the origin of any estimate.
4. Decision to change: relevant roles, constraints, priority, and experience of a comparable purchase.
5. Next experiment: the missing observation and a proportionate way to obtain it.

For every field, add three columns: “statement or reported fact,” “my interpretation,” and “what could contradict it.” A paraphrase is not an exact quotation. Use quotation marks only when you have preserved the wording faithfully and its use is authorised. For internal analysis, a code can replace the person's name.

Do not add these elements into a score out of one hundred. A strong consequence combined with a poorly understood situation does not become a good opportunity through averaging. Use explicit labels instead: documented through an account, general opinion, personal hypothesis, or missing information. The purpose is to trace the path from an answer to your decision, not to make intuition look mathematical.

The final column should change what you do next. “Keep thinking” is too vague. “Interview the role that approves changes” gives you an actionable next step.

Imagine an independent professional considering a request-tracking service for maintenance businesses. Every detail in this example is fictional. The initial hypothesis is that requests get lost because they arrive through multiple channels. The researcher interviews a coordinator, an owner, and a manager from a different business without presenting software.

The coordinator describes a recent incident: the request had been received, but the service visit was waiting for technical information. The owner explains that a centralised list already exists and does not want another tool. The third participant describes a satisfactory process because somebody checks the necessary information before scheduling work. These accounts do not establish a need for centralisation.

The independent professional creates three separate records. For the coordinator, they note the missing technical information and the delayed visit; the current checking process still needs clarification. For the owner, they record the existence of a centralised list and the refusal to add another tool. For the other manager, they record the preliminary checks and the process described as satisfactory. They do not transfer practices from one business to another. For each participant, priority and purchasing conditions remain unexplored. The interpretation changes: help preparing complete requests might be more useful than another tracking board. A competing explanation remains visible too: an internal instruction could be sufficient without an external supplier.

The next experiment is therefore not to build software. It is to ask relevant people how they check whether a request is complete, then, with their agreement, explore a simple checklist using an anonymised case. Even if the checklist appears useful, that establishes neither a large market nor willingness to pay. The main value of the interview is avoiding the premature conversion of an assumption into a product.

Review your records by situation rather than enthusiasm. Two people may use the same word, such as “disorganisation,” to describe different problems. One is looking for information while the other is waiting for approval. Combining those accounts without distinction produces a vague service. Compare triggers, tasks, and consequences first, then compare the language people use.

Next, look for exceptions. Why does one business avoid the difficulty? Does it have a dedicated person, a different workload, a simple procedure, or a satisfactory tool? An exception may reveal an essential condition for your intended audience. It may also show that your proposed solution would cost more than the practice already in place.

Do not treat interviews as votes. Three favourable answers in five conversations do not prove that sixty percent of the market would buy. The participants were not necessarily selected to represent that market, and a favourable answer is not a purchase. Keep counts as a description of the research you performed, never as a sales forecast.

When accounts diverge, do not force them into a single story. Separate the contexts and define a narrower question for the next round. You may also decide that the problem is too fragmented for your current resources. Abandoning a weak hypothesis is a useful decision, not a failure to hide by conducting more interviews. Keep the evidence that led to that choice so that you can revisit it if the circumstances change.

At the end of your analysis, choose whether to continue, change direction, or stop. Continuing means that you have a more precise question to test. It does not mean the service has been validated. A change might concern the audience, the task, the moment of intervention, or the form of the service. Stopping means the evidence collected does not justify the next investment you were considering.

Match the experiment to the remaining uncertainty. If the workflow is unclear, request an anonymised example or a step-by-step explanation. If the usefulness of a deliverable remains unknown, show a limited draft after the interview. If the decision process is missing, speak with the relevant role. A commercial proposal or paid pilot belongs to a separate stage, with its scope and conditions explicitly discussed.

Decide beforehand what the experiment could teach you and what would make you abandon the idea. Avoid tests in which every reaction becomes positive evidence: silence is not hidden interest; a request for documentation is not an order; and accepting something free does not prove that a budget exists.

Once you have a service to demonstrate, the guide to finding first clients without a portfolio covers presenting evidence of your work. Do not reverse the sequence. An attractive demonstration can make a solution understandable without establishing that the underlying problem is worth solving.

For your first round, reserve time for preparation, conversations, and analysis separately. The number of interviews depends on the diversity of situations and your availability. No magic interview count turns qualitative observations into universal validation. Start small enough to review every record carefully, then decide whether further conversations would genuinely answer an unresolved question.

Before each interview, reread the hypothesis and the counterexamples you want to investigate. During the conversation, prioritise the participant's account over your sales argument. Afterwards, separate their statements, your interpretation, and the unknowns. At the end of the round, write a one-sentence decision: “I am changing this hypothesis because these situations show this, and this question still needs investigation.” If you cannot write that sentence, identify exactly what is missing.

You do not need specialised software to use the worksheet. Once your audience becomes clearer and you move into prospecting, the SprintLead page for independent professionals describes tools for finding and following up with prospects. That stage replaces neither exploratory conversations nor your analysis. This guide assumes no customer-interview or market-validation feature in SprintLead.

Your next action can therefore remain modest: write a hypothesis that could be disproved, identify one person directly affected by the situation, and prepare an honest invitation. The value comes from what you are willing to learn, including answers that make your original project less attractive.