[laboratorymice]

> 2) assuming that what you are building is something the user wants - until people use it, you have no proof for this. Lots of startups fall into the trap of building stuff that nobody wants or needs.

> You have to pitch and explain the thing to them and even then they still might not get it. Only when you show them the thing and they like it will you get some confirmation that this might be something they want/need.

If you have to build first in order to pitch and show it, then necessarily you've had to assume that what you were building is something they want. Maybe your point was to get new features quickly into the hands of users to test the assumption early, but that has its own significant downsides.

I like the way you phrased it though, in terms of "don't assume foo" instead of "do bar", because it implies that there's really no replacing good old-fashioned _thinking_ with blindly following a 5-step plan to success.

[jillesvangurp]

It argues for validating your assumptions as quick as you can. Which is why mvps, prototypes, and click demos can be a good thing. It doesn't always work though. Digging in and burning through a few million of investor money before your product encounters real users, is the expensive way to do it.