10 Customer Validation Questions Before You Build (2026)

The best customer validation questions before building do not ask people to design your product. They help you reconstruct what customers already do, where the workflow breaks, which constraints are real, and whether a small test can fit into their world.

This is problem-and-workflow discovery. It comes before detailed pricing, procurement, and sales qualification. If you already know the workflow and need to assess urgency, budget, authority, and commitment, use these customer discovery questions for buying intent instead.

Do not ask all ten questions like a survey. Follow the customer's story, request examples, and probe contradictions. A 30-minute conversation about one real event is more useful than a long list of opinions.

Prepare Without Leading the Interview

Write your assumptions privately before the call:

• who experiences the problem
• what event triggers it
• how they handle it now
• where the current process fails
• what result matters
• what you might test first

Do not show the assumptions to the customer. Your goal is to discover where reality disagrees. Ask permission before recording, explain how notes will be used, and avoid collecting personal or confidential information you do not need.

1. “Walk me through the last time you did this.”

Start with a completed or attempted event, not a general attitude. Ask when it happened, what started it, what the person did first, and how the work ended.

Listen for sequence. A founder may describe “reporting” as one problem, but the real workflow might contain data collection, correction, approval, explanation, and follow-up. Each step has different users and risks.

Useful probes:

• “What happened immediately before that?”
• “What did you do next?”
• “How did you know it was finished?”

Record actions and artifacts, not adjectives such as “painful” or “clunky.”

2. “Can you show me the blank version or a redacted example?”

People omit details when they summarize familiar work. A blank template, checklist, screenshot with sensitive information removed, or sample output can reveal fields, exceptions, handoffs, and hidden quality standards.

Do not pressure someone to share confidential material. Offer alternatives: they can describe the columns, recreate a harmless example, or show only the starting template.

The evidence you want is structure. If every customer uses a different artifact, your proposed product may need a narrower segment. If the same fields and decisions repeat, you may have the basis for a useful first version.

3. “Which step requires the most judgment?”

The most time-consuming step is not always the riskiest. A five-minute approval may require expertise that cannot be reduced to a rule, while an hour of copying may be straightforward to simplify.

Ask what a new employee gets wrong, which decision needs an expert, and what happens when the judgment is poor. This protects you from automating the visible work while ignoring the part customers actually value.

For an AI-assisted product, separate drafting, recommendation, decision, and action. They require different evidence and controls.

4. “Where does the process usually break or return for rework?”

Ask for the last failure, not the ideal process. Work often returns because an input is missing, a stakeholder appears late, the definition of done is unclear, or a tool cannot represent an exception.

Useful probes:

• “Who noticed the problem?”
• “How was it repaired?”
• “What did the repair delay?”
• “Could the problem have been caught earlier?”

A good MVP may solve one rework loop rather than the entire workflow. The failure also gives you a measurable before-and-after test.

5. “What do you deliberately ignore, postpone, or do outside the system?”

Workarounds are often rational. People may keep a private note because the official system is too slow, skip a field because nobody uses it, or delay a task until enough items accumulate.

Do not assume every workaround should disappear. Ask what purpose it serves. An “inefficient” spreadsheet may be flexible, trusted, and easy to audit. Replacing it requires more than a cleaner interface.

Look for jobs the current system cannot represent and steps customers avoid because the cost exceeds the value.

6. “What cannot change about this workflow?”

Constraints shape adoption. The customer may need to keep a system of record, preserve an approval, use a specific file format, meet an accessibility requirement, or retain a human decision.

Ask which constraint is policy, which is customer preference, and which is only habit. Do not argue with the answer. Your first product should fit the real environment or explicitly test whether the customer will change it.

This question often prevents a technically impressive MVP that cannot be used. Integration and trust requirements belong in the product hypothesis from the start.

7. “Which cases do not follow the normal process?”

Every workflow has exceptions: urgent requests, incomplete inputs, unusual customers, seasonal peaks, or approvals from a different person.

Ask how often exceptions occur and what the team does with them. A product that handles the common path but hides exceptions can create more coordination work than it removes.

For the first version, choose one of three strategies:

• exclude the exception clearly
• route it to a human
• support it deliberately and test the added complexity

The right answer depends on frequency and consequence, not on feature ambition.

8. “Who provides the input, who does the work, and who uses the result?”

The user, beneficiary, and owner may be different people. A manager may buy a reporting tool, an analyst may operate it, and a client may act on the result.

Map each role and ask what “good” means to them. One person may want speed, another accuracy, and another an audit trail. A product that delights the buyer but adds work for the operator will struggle to become routine.

This is workflow ownership, not yet a full buying-process interview. Later, investigate approval, budget, and procurement separately.

9. “What would a useful first test need to produce?”

Only after understanding the workflow should you discuss a test. Ask for an observable result the customer could evaluate: a completed report, a correctly routed request, a shortlist with evidence, or a reduced rework loop.

Avoid asking the customer to specify features. Keep the conversation on outcome, input, quality, and evaluation:

• What would you give us?
• What would we return?
• Who would judge it?
• What would make the result unusable?

The answers help you choose among a manual service, prototype, landing page, or another MVP format.

10. “Can we observe or run that small test with a real example?”

Move from conversation to proportionate behavior. The next step might be observing the workflow, reviewing a redacted artifact, delivering one result manually, or testing a clickable prototype with realistic input.

Make the request specific: owner, material, date, expected output, data handling, and follow-up. A polite “keep me posted” is not the same as access to real work.

If the person declines, ask why without pressure. The problem may be weak, the timing wrong, the test unsafe, or the relationship too early. That answer is evidence too.

Turn Notes Into a Build Decision

After five to ten interviews in the same segment, create an evidence table:

Patterns should change your next task. Use the full customer-validation framework to judge the strength of the evidence and the attributed customer-development process to place the work in a wider startup sequence.

If you cannot reach participants, follow this guide to validating an idea without an audience. When the workflow and smallest useful outcome repeat, choose a test from the MVP examples library.

Build only when you can explain whose workflow changes, what real input enters the product, what useful result comes out, which exceptions are excluded, and what behavior will tell you the test worked.