5 ms·
There are some assumptions in the story. The first is that you/your team is able to communicate your idea verbally (maybe with some mockups) clearly enough that
by davidjgraph 13y ago
There are some assumptions in the story. The first is that you/your team is able to communicate your idea verbally (maybe with some mockups) clearly enough that people understand it fully. This isn't always the case, and it's certainly not always the case with engineers. We're in this process right now and I tried to explain exactly what the product is verbally to potential users, I just couldn't.
The second assumption that seems to come into this argument is that ideas for products are stand-alone and don't evolve through experience in a domain and feedback of pain points on existing products (prior to where we form the idea).
You either put up a landing page and say give me your email, or you build a minimum viable product as with feedback as you build.
So we built the minimum viable _prototype_. It's not the MV product, anyone using it gives up within 3-4 minutes. But combined with me talking directly to the user, I can now hear that lightbulb turn on as they get what I'm talking about.
Simply, it's a continuous spectrum between the two boundaries and you need to pick the right point for your product. As a contextless headline, this is bad advice.
- zacharycohn 13y agoI think you missed the point a little bit. The point isn't to get them to confirm what you want to build is the right thing, it's to learn more about their problems to find out what you should build.