A founder can spend weeks validating whether an AI model works and still have no evidence that anyone needs the product.

That is the central problem with AI startup validation today.

AI has dramatically reduced the cost of building prototypes. However, it has not reduced the difficulty of finding a painful problem, identifying the right buyer, proving demand and creating a commercially viable business.

At TICTECH, we look at this differently.

Before deciding whether an AI idea deserves an MVP, founders need to establish whether the underlying problem is real, recurring and commercially meaningful. Our AI startup problem validation framework looks at the evidence behind the problem before significant product investment begins.

This guide presents the TICTECH Validation Stack: a practical framework for deciding whether an AI startup idea deserves an MVP, a manual experiment, a pilot—or a rethink.

The real question is not “Is this a good AI idea?”

It is:

“What evidence would have to exist for me to confidently invest the next 3–6 months building this?”

That distinction matters.

A founder may have:

✔︎ an impressive AI capability;
✔︎ a technically feasible prototype;
✔︎ a large potential market;
✔︎ positive comments from potential users;
✔︎ a strong personal belief in the idea.

None of these independently prove commercial demand.

Customer discovery exists to test the assumptions behind the business model. Steve Blank’s customer-development work makes an important distinction between discovering customer problems and validating whether enough customers will actually adopt and pay for a solution. (Steve Blank)

Therefore, the objective is not to collect compliments.

The objective is to collect evidence that changes your confidence.

The TICTECH Validation Stack

We use five evidence layers:

1. Problem evidence: Is the problem real?

2. Workflow evidence: How is the problem handled today?

3. Buyer evidence: Who actually cares enough to act?

4. Value evidence: Can the improvement be measured?

5. Commitment evidence: Will someone take a meaningful next step?

🎯 Only after these layers become sufficiently strong should the founder decide what to build.

This is important because different evidence carries different commercial weight.

For example:

“That sounds useful.” → is weak evidence.

“We currently spend 10 hours a week doing this manually.” → is stronger.

“Can we test this with our team?” → is stronger again.

“If the pilot delivers the agreed outcome, we’d like to discuss a paid deployment” is substantially stronger.

The goal is therefore not simply to increase the number of interviews → The goal is to increase the strength of evidence.

1. Start With the Problem, Not With the AI

The first mistake is usually framing the opportunity around technology.

For example: “We are building an AI agent that automatically analyses customer conversations.”

That describes a technology.

It does not yet describe a validated business problem.

Instead ask: “What happens today when a company needs to understand customer conversations?”

Now the investigation becomes different. → You may discover that teams:

✔︎ Manually review calls;	✔︎ Copy information into spreadsheets;
✔︎ Miss important customer signals;	✔︎ Spend hours preparing reports;
✔︎ Use several disconnected tools;	✔︎ Lack visibility across customer accounts;
✔︎ Discover problems only after customers complain.

Now you have something you can investigate. → The AI may eventually be the answer. → But the workflow is where the commercial opportunity starts.

Steve Blank similarly warns against turning customer discovery into feature collection. The purpose is to test whether the problem and proposed solution actually matter to customers. (Steve Blank)

2. Map the Existing Workflow

This is where customer discovery becomes much more useful.

Don’t begin by showing your prototype. First understand the customer’s current process.

Ask:

“Walk me through what happens today.”

Then document:

Trigger → Action → Tool → Person → Time → Problem → Consequence

For example:

Stage	Question
Trigger	What causes this work to start?
Action	What does someone actually do?
Tool	Which systems are involved?
Person	Who performs the work?
Time	How long does it take?
Problem	Where does the process break?
Consequence	What happens when it goes wrong?

This reveals something founders often miss.

The customer’s real problem may be somewhere different from where the founder initially assumed.

You may think the problem is reporting. The customer may reveal that the real problem is data collection. You may think the problem is automation. The customer may reveal that the real problem is approvals. You may think the problem is lack of intelligence. The customer may reveal that the real problem is that nobody trusts the existing data.

That is why workflow discovery comes before solution validation.

The visible problem is not always the most valuable problem to solve. Sometimes the real opportunity sits one layer deeper, inside the operational constraint preventing the customer from achieving the desired outcome. This is where the Hidden Constraint Framework becomes useful.

3. Find the Cost of the Problem

Not every problem deserves a startup.

Some problems are annoying. Some are expensive. Some are dangerous. Some are frequent enough that people actively look for solutions.

Those are very different situations.

A useful question is: “What happens if you don’t solve this?”

