The Physics Of Startups: Is Your Startup Fast Enough?

In physics there is a term for speed needed to “break free” from the gravity — escape velocity. A rocket with an initial upward speed of 11.2km/s (25,950 miles per hour) or higher would leave the Earth and not return. If the speed was lower it would need to spend additional fuel or fall down and dramatically crash.

Is there anything more important for startup that a speed? Sam Altman said that: “Move fast. Speed is one of your main advantages over large competitors”. Lean Startup by Eric Ries is mostly about speed. What would it mean for a startup to maximise speed and avoid crash? Let’s find out!

Introducing Startup Speed Model

Startups also move at a certain speed. Speed in physics is a distance covered by a time it takes. For startups it would be the progress they make divided by time. Assuming that the main resource for a startup is time and progress is expressing the business value, this measure of speed is equivalent to ROI (return of investment).

Startups are organisations searching for a repeatable and scalable business model. They make progress by iterating with – elements of their model: value propositions, channels, target groups or revenue streams. Each time they receive a positive signal from the market (measured as a improvement in conversion / retention / acquisition cost etc.), they are getting closer to the goal.

As a startup you operate under huge uncertainty. You cannot predict the outcome of your next iteration. Your hypotheses can turn right, but unfortunately in most cases they turn wrong. The only thing you can do is to run a test and see. In a result, the progress startups make with each iteration is on average very small, because out of ten ideas you test, you are lucky if few of them become successful.

To express this worrying fact in our model, let’s break down the iteration progress into expected win and its chance of occurrence (success chance). As you can see small success chance of iteration is decreasing every startup’s speed. We have to deal with it.

The good news is that you have a big impact on the bottom part of the formula. You manage how much it takes to ship the feature or A/B test to the market. Iteration time consists of two main factors: development time (all activities directly contributing to the outcome — programming, designing, testing, deployment speed) overheads (research, discussions, brainstormings, planning sessions etc.)

Driving down the time of development and all the overheads you can significantly increase the iteration speed of your startup. If testing a minor change takes longer than few hours it means that you face some serious problems with product development and you should start with this point. Also if you spend the third hour trying to convince somebody to your idea, you should probably be already testing it. Less talking, more doing.

Is there anything you can do to increase the progress you make with each iteration? Absolutely, check out the following ideas: start with potential big wins — first of all focus on points where you can make a critical difference in a short term learn from your previous iterations to better assess the outcome and increase the success rate be careful with big projects — even though they offer high potential win, they are also very risky and time-consuming (basically, they slow you down)

Ok, having the complete model let’s us it in practice.

Case study

Some time ago I’ve advised a startup who faced challenges with the development time. It was a team of amazing, talented people willing to make a difference but not able to make a single move forward with their product. Development and deployment of a small feature was rarely shorter than a week time. Good ideas got stuck in the backlog for much too long. People got frustrated and nothing changed.

To avoid this problem they come up with a solution to assess each idea by its business value and technical complexity (very close to our iteration speed, however not including the risk/success chance). They wanted to limit the number of ideas by requiring each of them to have detailed analysis as a backup so that they can precisely assess the potential return.

Why it didn’t work?

• New approach didn’t include risk in the project assessment. As a result it over-estimated value of the large projects (with the highest risk) and under-estimated the small optimisations.
• With such a long deployment time many good ideas were rejected due to limited bandwidth.
• Extensive analysis required for each project added an additional time to the equation.
• The initial approach focused on the wrong things. By not addressing slow development time, limiting the stream of new ideas and requiring extensive research as an input for each iteration, it drastically slowed down the startup speed. They should rather focus on reducing the deployment time and all the overheads (including extensive research) to make sure that as many ideas as possible got tested.

Conclusions

Below key take-aways from the Startup Speed Model:

Aim at operational excellence in product development — minimise the time you need to bring any idea to the market. Shrink your development cycle to hours, not weeks. Ship MVPs, not excellent products.

• Do not believe you can predict the outcome. Go out of the building and test. Do not worry to fail. Learn.
• Do not block the stream of ideas. Make sure you have bandwidth to process the most promising ones.
• Do not let time overheads slow you down. Avoid too long data discussions or long-term planning.
• Divide big projects into small steps and test them as you go. Long projects can drastically slow you down.