Validating Demand

Demand is not encouragement. Demand exists when a specific buyer has a recurring problem, the problem creates a consequence they care about, money or paid time is already involved, and the buyer will take a real step toward a bounded paid result.

Validation is the process of buying information before making a large commitment. It does not need to prove that a permanent market exists. It needs to answer a smaller question: should this offer, for this buyer, move to the next paid test?

Use G01 to choose a plausible customer and problem. G02 helps keep the test inexpensive. G03 provides safe AI assistance. G05 and G06 cover setup and customer acquisition after demand is visible. This guide focuses on evidence quality, experiments, and stop rules.

Opportunity and Customer

Begin with a customer and a recent event, not an industry and a hope. A useful customer definition includes:

• Who the buyer is.
• The organization type, size, or situation.
• The recurring event that creates work.
• The consequence of delay or error.
• The person who can approve a small purchase.
• How you can reach that person lawfully.

For example: "The office manager of a five-to-fifteen-person accounting practice who has to collect missing client documents before a filing deadline." This is more testable than "accounting firms need better organization."

Map the problem's anatomy

For each candidate, identify:

• Trigger: What starts the work?
• Frequency: How often did it happen in the last three months?
• Current owner: Who does it now?
• Current method: What tools, staff, or workaround are used?
• Failure: What happens when it is late, incomplete, or wrong?
• Consequence: What money, time, trust, risk, or opportunity is affected?
• Budget source: Which account or role would pay for a solution?
• Decision process: Who approves and what evidence do they need?

If any answer is unclear, it is a research question. Do not replace it with a confident assumption.

Separate the problem from the requested solution

A buyer may ask for a dashboard, an automation, or a report. Those are proposed solutions. The underlying problem may be that no one knows which requests are blocked, which clients are waiting, or who owns the next action.

Test the problem first. A simpler list, checklist, or weekly review may solve it without custom software. That outcome can still be a paid service, and it saves both parties from unnecessary complexity.

Identify the buying moment

Demand is easier to validate near a real event:

• A backlog after staff turnover.
• A recurring month-end deadline.
• A new location or service launch.
• A seasonal volume increase.
• A failed audit, complaint, or missed deadline.
• A growth step that makes the current manual process unstable.

Describe the moment truthfully. Do not inflate risk or invent a deadline to pressure a decision.

Fit and Skills

Validation requires access, humility, and a willingness to lose. If you need every conversation to confirm the idea, you will collect reassurance rather than evidence.

Check access before design

Name 20 people who match the customer definition. For each, identify:

• A lawful contact route.
• A reason to believe the problem exists.
• A possible trigger.
• The likely decision owner.
• The next action.

If you cannot name 20 and reach at least ten through appropriate channels, the buyer definition may be too narrow, the problem may be invisible, or distribution may not yet fit your situation.

Define your evidence threshold in advance

Before interviews, write:

• Minimum number of completed conversations.
• Evidence required to proceed.
• Evidence that would cause a revision.
• Evidence that would cause a stop.
• Maximum time and money allowed.

An illustrative threshold might be: complete eight interviews, find at least four recent examples with a measured consequence, identify three buyers with a plausible budget, and secure one paid pilot. These numbers are planning choices, not universal proof.

Decide what you can deliver

Listen for the problem you can solve within your skills, access, and legal role. If every conversation points to regulated advice or a service requiring a licence, validation has identified a boundary. Revise the offer to preparation, routing, or documentation support, or stop.

Keep a learning mindset

Record exact buyer language and facts. Do not convert one vivid story into a market conclusion. Look for patterns across independent buyers, and note strong counterexamples.

Startup Budget

Validation should be inexpensive relative to the loss you are trying to avoid. The following ranges are illustrative and vary by location.

Conversation stage

Illustrative range: 0 to 100 currency units.

• A note-taking document.
• A simple call account if needed.
• Local travel only when it materially improves access.
• A small incentive only when it is appropriate and lawful.

Do not buy advertising to test a problem you have not discussed with buyers. Paid traffic is better for testing a clear offer after the problem and message are understood.

Prototype stage

Illustrative range: 0 to 250 currency units.