Then explore the consequence. Does the problem create:

✔︎ Wasted employee time?	✔︎ Lost revenue?
✔︎ Compliance exposure?	✔︎ Customer churn?
✔︎ Operational delays?	✔︎ Missed opportunities?
✔︎ Poor service quality?	✔︎ Unnecessary hiring?
✔︎ Management overhead?	✔︎ Reputational risk?

The stronger the consequence, the more interesting the problem becomes.

But don’t assume the cost.

Ask the customer to describe it.

For example:

✔︎ How often does this happen?	✔︎ How much time does your team spend dealing with it?
✔︎ What happens when the process fails?	✔︎ Who feels the impact most?
✔︎ Has this caused a financial or operational problem?

These questions turn a vague pain point into something that can potentially be measured.

4. Look for Existing Workarounds

One of the strongest signals in customer discovery is not what customers say they want.

It is what they are already doing to compensate for the problem.

Look for:

✔︎ spreadsheets; manual processes; internal tools;
✔︎ consultants; additional employees; WhatsApp groups;
✔︎ email chains; duplicated data entry; complicated workarounds;
✔︎ multiple SaaS subscriptions; scripts;
✔︎ outsourced services.

A workaround demonstrates behaviour. That matters.

Suppose someone tells you: “We really need an AI tool for this.”

That is interesting. But suppose they tell you:

“We have one employee spending two days every month manually combining data from four systems.”

Now you have evidence of an existing cost. And that creates a much stronger validation opportunity.

5. Ask “What Have You Already Tried?”

This is one of the most valuable questions a founder can ask.

“What have you already tried to solve this?”

The answer can reveal:

✔︎ competing products; failed implementations; internal solutions;
✔︎ budget; urgency; switching barriers;
✔︎ procurement requirements; technical constraints.

It can also destroy a weak startup idea early.

Imagine you discover that customers have already tried five products and abandoned every one because the workflow requires human judgement.

That is not necessarily bad news. It may reveal the actual opportunity.

Perhaps the winning product is not: “AI completely automates the process.”

Perhaps it is: “AI handles the repetitive 70%, while humans control the critical 30%.”

🎯 Customer discovery should therefore change the product hypothesis.

6. Identify the User, Buyer and Economic Buyer

“Customer” is often too vague. An AI startup may have several different stakeholders.

For example:

User: employee using the platform.

Champion: person who wants the problem solved.

Buyer: person responsible for purchasing.

Economic buyer: person responsible for the budget.

Decision-maker: person who approves deployment.

Gatekeeper: person controlling procurement, security or compliance.

These people may not be the same. That matters enormously for B2B AI startups.

A product can have enthusiastic users but no budget owner. Conversely, a buyer may love the business case while users dislike the workflow.

You need to understand the entire buying system.

Early customer discovery can also become the foundation for founder-led growth, because the conversations that reveal customer pain can eventually shape positioning, messaging and acquisition.

7. Validate Buyer Demand Separately From User Interest

This is where many AI startups get stuck. The founder interviews 30 users.

Everyone likes the concept. The founder concludes:

“We have product-market fit.”

Not necessarily. You may have user interest. You do not necessarily have buyer demand.

Ask:

✔︎ Who would normally pay for this?	✔︎ What budget would this come from?
✔︎ Who would need to approve it?	✔︎ What would prevent you from purchasing it?
✔︎ What would make this important enough to implement?

And eventually:

“If the pilot demonstrated the agreed outcome, what would the next commercial step look like?”

This moves the conversation from hypothetical enthusiasm toward buying behaviour.

Steve Blank has repeatedly emphasized that customer validation must test whether customers will actually buy, rather than simply whether they will talk to the founder or express interest. (Steve Blank)

8. Build a Buyer-Demand Evidence Ladder

At TICTECH, I would classify demand into five levels.

Level 1 — Awareness

The customer recognises the problem.

Evidence: “Yes, we have this problem.” → Useful, but weak.

Level 2 — Pain

The customer describes a recurring consequence.

Evidence: “This happens every week and takes our team several hours.” → Stronger.

Level 3 — Existing Spend

The customer already spends money, time or resources addressing it.

Evidence: “We currently pay an external provider.” → Much stronger.

Level 4 — Action

The customer agrees to do something meaningful.

Examples:

✔︎ introduction to the decision-maker; pilot; data-sharing discussion;
✔︎ technical evaluation; workflow assessment; trial;
✔︎ letter of intent; procurement discussion.

Now the evidence becomes commercially interesting.

