Post Scarcity Escape Velocity: Difference between revisions
(Created page with " '''Post-Scarcity Escape Velocity''' - a business term noting the point of infrastructure, which once reached, allows for open source product development on the time scale of...") |
No edit summary |
||
(One intermediate revision by the same user not shown) | |||
Line 1: | Line 1: | ||
'''Post-Scarcity Escape Velocity''' - a business term noting the point of infrastructure, which once reached, allows for open source product development on the time scale of one-day iterations, or a development compression (measured compared to the full time effort of one person) of about 100 fold. This allows for product releases | '''Post-Scarcity Escape Velocity''' - a business term noting the point of infrastructure, which once reached, allows for open source product development on the time scale of one-day iterations, or a development compression (measured compared to the full time effort of one person) of about 100 fold. This allows for product releases on an unprecedented time scale - ie, the possibility of solving problems faster than they are created. | ||
The rationale for 100x personal output increase is comparison to a one year product development cycle, or 12 man months. Here, we have in principle 100 man months in one month, but given inefficiency of non-peak performance, we have 10 man months. There are large coordination risks of 100 people teams, where the only route to success is collaborative literacy. A one month immersion cycle allows for rapid development in a reasonable amount of time. | |||
An open source product development process must have specific assumptions about manpower and goals reached. Designing a process around 100 people gains the inspiration factor of producing rapid results. Heavyweight product management must be applied in this case for focused delivery. Specific role architecture must be devised. |
Latest revision as of 22:03, 6 May 2024
Post-Scarcity Escape Velocity - a business term noting the point of infrastructure, which once reached, allows for open source product development on the time scale of one-day iterations, or a development compression (measured compared to the full time effort of one person) of about 100 fold. This allows for product releases on an unprecedented time scale - ie, the possibility of solving problems faster than they are created.
The rationale for 100x personal output increase is comparison to a one year product development cycle, or 12 man months. Here, we have in principle 100 man months in one month, but given inefficiency of non-peak performance, we have 10 man months. There are large coordination risks of 100 people teams, where the only route to success is collaborative literacy. A one month immersion cycle allows for rapid development in a reasonable amount of time.
An open source product development process must have specific assumptions about manpower and goals reached. Designing a process around 100 people gains the inspiration factor of producing rapid results. Heavyweight product management must be applied in this case for focused delivery. Specific role architecture must be devised.