• A fictional sample.
• A landing page on an existing site.
• A scheduling form.
• A short diagnostic template.
• A paid pilot workspace.

Keep the prototype separate from the permanent business. A validation page should state what is available, who it is for, what happens next, and that any price is a test or quote, not a guaranteed result.

Paid experiment stage

The experiment budget should include:

• Delivery time.
• Customer acquisition time.
• Direct tool or material cost.
• A correction allowance.
• Payment fees.
• A reserve for refunds if the promised result is not delivered.

Set a cap before starting. If the experiment is not producing evidence within the cap, stop and decide rather than extending it out of sunk-cost pressure.

Validation does not need a legal entity first

The correct setup order depends on jurisdiction and activity. You may be able to conduct interviews and prepare a sample before registering a business, but paid work, banking, tax, privacy, insurance, and licensing requirements still apply. Ask a qualified local adviser before taking money or handling regulated information.

Skill Acquisition

The central skill is asking about behavior without steering the answer.

Learn the past-behaviour interview

Ask:

1. Tell me about the last time this happened.
2. What triggered it?
3. Who did the work?
4. What did they use?
5. How long did it take?
6. What went wrong or required rework?
7. What did the delay or error affect?
8. What did it cost or displace?
9. Have you paid for this before?
10. Who approves a purchase like this?

Avoid:

• "Would you use this?"
• "Do you think this is a good idea?"
• "How much would you pay?" before understanding the current alternative.
• Leading descriptions of the tool or outcome.

Hypothetical answers can be useful for learning language, but they are weaker than recent behavior and a real purchase decision.

Practice silence and follow-up

After the buyer answers, wait. Then ask for an example, number, or document where appropriate. "Can you walk me through what happened next?" often produces more useful evidence than another opinion question.

Learn to test one variable

A validation experiment is easier to interpret when it changes one major thing:

• Which customer segment sees the message.
• Which problem framing is used.
• Which deliverable is offered.
• Which price threshold is requested.
• Which channel produces qualified conversations.

If you change all four at once and receive mixed results, you will not know what caused them.

Practice asking for payment

Rehearse a clear request:

"Based on what you described, the smallest useful test is [result] for [scope], completed by [date], for [price]. It includes [approval and handoff]. Would you like to proceed with that paid pilot?"

If the answer is no, ask what would need to be different. Record the response without arguing.

Setup

Set up a small evidence system before collecting data.

Create an interview register

For each conversation, record:

• Date and customer type.
• How you were introduced or found the contact.
• Recent problem example.
• Frequency and current owner.
• Consequence and evidence of spend.
• Decision process.
• Objections.
• Follow-up action and date.
• Consent and data-handling notes.

Keep only the information needed for the research. Do not copy private documents into unapproved tools or public samples.

Separate evidence from interpretation

Use two fields:

• Observed: "The office manager said she spent two days last month rechecking missing client documents."
• Interpretation: "I think the firm would buy a document collection service."

The first is evidence. The second is a hypothesis. This distinction prevents a confident conclusion from hiding a weak input.

Prepare a consent and use statement

Before recording a call or collecting examples, explain:

• Why you are collecting the information.
• How it will be stored.
• Whether it will be used in a sample.
• How it will be deleted.
• How the participant can ask a question or withdraw where appropriate.

Respect applicable privacy, recording, anti-spam, and consumer rules.

Prepare a pilot agreement

Even a small test needs a written scope:

• Deliverable.
• Volume or maximum effort.
• Inputs and access.
• Start and finish dates.
• Review and revision limit.
• Approval role.
• Price and payment terms.
• Data handling and deletion.
• Exclusions and stop condition.

Use qualified local advice for contracts when the value, data sensitivity, or risk warrants it.

Set a decision date

Choose the date when you will review the evidence. Without a date, validation can continue indefinitely and become an expensive way to postpone a decision.

Concrete Offer

Validation offers should produce evidence without requiring the buyer to imagine a finished future.

Offer A: Paid diagnostic

"I will review one recent workflow with you, map the inputs and handoffs, identify missing fields and approval points, and deliver a one-page recommendation with a pilot scope and estimated delivery range. The fee is [price]."

A diagnostic is a real service when it produces a decision-ready document. It is not a disguised sales call.

