Premature scaling can limit system iteration
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.
This is something that happen to me while building the NanoCET.
I wanted to include the opinion of people working on different fields, that required different approaches. When developing the NanoQNT happened again, but I had no clear way of communicating my thoughts with my team.
The issue
If you scale prematurely (see: Do things that can scale), you limit your opportunities of iteration. When you start building a minimum viable product, the objective is to explore as many use cases as possible, in as little time as possible.
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.
With hardware (see: _Hardware MVP) the issues are pervasive, since iteration is expensive, slow, and with a high degree of uncertainty regarding its success.
Backlinks
These are the other notes that link to this one.