Before You Build: A Customer Evidence Sprint

01

Start with a problem you could be wrong about

Write a testable claim: 'Independent service-business owners lose time each week reconciling incomplete customer requests, and some would pay to reduce the rework.' Identify who experiences the problem, when it happens, and what consequence matters. 'Small businesses need better software' is too broad to investigate.

Before talking to anyone, record the strongest reason your idea might not be needed. Perhaps the problem is rare, the workaround is adequate, or the person who struggles with it cannot authorize spending. Set a time cap, a cost cap, and evidence that would make you narrow, revise, or stop the idea.

02

Recruit for contrast, not agreement

Speak with people who experience the work, people who decide or approve purchases, and people who solved the problem another way. These roles may belong to different people. Include a perspective outside your immediate supporters; friends can help you practice, but their encouragement is not independent demand evidence.

Explain that you are learning about the problem, not promising a finished solution. Ask permission to take notes or record. Let people decline and do not request confidential customer, employee, or financial records. Use role labels and sanitized observations in the workbook.

03

Ask about the last real occurrence

Begin with a recent event instead of pitching features. Ask the person to walk through what happened in order. Stay with concrete examples before introducing your idea. Separate what they describe from your interpretation; a vivid story can still be unusual rather than typical.

• When did this last happen, and what triggered it?
• What did you do next, and who else became involved?
• What did it cost in time, rework, missed service, or money? Which parts are estimates?
• What have you already tried? Why do you still use the current workaround?
• Who would use, approve, pay for, and maintain a different solution?
• What would have to happen for changing the process to become a priority?

04

Keep four kinds of evidence separate

Maintain an evidence ledger with the date, role, recent episode, current workaround, buying constraint, and what changed your mind. Count independent situations rather than repeatedly treating one enthusiastic contact as new evidence. Actively retain contradictions. A small, convenient sample cannot establish market size or a reliable conversion rate.

• Observed or reported behavior: what someone actually did. Label direct observation separately from their account of it.
• Consequences: how often the problem occurs and why it matters. Record the basis of any estimate instead of inventing precision.
• Buying conditions: budget ownership, timing, approval, switching costs, and competing priorities. A user can need help without being able to buy it.
• Commitment to a next step: an accepted introduction, a scheduled test, or an appropriately agreed paid pilot. Each supports a different claim; none alone proves repeat demand.

05

Design the smallest honest test

Choose a test that addresses the weakest important assumption. If the uncertainty is whether the problem matters, observe the workflow. If the uncertainty is willingness to change, invite a clearly described trial. If delivery is uncertain, manually provide a narrow service before building automation. Do not use a prototype to answer a pricing question it cannot test.

Write the scope, recipient, permission, delivery effort, success evidence, and stop condition before starting. A paid pilot must be deliverable and transparent about what exists, what does not, and what the customer will receive. Do not imply availability, fabricate scarcity, or take payment for something you cannot responsibly provide. A letter of interest is not revenue; one paid pilot is not repeat demand.

06

Illustrative example: the popular idea that got smaller

A hypothetical founder wants to build an all-in-one intake platform for small service firms. Six conversations are positive, but recent examples reveal different problems. Three firms already have a satisfactory workaround. Two describe frequent rework but require approval from someone the founder has not met. One agrees to test a clearer request form with its operations lead.

The founder does not treat six compliments as six customers. The next test is a narrowly scoped, manually supported intake process for the willing firm. Before starting, they agree to compare missing information and staff rework with a defined baseline, while recording the effort required to maintain the process. The review asks whether the improvement is useful enough to continue and whether the result warrants testing with another firm—not whether it is time to build the whole platform.

07

Review the evidence before increasing the commitment

At the review date, summarize the best evidence for and against the problem, buying conditions, and ability to deliver. Choose continue, narrow, revise, or stop. Continuing means the next test is justified within your limits; it does not mean every assumption is settled.

• Do not ask only 'Would you use this?' and call the answer validation.
• Do not mix different customer groups until every conversation appears to support the same idea.
• Do not confuse free participation, polite interest, or an introduction with willingness to pay.
• Do not interpret refusal as ignorance; your proposal may impose real cost or fail to solve a priority.
• Do not build a large product merely to avoid an uncomfortable conversation with a buyer.

Continue with a related resource

• Build or Buy Decision Workbook
• VMBARS Working Canvas