Offer B: Narrow paid pilot

"I will complete [one result] for up to [volume] by [date] using [inputs and method]. You will receive [deliverables], one review round, and a handoff note. The fee is [price], with [payment terms]."

The result should be deliverable with existing tools and a checklist. The buyer should be able to accept or reject it against a stated standard.

Offer C: Reservation with a clear condition

For a future service, you can ask for a refundable or non-refundable reservation only if local law and the terms allow it and the buyer understands what is being reserved. Avoid pretending that a deposit is a proven purchase if the deliverable, date, or terms are not defined.

A reservation can test commitment, but it is not as strong as completed paid delivery. A waitlist signup is weaker still because it has little cost to the buyer.

Outreach

The purpose of validation outreach is to learn and to ask for a test, not to collect as many contacts as possible.

Use a specific invitation

Subject: How did you handle [specific recurring task] recently?

"Hello [Name], I am researching how [customer type] manages [specific task]. I am trying to understand the last time it caused delay or rework. Could I ask about one recent example in a 15-minute conversation? I am not asking you to buy anything or change systems."

The message should be honest about the stage. It should also respect the person's time and stop after a clear no or an opt-out.

Speak with the user and the buyer where possible

The person doing the work understands exceptions. The person who approves spending understands consequences and budget. If they are different, interview both. Otherwise, a solution may be useful to operations but impossible to purchase.

Ask for a paid next step only after fit

Do not end every conversation with a pitch. First confirm that the problem is recent, costly, and owned. Then describe the smallest test and ask for a decision.

Measure channel quality

Track:

• Invitations sent.
• Responses.
• Interviews completed.
• Qualified problems.
• Requests for a sample or proposal.
• Paid tests accepted.
• Reasons for no.

An outreach channel that produces pleasant conversations but no qualified buyers is not a sales channel yet.

Pricing and Unit Economics

Price the test high enough to measure real willingness to pay and low enough to keep the buyer's risk bounded. Zero is not a price test.

Use a three-part price test

1. Value anchor: What does the current workaround cost in paid time, delay, rework, or lost opportunity?
2. Delivery floor: What price covers delivery, selling, administration, direct costs, corrections, and the required contribution?
3. Buyer threshold: What amount can the buyer approve without a long procurement process?

The test price should sit at or above the delivery floor and, where possible, below the buyer's easy-approval threshold.

Illustrative arithmetic

Suppose a diagnostic takes four delivery hours, one sales hour, one preparation hour, and 15 currency units of direct cost. A 200-unit fee leaves 185 before tax and general overhead over six hours, or 30.83 per working hour. If the conversion requires four calls and two proposals for every accepted diagnostic, the effective time and acquisition cost are higher.

Record all selling time. A price that looks acceptable for one project can be inadequate when the cost to acquire the project is included.

Test price with a real choice

A useful sequence is:

• Describe the outcome and boundary.
• Ask whether the buyer wants to proceed at the stated price.
• Pause and let the buyer decide.
• Record the answer without offering an immediate discount.

If the buyer says no, ask whether the problem, scope, timing, authority, or price is the issue. Do not assume the answer.

Avoid a free custom project

A free prototype can attract buyers who are curious but unwilling to commit. A small paid diagnostic or pilot is a better test. If you offer a no-cost sample, make it generic or fictional and clearly bounded.

Delivery Example (Illustrative)

The following is an illustrative composite, not a real case study.

A relocation coordinator at a mid-sized property management company collects utility, access, and move-in details for new tenants. Each week she rechecks spreadsheets and messages for missing information. She believes a central dashboard would help, but the company has not approved software.

The seller interviews the coordinator and the operations manager. Both describe a recent move-in delay caused by missing access information. The manager identifies the person who approved a small vendor invoice and the budget likely to cover a one-time cleanup. The seller tests a smaller offer: a ten-day paid completeness review for one week of move-in records, not a dashboard.

The seller asks for access to a sanitized export and a written set of required fields. The output is a prioritized exception list with owner, due date, source, and status. It includes a draft message for the coordinator to approve, but no message is sent automatically. Price is 300, with payment after acceptance because the buyer is a new customer and the scope is low-risk.

