3 ms·
Using your example, my personal approach would be: 1) Figure out how to organize a democracy of 10 people. 2) Once you got that down, bump the number to 100 p
by cj 6y ago
Using your example, my personal approach would be:
1) Figure out how to organize a democracy of 10 people.
2) Once you got that down, bump the number to 100 people, and identify / solve any new problems that arise.
3) Bump the number again to 1000. Rinse & repeat until you get up to 100 million.
In simpler terms, break the problem / idea into something you can confidently solve in a reasonable time frame, even if the first step (ie. "how to organize a democracy of 10 people") seems far removed from the end goal (ie. 100 million people).
- mazer_r 6y agoI like this “scaling” thought experiment technique very much in a variety of problems I face. It often makes things clearer to think in those terms. However, I think the 100, 1k, 100M approach might have drawbacks to finding the _best_ solution because the final iteration carries forward assumptions from the previous iterations. In CS terms, we may arrive at a local maximum this way, instead of the global max.
- cj 6y agoGood points. In startup terms, generally it's necessary to start with a MVP, from which you build on. The iterative approach is effective at ensuring you make progress toward the problem you're solving, but I agree, the risk is that you might end up carrying forward or "inheriting" problematic assumptions which can impede your ability to effectively solve the larger problem in the long run. On the flipside, the iterative approach at the very least will help you understand the problem domain thoroughly from multiple perspectives (iterations), even if that means you periodically need to throw out all of your work and start again from scratch.