A lot of startup advice assumes building is expensive. Interview people, make a landing page, collect emails, and sell the idea before committing to the product.
That can still make sense. But when a credible prototype takes a day or two rather than several weeks, I think the order becomes worth reconsidering.
A working prototype answers one question. It doesn't tell us whether anyone will change their habits to use it.
Start with what would change
Would someone stop using a spreadsheet? Save a few hours? Make a better decision? Come back the next day?
Being specific about that makes the idea easier to test. Otherwise, it is easy to collect positive reactions without learning much.
I would also look closely at the existing workaround. A manual process or five tools stitched together can tell you where someone is already spending effort. It is a useful signal, though not proof that they will adopt your solution.
Build something people can respond to
If a small prototype is cheaper than a long round of hypothetical conversations, building can become part of the research. Instead of asking whether someone would use it, you can observe what they actually do.
That does not mean skipping the customer conversation. It gives the conversation something concrete to work with.
It could do a small part of the actual job, too. For example, produce the comparison someone needs instead of only showing them what a comparison screen might look like.
Keep the machinery simple
It is tempting to automate everything once you can. I would be careful about doing that before knowing whether the result matters.
It's fine to do some of the work manually for an early test. I'd want to know whether anyone needs the result before automating every step.
Then ask for a commitment appropriate to the product. That might be money, a pilot, workflow access, or enough time to use it properly. Each tells you more than a polite “this is cool.”
Look past the first reaction
An AI demo can feel impressive once. What happens after that is more useful. Does someone return? Does the product become part of their work? Is the improvement worth the effort of changing a habit?
That is where I would look before investing in more automation or infrastructure.
These aren't entirely new research methods. Cheaper prototypes just let us use some of them earlier:
| What I want to learn | What I'd try |
|---|---|
| Where is someone spending unnecessary effort? | Watch the existing workaround |
| Does the idea help with the actual task? | Build a small version they can use |
| Is it worth anything to them? | Ask for a commitment, not just feedback |
| Was the first reaction more than curiosity? | See whether they return |
| What needs to be automated? | Notice which manual steps become a problem |
“Sell it before you build it” is still useful advice when building is the expensive part. When it is not, I would rather build enough to learn, then look for commitment before scaling.