The buyer rejects the pilot at first, saying the team is too busy to provide a clean export. The seller records that objection and tests a second design: the buyer provides a messy export, and the seller includes cleanup in the scope for 380. The buyer accepts the second version. This evolution is evidence about the cost of input preparation, not simply a price discount.

The pilot may still fail if the exception list requires decisions the coordinator cannot make or if the review takes more time than the fee supports. Either result reduces the risk of building a dashboard nobody uses. The seller records the actual reason for the outcome before changing the offer again.

Growth

Validation does not end after the first sale. It becomes a recurring discipline.

Repeat with a distinct buyer

One paid pilot can be an outlier or a special relationship. Sell the same offer to several similar buyers before treating it as repeatable. Track whether the problem, inputs, time, and approval process stay comparable.

Expand only from adjacent evidence

Add a second service only when existing buyers identify the next problem and a paid test is possible. Do not expand because the first service used a tool that could do many other things.

Maintain a contraindication list

Record buyers or situations that are not a fit:

• The buyer cannot provide the necessary data lawfully.
• The work requires a licensed professional.
• The approval process makes the scope impossible.
• The buyer wants unlimited changes.
• The expected volume does not support the price.
• The buyer is purchasing a promise the service cannot verify.

This list improves targeting and protects quality.

Keep a test cadence

Run one new demand hypothesis at a time. Review results weekly and make a decision at the planned date. Preserve the test design and evidence so a future decision does not depend on memory.

Risks

False positives

Friends, peers, and enthusiastic strangers can produce polite encouragement. Weight recent behavior, paid attempts, a decision owner, and an actual purchase more heavily than compliments.

False negatives

A good opportunity may fail the first test because the customer definition, message, timing, or scope was wrong. Diagnose the cause before declaring the market dead. Do not use that possibility as an excuse for endless retesting.

Leading questions

Describing your solution before asking about the current process can teach people to agree with you. Ask about the last real occurrence first.

Sampling the easy but unrepresentative

Your network may not contain the buyer who can pay. If every prospect is a peer with no budget, revise access instead of concluding that the service has no value.

Free consulting

Long unpaid discovery makes validation expensive and can attract buyers who never commit. Cap the conversation, clarify the purpose, and sell a diagnostic or pilot when deeper design is needed.

Incentives that distort behavior

Paid research participants or referral incentives can be appropriate, but they may change who responds. Understand the bias and follow local rules.

Privacy and data misuse

Interview notes, exports, recordings, and customer examples may contain personal or confidential information. Use consent, minimization, secure storage, and deletion. Do not publish identifiable examples without permission.

Regulatory and professional boundaries

Do not let the search for demand push you into advice or services you are not qualified to provide. Confirm licensing, insurance, tax, privacy, and consumer obligations in your jurisdiction.

Sunk-cost pressure

The more time you spend, the more tempting it is to reinterpret weak evidence as success. Set the stop rule before the test and use a second person to review the decision where possible.

This guide is general education, not legal, tax, accounting, insurance, or licensing advice.

Privacy and AI Verification

Validation often includes sensitive customer examples. Protect them from the first interview.

• State the purpose and use of the information.
• Collect only the evidence needed for the test.
• Use fictional or sanitized examples in public materials.
• Do not place raw customer files into unapproved AI tools.
• If AI helps summarize notes, correct the summary against the source.
• Keep identifiers and sensitive details out of prompts where possible.
• Record who reviewed a generated summary.
• Do not represent an AI-generated market estimate as observed spending.
• Store the evidence in a controlled location and delete it when no longer needed.
• Separate a customer's factual answer from your interpretation.

AI can help organize evidence, but it cannot manufacture demand. A generated persona, industry report, or survey summary is not a substitute for a buyer's recent behavior and a real paid decision.

30-Day Action Plan

Days 1 to 3: Define the hypothesis

• Write the customer, trigger, problem, consequence, and likely budget source.
• Name the decision owner.
• Write the evidence threshold and maximum test budget.
• List assumptions that would invalidate the idea.

Days 4 to 6: Build the prospect list