Level 5 — Commercial Commitment

The customer is willing to pay or formally move toward purchasing.

This is the strongest evidence before scale.

The important point is simple:

Don’t count all conversations equally.

Ten “sounds interesting” conversations should not outweigh one serious pilot conversation.

9. Test the AI Advantage

Only after understanding the problem should you ask:

“Why does this need AI?”

This is an underrated question.

An AI startup should not exist simply because AI can perform the task.

Ask whether AI creates a meaningful improvement.

For example:

Before

A team spends 12 hours reviewing documents.

After

AI reduces the review workload to three hours while maintaining acceptable accuracy.

That is meaningful.

But:

“AI makes the dashboard smarter.” → is much harder to commercialise.

The AI should ideally improve an outcome such as:

✔︎ time; pilot; cost; accuracy;
✔︎ response speed; capacity; revenue;
✔︎ customer experience; risk detection; decision quality.

This connects technical capability to commercial value.

10. Create a Value Hypothesis

Before building an MVP, write one sentence:

“For [buyer], Startup/product X reduces [problem] by improving [measurable outcome].”

For example:

“For care agencies, the platform reduces manual care-monitoring work by making routine, mood and behavioural information easier to capture and review.”

That is much stronger than:

“We are building an AI-powered care platform.”

The first statement can be tested. The second is primarily positioning.

11. Turn the Value Hypothesis Into a Test

Now define what success would look like.

For example:

Hypothesis

Care coordinators spend too much time manually collecting and reviewing daily information.

Expected outcome

Reduce administrative review time by 30%.

Test

Run a 30-day pilot with five agencies.

Evidence

Measure:

✔︎ usage frequency; time spent; workflow completion;
✔︎ adoption; caregiver feedback; coordinator feedback;
✔︎ retention; willingness to continue.

This is the point where an MVP becomes useful. You are no longer building because the idea feels exciting.

🎯 Founder signal: You are building because you have a hypothesis worth testing.

12. Don’t Always Build the MVP First

This is one of the biggest opportunities created by modern AI.

You can often test demand manually. Suppose you want to build an AI research platform. You don’t necessarily need to build:

❌ an AI agent;
❌ an automated dashboard;
❌ a complex database;
❌ an API;
❌ a recommendation engine.

You might initially:

✔︎ interview the target customer;
✔︎ collect their inputs manually;
✔︎ process them using existing tools;
✔︎ deliver the result manually;
✔︎ observe whether they use it;
✔︎ ask whether they would pay for it.

This is sometimes called a concierge approach. The point isn’t to pretend the manual system is the final product. The point is to test whether the outcome is valuable before automating the machinery behind it.

YC’s startup guidance similarly emphasizes learning from actual users and understanding whether users return, rather than assuming growth or acquisition alone proves product value. (Y Combinator)

13. Use the Smallest Possible Validation Experiment

Before writing a large product specification, ask:

“What is the smallest experiment that could prove or disprove this assumption?”

Examples:

Assumption	Smallest test
Customers have the problem	15 targeted interviews
Problem is frequent	Workflow diary
Customers already spend money	Existing-solution research
Buyers care	Buyer interviews
Solution creates value	Concierge pilot
Customers will adopt	Controlled trial
Customers will pay	Paid pilot
Business can scale	Repeatable acquisition experiment

This is where founders can save months.

14. Create a Validation Kill List

Validation is not only about proving your idea.

It is also about finding reasons to stop.

Before beginning research, write down your kill criteria.

For example: Stop if fewer than 20% of target customers experience the problem frequently.

Or:

Reposition if users experience the problem but do not consider it important.

Or:

Change the buyer if users value the solution but have no purchasing authority.

Or:

Stop building if customers cannot identify a measurable outcome.

This creates discipline.

Otherwise, founders tend to reinterpret every negative signal as a reason to continue.

15. Build a TICTECH Validation Score

This is the part I would make distinctly TICTECH-owned rather than another generic startup checklist.

Score each category from 0–5.

Validation dimension	0	5
Problem	Hypothetical	Repeated, painful problem
Frequency	Rare	Frequent
Existing workaround	None	Significant manual/spend workaround
Buyer clarity	Unknown	Clearly identified
Economic impact	Unknown	Quantified
Existing alternatives	Unknown	Clearly understood
AI advantage	Unclear	Measurable improvement
User commitment	Interest	Pilot/adoption
Buyer commitment	None	Commercial discussion
Retention potential	Unknown	Repeated workflow

