Skip to main content

Startups as systems

The process of creation of a startup is the creation of a system. “A system is an interconnected set of elements that is coherently organised in a way that achieves something”. Your ability to influence that system extends to the elements (called “stocks”) you chose, the way in which they are organised (called “flows”), and the achievement itself. There is also a feedback loop in most systems, which takes time. Whether it’s adding a new feature, changing pricing, architecture, go-to-market and so on, it needs to be planned, implemented and measured for impact.


Your goal as a startup is to get to product-market fit (“being in a good market with a product that can satisfy that market.”). Thus the achievement, or output, is to produce a product fit for a given market using a model which both satisfies the market and is profitable for the producer. The race is to do that before you run out of money, or grit, or both.


Since feedback loops take time, and since changes to your system should be experiment/data driven, you have a limited number of actions you can take to make incremental changes unless each change extends your runway. Each change can be classified as an addition, subtraction or reconfiguration.


Changes influence complexity, the more complex a system is, the less predictable it is, and the less changeable it is. The easiest changes are subtractions, but these are rare in a “young” system (i.e. refactoring, restructuring, consolidating). The most common are additions (of stocks in this case i.e. employees, resources, technologies). The next most common are reconfigurations (i.e. experiments, changing the flows between stocks)


So what’s the point? To help you understand through a systems lens how to make decisions. 


  1. Make roadmap decisions. For as long as possible, keep the system as simple as possible, you want it predictable and adaptable with short feedback loops. The temptation is always to add more, and we generally look at stocks more than flows. Choose reconfigurations over additions.


  1. Choose your experiments wisely. Rate them on a scale of potential impact vs time taken, depending on your own situation, choose high impact low time options, then a couple of high impact high time.


  1. Understand what makes a system. Do this in order to know what you can change. Your company has the same purpose even if every person in it replaced themselves or re-organised themselves. However, if you adjust the objectives, you can end up with a very different system. Make sure you stay in the right game, but be very flexible with stocks/resources and their relationships/flows.


  1. Understand the results of your experiments. The reference book uses the example of holding a slinky from above, with one hand underneath, then removing the hand and letting it drop, instinct is to say it was the removal of the hand which caused change, but do the same with a box and nothing will drop, it was within the slinky that the change happened. Don’t be misled.


  1. Consider your investments. Adding sales/marketing early (addition) may increase stocks and look like a better system with a better outcome, but the flows will be badly optimised and the addition is one of manual pressure rather than a self balanced system. Ask yourself if it’s better to design a system based on product led growth instead.


  1. Assess in funding decisions/opportunities. The simpler the system, the more the potential shapes it could take, and the easier an addition. For example, you have less to prove when raising a pre-seed round (based more on potential), so this can fund your experiments. Again, keeping the system simple while effective for as long as possible is the optimisation here. Keep options open, be guided by the market.


Note: this article is influenced heavily by the book “Thinking in systems: a primer” which is highly recommended as a more general introduction.


Comments

Popular posts from this blog

Your first Clojure Project in 5 minutes

Clojure is a dynamic functional language, and is a dialect of Lisp with a priority of concurrency. It can run on top of the JVM (Java Virtual Machine), CLR (Common Language Runtime) and Javascript platforms like NodeJS through ClojureScript. Its pioneer is Rich Hickey , and if you have not heard his talks, I recommend this one on "Simple made easy" . You can learn about the current state of adoption of the language in  this Infoworld article . If you'd like to understand why Clojure is a good choice to learn, Uncle Bob can tell you . Tl;dr "I began to realize that this language was the easiest, most elegant, least imposing language I had ever used – and not by a small margin.". If you have never interacted with Lisp, Clojure can have a steep learning curve. The aim of this post is not to give a level of understanding of how Clojure operates. Rather, it exists to help people realise they can achieve a basic program very quickly even if they do not yet ...