Your MVP does not have to be an app
A lot of founders define an MVP as the smaller version of the software they eventually want to build.
Fewer features. Rougher design. Basic onboarding.
But that is still a product scope decision. It does not tell you whether software is the smallest useful test.
If the riskiest assumption is whether someone will change their behavior, trust the result, or pay for the outcome, building a dashboard may not be the minimum way to test it.
A marketplace can begin with you manually matching five buyers and sellers.
An AI research tool can begin as a report you produce with existing tools and deliver to a few users.
A workflow product can begin with a form, a spreadsheet, and you doing the work behind the scenes.
An automation product can begin in shadow mode, producing an output that a human reviews before it affects the real process.
The manual version is not an excuse to deliver fake value. It still needs to complete the outcome the customer cares about. The difference is that you postpone automation until you have evidence about what should be automated.
The strongest signals are usually behavioral. Does the person bring a second real case? Give you access to data or a workflow? Replace part of their current process? Pay to continue? Introduce someone with the same problem?
The format of the MVP should follow the question you need answered.
If you are unsure whether the problem is real, study recent behavior.
If you are unsure whether people trust the outcome, deliver it manually.
If you are unsure whether they will pay, run a paid pilot.
If you are unsure whether it can scale, automate only after the manual version is repeatedly useful.
Sometimes building less means fewer features. Sometimes it means not building software yet.
What are you currently building, and which part could be tested manually this week?
Exactly. Feature feedback is easy to collect because it asks people to imagine value. Behavioral evidence forces the assumption into contact with a real workflow. A useful exercise is to write the risky assumption first, then define the smallest action that would make it harder to dismiss. That keeps the test focused on learning instead of accumulating features.
The distinction between testing the product and testing the assumption behind it is useful. The behavioral signals you listed also seem much harder to dismiss than another round of feature feedback.