[pilgrim0]

As someone who’s on research, I do hundreds of prototypes each year. My time optimizations include having a backing hypothesis for each prototype, and prototyping one hypothesis at a time, even if two hypothesis touch on the same domain problem, I spin a fresh new prototype for each. Usually I’m able to validate the hypothesis even before finishing the prototype, as merely getting the hands on the process reveals the answer. Also, each hypothesis lend itself to some specific kind of prototype. Some things will be amenable to code prototypes, others to statecharts, others to visual designs, etc. so getting intimate with your toolset is essential for productivity, as most time is spent with these tools. Even simple things like mastering keyboard shortcuts represent significant productivity gains. But building is not the hardest part, by far. The hardest part, for which there’s hardly any optimization is this: how to filter and select an hypothesis to begin with? Overall, I would recommend getting good at prototyping in general (as a mindset thing) and not simply trying to quickly make a particular prototype.

[yamalight]

Having a research background - for me, doing this in research was always easier. Because you generally have very straightforward ways to validate your hypotheses.

Validating things with customers - in my experience - can be extremely tricky as they might not even know what they want

[pilgrim0]

Absolutely. In this case this means your pre-process will be less deterministic, hence your success ratio will be lower (maybe a lot lower). Perhaps improving your communication and data analysis skills would do good, as this sort of context is characterized by asymmetric information. Even though you’re in the market, this is still research, just of a different kind. I would try and find the “hidden variables” for each candidate hypothesis. Assuming “performance” to be the true abstract metric you’ll be striving for, it’s important to identify what particular concrete performance metric is worthwhile improving. For instance, consumers may suggest interest in feature A and B, but once you analyze their yield you identify they are time-saving features at their core. If time is the hidden variable, then where in the product lies the best opportunity for saving user time, even though the customers might not be mentioning it? I would guess that most requests or indications coming from customers will fall more or less in the same few buckets in respect to hidden variables and related metrics. Overall you shouldn’t take customer feedback as prescriptions, but as symptoms, and those symptoms might not even be related to what they’re being vocal about, since they might be stuck in a corner not by the lack of improvements in that existing domain but maybe by the lack of an entire novel domain. Think of it like a Tetris game, locally, each region in the bricks stack require some particular piece to solve that region, but globally, that’s not a good strategy, as a whole different piece in a whole different region would solve a larger portion of the stack.

[pilgrim0]

Then there’s, of course, the issue that the whole of current customers feedbacks might be blinding you from what the product really needs to grow beyond that base, since a startup’s ultimate goal is growth, and fulfilling the current customer’s needs might make them happier but result in zero overall growth.