Maximum score: 30

I would interpret it as:

0–15 — Customer Discovery

Pause major investment; return to problem and buyer interviews.

16–27 — Problem signal and Validation opportunity

Test demand, pricing, and adoption barriers.

28–34 — MVP/Pilot readiness

The commercial case is becoming credible.

35–40 — Strong validation signal

The founder has meaningful evidence across problem, buyer, value and commitment. The score is not a prediction of startup success. It is a measure of how much market evidence you have accumulated.

The important part is that the founder can see where the evidence is weak.

To unlock the complete TICTECH Market Validation Checklist, jump straight to it here.

16. Separate Market Validation From Commercial Readiness

This distinction is critical.

A market can want something without creating a viable business.

For example:

100 people say they like the product. That demonstrates interest. But perhaps:

✔︎ acquisition costs are too high;
✔︎ the buyer is difficult to reach;
✔︎ implementation takes months;
✔︎ margins are poor;
✔︎ customers require extensive customisation;
✔︎ retention is weak.

Therefore, TICTECH’s validation process should move through three commercial questions.

Market validation

✔︎ Does the problem exist?

Buyer-demand research

✔︎ Will the right buyer act?

Commercial readiness

✔︎ Can this become a repeatable business?

That is where TICTECH can differentiate itself from generic startup coaching. The objective isn’t simply to tell founders whether an idea sounds good. It is to reduce the uncertainty between idea and commercial decision.

More AI investment does not automatically translate into more business value. TICTECH’s analysis of the AI spending paradox examines why technology investment can increase while measurable business outcomes remain limited.

17. What “Good Validation” Actually Looks Like

A founder should eventually be able to say something like:

“We interviewed 38 people across our target segment.”

→ “27 experience the problem at least weekly.”

→ “19 currently use manual or paid alternatives.”

→ “12 identified measurable operational consequences.”

→ “7 agreed to a pilot.”

→ “4 completed the pilot.”

→ “3 want to continue.”

🎯 And finally: “2 are willing to pay under the proposed commercial model.”

That is a completely different story from: “We interviewed 40 people and everyone loved the idea.” The first contains evidence progression. The second contains enthusiasm.

18. What to Measure During the Pilot

Once you have moved beyond discovery, don’t measure only downloads. Measure behaviour. For an AI SaaS product, useful signals can include:

Activation

How many users complete the core workflow?

Frequency

How often do they use the product?

Time-to-value

How quickly do they experience the promised benefit?

Retention

Do they continue using it?

Outcome

Did the workflow actually improve?

Expansion

Would they introduce another team, department or customer?

Referral

Would they recommend it?

Commercial intent

Would they pay to continue?

YC’s current interview guidance explicitly focuses on questions such as where users come from, how much they use the product, whether they stick around, what makes them try it and why reluctant users hold back. (Y Combinator)

That is a useful reminder:

🎯 Founder signal: Usage behaviour is often more informative than stated enthusiasm.

19. The Evidence Should Change What You Build

Customer discovery is wasted if research goes into one folder and product development continues unchanged.

Every interview should potentially change one of five things:

Problem: Maybe the problem is different.

Customer: Maybe the user isn’t the buyer.

Workflow: Maybe the product should fit into an existing system.

Value proposition: Maybe the real benefit isn’t what you expected.

Product: Maybe the minimum feature set needs to change.

This is why customer discovery and product development should operate as a loop.

Research → hypothesis → experiment → evidence → decision → iteration.

Steve Blank describes customer development in similar terms: startups test business-model hypotheses outside the building, then iterate based on what they learn. (Steve Blank)

20. When Should You Actually Build the MVP?

I would not use a fixed number such as:

“Interview 30 people and then build.”

Thirty interviews can be useless.

Ten interviews can be transformative.

The better question is:

“Have we reduced the most dangerous commercial uncertainties enough to justify building?”

You are closer to MVP readiness when you understand:

✔︎ Who has the problem;	✔︎ How often it occurs;
✔︎ Why it matters;	✔︎ How it is handled today;
✔︎ Who uses the solution;	✔︎ Who buys it;
✔︎ What alternatives exist;	✔︎ What measurable improvement you promise;
✔︎ Why AI is useful;	✔︎ What evidence would prove the product works.

At that point, the MVP has a job.

It is not supposed to prove that the founder was right. It is supposed to test the next important assumption.

The TICTECH Commercial Validation Loop

This is the framework I would make central to the TICTECH article.

1. Discover

Find the real problem.

↓

