How Technical Founders Validate Demand: From Concrete Scenario to First Paid Pilot

1. Narrow "Demand Category" to a Real Task

Technical founders often list their capabilities — coding, deployment, cloud, AI-assisted development — but struggle to answer who will buy. Broad directions like "enterprises need software" or "improve development efficiency" are too large to act on. A useful starting point is to answer: What specific group of people is trying to complete what task, where are they stuck, how do they solve it now, what is the cost, and who decides payment?

A small team without dedicated ops must demo to a client next week. The lead has spent two days on environment issues and wants deployment completed before the demo, with verified access, configuration, and rollback steps.

This description is still a hypothesis, but it guides action: you know which teams to approach, which deployment to ask about, what deadline matters, and how the first delivery can be accepted.

A key distinction: the task and the customer's requested feature are different. A customer asking for an "automated deployment platform" may actually need to demo on time or enable juniors to release. The former might be solved with one-time deployment help; the latter may require docs, permissions, and a release process. The article references the Jobs-to-Be-Done theory (Christensen Institute) to frame demand as progress in a specific context, noting this alone does not prove willingness to pay.

2. Use Your Circle of Competence to Find the Scene

Starting from a concrete scene does not mean picking a random niche. For solo ventures, speed of understanding, access to buyers, and delivery ability all affect trial cost. Review your own work history: which tasks repeatedly needed ad-hoc help? Which issues caused repeated delays? Which technical problems had no owner?

The article provides a demonstration table (not real validated opportunities) mapping three technical directions to interview-worthy scenes and misjudgments to exclude:

Project Deployment: Small team without ops, blocked on environment config before first client demo. Exclude: They just want to learn and will troubleshoot themselves.

Cloud Billing: Bill rising, owner must explain spend and find savings before budget review. Exclude: Increase driven by business growth, little room to cut.

AI Code Changes: Team uses AI but verification and rework slow merges. Exclude: Real bottleneck is changing requirements; more testing won't fix it.

Each direction relates to your tech, but the bought outcomes differ: on-time launch, explained/improved spend, reduced verification cost for specific changes. They cannot be uniformly packaged as "technical empowerment."

Beyond personal experience, clues appear in community help requests, negative tool reviews, job postings, and teams' temporary scripts. However, a clue only finds interview candidates; evidence must come from the actual scene. Hiring shows willingness to fund a role, not to outsource a task; complaints don't equal budget. Pick one direction, list a few reachable prospects. If you cannot name who has the problem or where to find them, fix the access path first — adding features won't close that gap.

3. Problem, Willingness to Buy, and Profitability Are Three Separate Judgments

A developer losing two days to deployment has a clear problem, but may treat it as learning, lack budget, or refuse to give a stranger production access. Rising cloud bills may annoy engineers but not trigger the budget owner's urgency. AI rework frustrates users, yet policy may restrict vendors to an approved list.

Therefore, demand discovery must continuously verify: what consequences the problem causes, whether it ranks in near-term priorities, who bears the cost, where budget comes from, why the customer would trust you, and what extra adoption costs exist.

Discovering the problem, getting purchase commitment, delivering, and retaining margin each require distinct evidence. Trust must address concrete fears: read-only diagnosis plus approved execution for production safety; written acceptance criteria for usability concerns; handover docs and support windows for continuity risk. Case studies help but cannot replace explicit delivery terms.

Enterprise buyers involve multiple roles: users describe pain, tech leads assess feasibility, budget owners approve spend. Sometimes one person wears all hats; sometimes procurement adds steps. Do not infer company purchase from one engineer's enthusiasm. Ask: "If we pilot, who approves? What materials are needed? Which budget pays? When can a decision happen?" For solo ventures, shorter purchase paths accelerate learning, but small teams may lack budget while large ones may have earmarked pilot funds.

4. Interview: First Reconstruct the Past, Then Discuss Next Steps

"Would you buy if I built this tool?" yields polite yeses without real commitment. Instead, ask the prospect to recount a recent episode:

When did you last hit this problem? What task were you completing?

What steps did you take from discovery to resolution? Can you share sanitized records?

Who was involved? How much time did it cost? What downstream work was impacted?

What alternatives did you try? Why did you settle on the current approach?

Have you bought tools, hired externals, or requested budget for this?

When might it recur? If the approach changed, whose agreement is needed?

If they say "deployment is annoying," drill down: build failures, missing config, or post-release uncertainty? Each maps to a different delivery. If they say "AI makes random changes," ask for the last rework: what broke, when detected, who verified, what evidence allowed merge. Let the interview disprove your hypotheses.

Time already spent, existing bills, delayed tasks are stronger signals than "I really need this." Yet existing spend isn't a direct pricing anchor: the customer may be happy with the current vendor or face high switching costs.

After the interview, organize notes into four buckets: observed facts, current alternatives, unvalidated assumptions, agreed next steps. Separate "customer said interesting" from "customer agreed to bring decision-maker for pricing talk." A few interviews refine hypotheses; they cannot project market purchase rates. Actively seek those who self-solve, rejected pilots, or switched away to learn why they didn't buy.

