[yamalight]

To finally figure out how to effectively design and test MVPs / prototypes without overdoing it. I think this has been a bane of my startup life for pretty much whole ~14 years I've been doing it.

[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

[dan_lannan]

+1. I'm in the same boat. Making a conscious effort to build quick and dirty prototypes when needed and only build them after I get a potential customer to jump into Figma with me and spend an hour of their time designing something with me. If they're willing to do that the hypothesis is they actually really do want it.