Premature scaling can limit system iteration

First published:

Last Edited:

Number of edits:

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.


These are the other notes that link to this one.


Share your thoughts on this note
Aquiles Carattino
Aquiles Carattino
This note you are reading is part of my digital garden. Follow the links to learn more, and remember that these notes evolve over time. After all, this website is not a blog.
© 2021 Aquiles Carattino
This work is licensed under a Creative Commons Attribution-ShareAlike 4.0 International License
Privacy Policy