When working on new products, here’s one hack I’ve used to avoid over-architecting for scale in the early stages but keeping teams focused on same goal. Shorthand is 1:10:100
1: Do the minimum work involved to pilot the product in its most minimal form, supporting it manually or in a manner that wouldn’t be economically sustainable at scale. Use this phase to test your key assumptions. Example might be a pilot with one organization, or a week long beta with actual users.
10: Identify the minimum additional work that needs to be done in order to scale up an order of magnitude from before. 10x more users, 10x more availability, 10x more clicks – whatever. Here you are testing to make sure the data you saw before holds. And understanding what parts of your technology/process/system break at this increased load.
100: Consider this steady state. What has to occur between 10 and 100 to support ongoing operations. It doesn’t necessarily mean full launch. For example, you might still decide to launch only to a particular customer segment or in a particular country. But it does mean that you’re pretty close to a product and process which scales repeatedly with demand or opportunity.
There’s nothing revolutionary about 1:10:100 thinking but I find that have an easy and simple way to describe moving from a manual test to a scalable product helps when defining goals and communicating across teams.
Are there other ways you’ve helped your teams understand the process of scaling?
Your explanation of 1:10:100 is simplest one I've read yet. Thank you for reassessing. We like to keep a simple model ourselves until we know the service has been tested, it's not breaking on use and users are happy with the benefit. Once we see good, growth and uninterrupted use around a particular service, we start to build other complimentary assets around it.