If your product risk is high, the problem may be real.
But your solution may not yet be the right one.
Before adding features, validate whether users understand, use, and value the core solution enough to change their behaviour.
A common early-stage trap looks productive from the outside: the team keeps shipping.
New features appear. The roadmap gets longer. The demo improves. Everyone is busy.
But the uncomfortable question remains:
Are you building something customers actually need or just making the wrong solution more impressive?
This is the essence of Product Risk.
It does not necessarily mean your idea is weak.
It means your solution has not yet earned the right to become more complex.
For early-stage tech startups, product validation is about finding evidence that the solution helps a specific customer make progress on a real problem. The Lean Startup approach describes the minimum viable product (MVP) as a way to begin learning as quickly as possible through the build-measure-learn loop, not as a smaller version of the final product.[1, 2]
An MVP is not necessarily something you “build” in code.
It is the fastest way to test critical assumptions with the least effort.
That distinction matters.
Many founders use MVPs to start building.
Better founders use MVPs to start learning.
Start with the riskiest product assumption
Before building anything else, ask:
What must be true for this solution to work?
Examples:
- Customers understand the value proposition.
- The workflow fits into how they already work.
- The user can reach the desired outcome without heavy support.
- The buyer sees enough value to pay.
- The technical performance is good enough for the use case.
Do not test everything at once.
Choose the assumption that would most seriously damage the business if it were false.
For example, if you are building AI software for clinical documentation, the riskiest assumption may not be whether the model can generate summaries. It may be whether doctors trust the output enough to use it, whether hospitals allow the workflow, or whether the time saved justifies procurement effort.
Test the core value, not the full product
Founders often postpone validation until the product is “ready”.
However, this is often expensive procrastination wearing a lab coat.
The better question is:
What is the smallest test that can reveal whether customers value the solution?
Possible tests include:
- a clickable prototype,
- a landing page with a clear call to action,
- a concierge test where the team manually delivers the result,
- a pilot with a narrow use case,
- a workflow simulation,
- a paid discovery or implementation project.
Even lightweight coded MVPs require support, bug fixes, and infrastructure. Hence validating the value proposition before committing to code is a good idea.[3]
Watch what users do, not what they praise
Positive feedback is useful only when it is connected to behaviour.
“Looks great.” “This could be useful.” or “I can imagine using this.” are weak signals. You should not count on them.
Stronger signals:
- The user completes the task in the prototype.
- The user asks for access to try it with real data.
- The buyer introduces the team to procurement or IT.
- The customer agrees to a pilot with clear success criteria.
- The customer pays, even a small amount.
User research should not be reduced to a yes/no validation exercise. When research is used only to confirm an existing decision, teams may miss the nuance that makes the research valuable.[4]
The real goal is to understand what creates value, what creates friction, and what must change before adoption becomes realistic.
Define success before the test
Before you run a test, define what evidence would make you continue, change direction, or stop.
For example:
- At least 5 out of 8 target users complete the core workflow without help.
- Three qualified customers agree to a pilot.
- One customer pays for a limited implementation.
- Users repeatedly return to the product without reminders.
Avoid vague goals such as “get feedback” or “see if they like it”.
Look for real evidence.
Do not mistake feature requests for validation
Feature requests feel exciting because they sound like demand.
But they can also be a polite way for customers to postpone commitment.
When someone asks for a feature, ask:
- What would this allow you to do?
- How do you solve this today?
- How often does this matter?
- Who else needs this?
- Would this change your decision to use or buy?
- What would happen if this feature did not exist?
A feature request is only a roadmap item when it is connected to a valuable use case, repeated across relevant customers, and aligned with your strategic focus.
Conclusion
Product validation is not about building less.
It is about learning faster based on evidence.
If your biggest risk is the product, do not build more yet.
Test whether the core solution creates value, whether users can adopt it, and whether customers are willing to make a real commitment.
A product becomes stronger when every important feature has earned its place.
If you are building a tech-driven startup and want structured support with validation, product-market fit, and growth, explore the INiTS SCALEup Incubation Program.
Explore INiTS SCALEup → https://www.inits.at/en/scaleup/?src=wp
The Big Takeaways
Test the riskiest product assumption first.
Do not validate the easy parts while ignoring the adoption risk.
Use prototypes and pilots to learn before you build.
The goal of an MVP is learning, not feature delivery.
Treat behaviour as stronger evidence than praise.
Usage, payment, data access, and pilots matter more than compliments.
Sources
[1] Eric Ries / The Lean Startup — Methodology Principles — https://theleanstartup.com/principles
[2] Strategyzer — Don’t Build When You Build-Measure-Learn — https://www.strategyzer.com/library/dont-build-when-you-build-measure-learn
[3] Nielsen Norman Group — Minimum Viable Product: Definition — https://www.nngroup.com/articles/mvp-definition/
[4] Nielsen Norman Group — In User Research, Don’t Stop at “Yes” or “No” — https://www.nngroup.com/articles/research-yes-or-no/