2. Map

Understand the existing workflow.

↓

3. Quantify

Measure frequency, cost, time and consequence.

↓

4. Identify

Find the user, champion and buyer.

↓

5. Test

Run the smallest experiment.

↓

6. Measure

Capture behavioural and commercial evidence.

↓

7. Decide

Build, modify, pilot or stop.

↓

8. Commercialise

Test whether the model can become repeatable. This final step is important. Validation does not end when somebody uses the product. It ends when the founder understands enough about the customer, buyer, value and commercial mechanism to make a confident next decision.

What Founders Should Have Before Building

Before committing significant engineering resources, I recommend creating a one-page Validation Evidence Sheet.

It should answer:

Problem

What problem are we solving?

Customer

Who experiences it?

Buyer

Who pays?

Workflow

How is it handled today?

Pain

What happens if nothing changes?

Existing solution

What alternatives already exist?

AI advantage

Why does AI materially improve the workflow?

Value

What measurable outcome should improve?

Evidence

What have customers actually said or done?

Commitment

What are customers willing to do next?

Risk

What remains unvalidated?

Next experiment

What is the cheapest experiment that reduces that risk?

If several of these fields are still assumptions, the startup probably isn’t ready for a large MVP.

The Difference Between a Prototype and a Business

This distinction deserves emphasis.

A prototype answers: “Can we build it?”

An MVP should answer: “Can users get value from it?”

A pilot should answer: “Does it work in the customer’s environment?”

Commercial validation should answer: “Will the right customers repeatedly pay for it?”

Those are four different questions. Confusing them is expensive.

A technically impressive prototype can therefore be commercially meaningless.

Conversely, a very simple MVP can become extremely valuable if it proves an important customer and buyer hypothesis.

What TICTECH Looks For Before Recommending “Build”

At TICTECH, the objective of market validation is not to give founders a green light because an idea sounds exciting.

The objective is to identify where the commercial uncertainty still lives.

Sometimes the answer is:

Build the MVP.

Sometimes it is:

Change the target customer.

Sometimes:

Validate the buyer first.

Sometimes:

Test the workflow manually.

Sometimes:

Change the value proposition.

And sometimes:

Don’t build this.

That last answer can be extremely valuable.

🎯 A founder who avoids spending six months building a product nobody needs has not failed. They have bought back six months of their life.

From Customer Discovery to Commercial Readiness

This is where the TICTECH approach extends beyond traditional startup validation.

Our work can be thought of as three connected layers.

Market Validation

We investigate whether the problem exists and whether the target market experiences it strongly enough to justify a solution.

Buyer-Demand Research

We identify who buys, what influences the decision, what alternatives exist and what evidence would cause a buyer to act.

Commercial Readiness

We assess whether the product, value proposition, pricing logic, acquisition path and customer evidence are strong enough to support the next stage of growth.

The result is not simply a research report. It is a decision framework. The founder should finish knowing:

✔︎ What do we know?	✔︎ What do we not know?
✔︎ What evidence do we need next?	✔︎ What should we build?
✔︎ What should we not build yet?	✔︎ What would make a customer pay?

That is the difference between research and commercial intelligence.

A Practical 30-Day AI Startup Validation Sprint

For founders who want a practical starting point, I would structure the first month like this.

Days 1–5: Define the hypothesis

Document:

→ target customer;
→ problem;
→ workflow;
→ buyer;
→ value hypothesis;
→ AI advantage;
→ Biggest commercial risks.

Do not build yet.

Days 6–12: Customer discovery

→ Conduct targeted conversations.
→ Prioritise people who actually experience the workflow.
→ Do not spend the entire conversation pitching the product.

The objective is to understand reality.

Days 13–17: Analyse the evidence

Group findings into:

→ recurring problems;
→ high-intensity problems;
→ existing workarounds;
→ buyer signals;
→ objections;
→ unexpected use cases.

Then update the hypothesis.

Days 18–22: Run a low-cost experiment

Depending on the business, this could be:

→ concierge service;
→ landing page;
→ manual workflow;
→ clickable prototype;
→ limited beta;
→ design-partner programme;
→ paid pilot.

The experiment should test the most dangerous assumption.

Days 23–27: Test commercial intent

Ask:

✔︎ Would they continue?	✔︎ Who would approve it?
✔︎ What outcome matters?	✔︎ What would prevent adoption?
✔︎ What would a reasonable next step be?

Where appropriate, test pricing or a paid pilot.

Days 28–30: Make the decision