• Identify 20 buyers and lawful routes to reach them.
• Record why each might have a recent trigger.
• Choose one channel for the first conversations.
• Prepare a short research invitation and an opt-out.

Days 7 to 13: Interview

• Complete at least six to eight conversations.
• Ask about last quarter's real examples.
• Record current spend, time, consequence, and approval.
• Ask for relevant documents only when necessary and authorized.

Days 14 to 16: Review the evidence

• Separate observations from interpretations.
• Count qualified problems, not compliments.
• Identify repeated objections and missing information.
• Choose one problem and one bounded result to test.

Days 17 to 20: Build the smallest test

• Write a one-page pilot scope and acceptance standard.
• Prepare a fictional sample if it helps the decision.
• Calculate the delivery floor and the buyer's approval threshold.
• Define payment and a stop condition.

Days 21 to 26: Ask for a paid decision

• Return to the most relevant buyers.
• Present the test clearly and ask for a yes or no.
• Record objections without discounting automatically.
• If the test changes, run a clearly revised version.

Days 27 to 30: Deliver or stop

• If a buyer pays, deliver within scope and record time, cost, and corrections.
• If no buyer pays, write down the evidence that would justify another attempt.
• If the problem is not real, stop.
• Share the evidence with someone who will challenge your interpretation.

Templates

Demand hypothesis

• Customer: [specific buyer and situation]
• Trigger: [event]
• Problem: [observable work or failure]
• Consequence: [time, money, trust, risk, or opportunity]
• Current alternative: [staff, tool, process, or paid provider]
• Budget source: [role or account]
• Decision owner: [role]
• Small paid test: [result, scope, price]
• Disconfirming evidence: [what would make me stop]

Interview record

• Date:
• Participant type:
• How recruited:
• Recent example:
• Frequency:
• Current owner and method:
• Consequence:
• Evidence of spend:
• Decision process:
• Exact useful quote:
• My interpretation:
• Follow-up:

Evidence scorecard

For each opportunity, score from 0 to 4:

• Recent occurrence.
• Consequence.
• Repeated frequency.
• Existing spend.
• Reachable buyer.
• Clear decision owner.
• Buyer willingness to take a next step.

Write the evidence beside each score. Do not average away a zero on access or decision authority.

Paid test scope

• Buyer and approver:
• Result:
• Inputs:
• Volume and finish line:
• Deliverables:
• Acceptance standard:
• Review and revision limit:
• Privacy and access:
• Exclusions:
• Price and payment:
• Start and end dates:
• Stop condition:

Decision memo

• What we expected:
• What we observed:
• What changed:
• What remains uncertain:
• Did a buyer pay?
• Does the price cover the delivery system?
• Is delivery within our qualifications and capacity?
• Decision: continue, revise, or stop.
• Next test and date:

Common Mistakes

Asking whether people like the idea

Likability is not demand. Ask about recent work, cost, workaround, and a real purchase decision.

Counting a waitlist as a sale

A waitlist can measure interest, but it does not prove someone will pay or that the service can be delivered profitably.

Building a full service before the test

A prototype should be enough to support a paid diagnostic or narrow pilot. Build the permanent system only after the evidence supports it.

Changing everything after one no

Record the objection first. A pricing objection is different from an access problem, an authority problem, or a scope problem.

Treating a buyer's requested tool as the problem

The tool may be a proposed solution. Test the work, consequence, and current alternative before committing to it.

Ignoring the buyer's privacy concerns

A buyer who cannot trust you with a small sample will not trust you with the operating workflow. The concern is useful evidence, not an obstacle to overcome.

Key Takeaways

• Demand means recent, consequential behavior plus a real next step toward payment, not praise.
• Define the buyer, trigger, problem, current cost, budget source, and decision owner.
• Set evidence thresholds and a stop rule before collecting information.
• Interview the person doing the work and the person who can approve a purchase when they differ.
• Test one major variable at a time.
• Use a paid diagnostic or a narrow pilot before building a full service.
• Price the full delivery system, including selling, administration, review, and acquisition cost.
• Treat a no as information and record the reason before changing the plan.
• Protect interview data and verify AI summaries against their sources.
• Confirm local legal, tax, privacy, insurance, and licensing requirements before taking on real work.