There’s a reason speed has become a cult in startup culture. Whoever reaches the market first gains a huge advantage, often eclipsing the importance of having the best product.
But as car racing shows, slowing down at the right part of the bend positions you to accelerate through the straightaway. The key is manoeuvrability, which is how the tiny Mini can beat a muscle car like the Ford Mustang.
What’s true in racing is true in entrepreneurship. You want to go as fast as possible, but doing so sometimes means slowing down. I thought about that the other day when I heard Niklas Rosvall talk about a product management concept called speed layers.
The idea is to view a product as a set of layers, each developing at its own pace.
For example, growth hacking can keep a product fresh with cosmetic tweaks at the top layer, while deeper layers in the stack need to move at a slower, more deliberate pace. These are tech-driven and your users don’t need to know about them. It’s where you’re making the slow moves that will create a unique position in the long run. It’s where market leadership is spawned.
Now you might think this is just putting new labels on the different layers of the tech stack. After all, don’t we already know that frontend development can generally be more agile than backend stuff?
Not quite. As many architectures are moving towards a service based modularity, you can actually have full – as in vertically integrated – slices of functionality where it’s possible to move fast without breaking things.
The opposite is also true: just because frontend developers are working on what’s technically the top layer of the product, that no longer means that they can necessarily move quickly. They might have been the cowboys of software engineering in a simpler time –really not so long ago – but the complexity a frontend developer has to handle these days, can easily supersede what a backend’er has to deal with.
I really like the clarity this concept brings. In my experience, we often squeeze multiple layers into a bloated roadmap, making processes that should move slowly seem even slower. As a result, the layers that could and should move quickly end up deprioritised. I can see how having different frequencies for different layers really could make a difference here.