Choose one:

Build

Evidence is strong enough.

Modify

The problem is real, but the solution or buyer needs changing.

Continue discovery

Important commercial assumptions remain unresolved.

Stop

The evidence does not justify further investment.

This final decision is the point of the process.

The Founder Validation Checklist

Before building an AI MVP, ask:

Problem

• Is the problem real?
• Is it recurring?
• Is it painful?

Workflow

• How is it handled today?
• What tools are involved?
• What workarounds exist?

Buyer

• Who uses it?
• Who champions it?
• Who pays?
• Who approves it?

Economics

• What does the problem cost?
• What outcome could improve?
• Is there an existing budget?

Competition

• What alternatives exist?
• Why are they insufficient?
• Why would customers switch?

AI

• Does AI create a meaningful advantage?
• Could the problem be solved without AI?
• What specifically improves?

Evidence

• What have customers actually done?
• Have they agreed to a pilot?
• Have they provided data?
• Have they introduced the decision-maker?
• Have they discussed payment?

Commercial readiness

• Can the value be measured?
• Can customers be acquired?
• Can they be retained?
• Can the model eventually become repeatable?

🎯 Founder signal: If most answers are still assumptions, you probably need more validation before more engineering.

The Biggest Mindset Shift for AI Founders

The old startup question was often:

“Can we build this?”

AI increasingly makes that question easier.

The more important question becomes:

“Can we find enough evidence that this deserves to be built?”

That changes the founder’s behaviour.

Instead of spending the first month polishing an interface, you might spend it observing workflows.

Instead of collecting feature requests, you investigate existing workarounds.

Instead of asking whether people like the idea, you look for behavioural commitment.

Instead of measuring downloads, you measure whether the product changes something important.

And instead of treating customer discovery as a marketing activity, you treat it as commercial risk reduction.

That is the shift TICTECH believes matters.

Once founders have evidence around the problem, buyer, workflow, usage and commercial demand, the question changes from “Is this idea worth building?” to “Is this company ready to scale?” That is where AI startup fundraising readiness becomes relevant.

The TICTECH Principle

Don’t validate whether people like your AI idea.

Validate whether:

the problem exists → the workflow is costly → the buyer cares → the outcome matters → the solution creates measurable value → and someone is willing to take the next commercial step.

Only then should you increase the engineering investment. Because the objective isn’t to build an AI product faster. It is to become more certain that you’re building the right one.

It is to become more certain that you’re building the right one.

How TICTECH Can Help

If you are an AI founder with an idea, prototype or early product, TICTECH can support the commercial journey through:

Market Validation

Research the target market, problem, customer segments, competitors and opportunity signals.

Buyer-Demand Research

Identify the actual buyer, purchasing triggers, existing alternatives, unmet needs and evidence of willingness to act.

Commercial Readiness

Assess whether your product, positioning, value proposition, pilot evidence and commercial model are ready for the next stage.

The outcome should be more than a document.

You should leave with clearer evidence about what to build, who to build it for and what needs to happen before you scale.

Frequently Asked Questions

How do I validate an AI startup idea before building an MVP?

Start by validating the customer problem rather than the technology. Interview people who experience the workflow, understand how they solve it today, identify the buyer and quantify the consequence. Then run the smallest experiment capable of testing your most important assumption.

How many customer interviews should an AI startup conduct?

There is no universal number. The goal is not to hit an arbitrary interview target. Continue until recurring patterns emerge and your most important commercial assumptions have enough evidence to support a decision.

Should I build a prototype before talking to customers?

Usually, no. Start with customer discovery when the biggest uncertainty is market or customer demand. A prototype becomes more useful when you already understand the problem and need to test a specific solution hypothesis.

How do I know whether customers actually want my AI product?

Look for behaviour rather than compliments. Stronger signals include sharing data, requesting a pilot, introducing a decision-maker, agreeing to test the workflow, continuing to use the product and discussing payment.

How do I validate willingness to pay?

First understand the customer’s existing spending, internal resources and consequences of the problem. Then test a commercial offer, pilot or pricing conversation with the actual buyer rather than relying only on survey responses.

What is the difference between customer discovery and commercial validation?

Customer discovery investigates the problem, customer and workflow. Commercial validation goes further by testing whether the right buyer will adopt, pay and potentially repeat the purchasing behaviour.

Does every AI startup need an MVP?

No. Some ideas can be tested through interviews, concierge services, manual delivery, prototypes, landing pages or design-partner pilots before significant engineering investment.