Premature scaling can limit system iteration

<p>When we design a system to explore with users, there is always the temptation to scale it to include different use cases. That would extend the footprint, hopefully gathering more users, more feedback, and a more efficient iteration cycle. </p> <p>This is something that happen to me while building the <a class="wikilink" href="/nanocet/">NanoCET</a>. </p> <p>I wanted to include the opinion of people working on different fields, that required different approaches. When developing the <a class="wikilink" href="/nanoqnt/">NanoQNT</a> happened again, but I had no clear way of communicating my thoughts with my team. </p> <h2>The issue</h2> <p>If you scale prematurely (see: <a class="wikilink" href="/essays/do_things_that_can_scale/">Do things that can scale</a>), you limit your opportunities of iteration. When you start building a <a class="wikilink" href="/minimum_viable_product/">minimum viable product</a>, the objective is to explore as many use cases as possible, in as little time as possible. </p> <p>Therefore, it is not a matter of scaling the MVP itself, but in scaling the exploration. It is much smarter to create small context of use that will provide serious feedback before scaling up and ending in a situation where change is no longer possible. </p> <p>With hardware (see: <a class="wikilink" href="/essays/_hardware_mvp/">_Hardware MVP</a>) the issues are pervasive, since iteration is expensive, slow, and with a high degree of uncertainty regarding its success.</p>