5. Your Competitors Include "Making Do"

No existing purchase doesn't mean no competition. The customer may be handling it internally, asking a colleague, using free tools, or tolerating the problem. You must compare against these real options.

Example: A team spends one day monthly reconciling cloud bills, but the lead thinks a day is acceptable. A full-featured platform may still lose because onboarding, authorization, and learning costs exceed the perceived gain. Another team faces imminent budget review and must explain spend spikes; a scoped, auditable diagnostic report may be more compelling. Purchase drivers include task deadline, existing capabilities, and responsibility allocation — not just technical sophistication.

Scenarios with high value and low adoption resistance suit early pilots; high value but high resistance require unpacking procurement, trust, and integration barriers first.

When comparing, don't equate "saves one engineer-day" to "one day's salary in cash." Fixed salaries may not drop, and freed time may not shift to high-value work. Verify what capacity is actually released and whether the stakeholder recognizes the improvement.

6. Turn the Pilot into a Purchasable Deliverable

When several people in similar scenes describe real problems, propose a small-scale pilot. Small scope must reflect in a customer-understandable deliverable. Don't promise a universal platform upfront; agree on required inputs, work to be done, evidence delivered, and exit criteria if conditions aren't met.

For cloud bill diagnosis, a sample proposal:

For one cloud account, within an agreed period, using client-provided bills and read-only resource data, deliver spend-change explanations, candidate optimizations, and the rationale and risk for each. Client accepts report against agreed scope; actual changes are separately approved and priced.

The proposal must also specify fee, payment milestones, data readiness, support window, and liability boundaries. Implementation requires resource-owner confirmation of purpose and change conditions; low utilization alone cannot justify deletion.

Deployment scenes can sell "one-time scoped launch assistance": resolve agreed environment issues, complete access checks, deliver operation and rollback notes. AI-change scenes can sell "verification workflow for a class of changes": build necessary checks around a real repo, observe if rework drops within the agreed scope. Passing tests cannot be marketed as "all changes are correct."

The article cites Paul Graham's "Do Things that Don't Scale" — early manual service to learn customer tasks before automating. It further recommends using bounded paid pilots to validate purchase, noting this doesn't guarantee consulting converts to software product; professional services can be a valid business. If productization is the goal, separately verify which steps are reusable.

Payment or deposit is stronger evidence than verbal agreement, but examine terms: friendship discounts, below-sustainable pricing, and one-off emergencies may not replicate. When a company cannot pay yet, a concrete pilot schedule, budget approval steps, and formal procurement process still carry information — just don't book them as realized revenue.

7. After the First Sale, Check If It's Worth Continuing

One sale only proves this customer accepted this deal under these conditions. Next, verify whether you can find similar customers at acceptable cost and deliver repeatedly.

Run a simple operating calculation: revenue minus direct costs = remainder. Total hours invested (discovery, sales, onboarding, rework, handover, support) divided into remainder gives an hourly rate. Example: 3,000 CNY revenue, 300 CNY direct cost, 18 hours invested → 2,700 CNY remainder, 150 CNY/hour. This is a single-case arithmetic, not a market rate or net profit.

Omitting pre-sales and post-sales time easily mistakes revenue for gain. Even with a surplus, confirm the work pattern fits your income goals and available time.

Retrospective questions: Did the customer accept the outcome? Will they repurchase next cycle? Can you find similar buyers without personal connections? Which steps repeat, which require fresh business understanding?

Deployment rescue may be low-frequency, unsuited for subscription but viable as one-off service. Cloud bill reviews may recur but diminish after optimization. AI verification may be frequent, yet repo differences affect standardization. Pricing model should follow task frequency and delivery structure.

If multiple deliveries rely heavily on customization, you can continue as a professional service or narrow the service boundary. Only when reusable steps and stable purchasing appear is there grounds to build a tool for part of the flow.

8. Set Clear Stop Conditions for the Next Validation Round

Demand discovery can become endless research: reading articles, collecting ideas, still unsure who to contact. Time-box an exploration cycle: e.g., one week to list familiar scenes, conduct a few interviews, and propose a pilot to qualified prospects. This is a work-planning example; complex enterprise sales need longer — don't treat the deadline as a validity test.

Before starting, write down what evidence means "continue" and what means "revise hypothesis."

If the problem recurs recently with clear consequences and the customer discusses pricing/procurement → validate further.

If everyone sees value but no budget or near-term task emerges → revisit audience and trigger scene.

If someone pays but every delivery exceeds scope → adjust service boundaries and price.

If you cannot reach similar buyers → fix the acquisition path first.

Record rejection reasons: no budget, insufficient trust, integration too heavy, problem not important — each points to a different next step. One rejection doesn't invalidate demand; repeated same reason cannot be ignored by adding features.

Technical founders can act today: write down one familiar, recently occurred problem, find someone who lived it, ask them to replay the last handling. Then complete this sentence:

I serve which customer type, in what trigger scenario, delivering what verifiable outcome; who buys for what reason, and at what cost can I deliver?

The parts still blank are the hypotheses for the next validation round.