Conventional startup wisdom says that the first thing you should build is an MVP.
And yet, I’ve built three in the past, each taking 2 - 4 months to release, despite estimating a few weeks at most. This is the planning fallacy at work, and the reason why MVPs in practice aren’t nearly as compelling an idea as they seem in theory.
The planning fallacy says that humans are extremely overoptimistic about how long something will take. A landmark 1994 study found that the actual time things take is generally slightly worse than our worst-case prediction.
The point of an MVP is to learn and validate in extremely short cycles. But if most MVPs take months to build, then it ceases to be an effective tool for rapid learning.
Knowing this, I decided to do things a bit differently this time.
These days, I’m working on Probe.
Probe is an autonomous user interviewer who talks to customers for you, so you can conduct hundreds of customer interviews in a single weekend.
In the past, I would have spent months building an MVP to validate it. This time around, I knew better and built a prototype instead.
I figured that if the prototype can gather deep insights about my customer, then the product probably has potential. If it can’t, I’ll either need to iterate, pivot, or drop the idea altogether.

The prototype is pretty basic: it just interviews founders about their experience conducting customer interviews. You can’t sign up to it, and it doesn’t do much else.
Overall, it took just over two weeks to build.
The planning fallacy still made its presence known, since my initial time estimate for the project was just four days. But because the scope was so small, it didn’t really matter.
Two weeks is a lot longer than the four days I’d intended, but miles better than the two months I would have spent building an MVP.
If you want to give the prototype a try, you can chat with it at heyprobe.com. It only takes ~3 minutes to try, and it’d be a massive help in validating whether the prototype does the job!