There’s a reason why there’s such a cult around speed in startup culture. Whoever reaches the market first has a huge advantage, so you better get there before your competitors do, because the first mover advantage often eclipses the importance of who has the best product.
But as car racing will show, going slow at the right portion of the bend is what positions you to make the most of the “straightaway”. The key here is manoeuvrability, and it’s what makes a the tiny Mini beat a muscle car like the Ford Mustangs.
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 look at any given product in terms of layers, each of which can and should develop at different speeds.
For example: growth hacking can and should keep a product enchanting by a constant stream of cosmetic tweaks in the top layer, while deeper into the stack there are layers that needs to move at a slower 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.
(You might think this is just putting new labels on the different layers of the tech stack. Afte rall, 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 and be dirty. 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 it brings. It is my experience that we far too often try to squeeze multiple layers into one obese roadmap with the result that processes which needs to be slow seems to be moving even slower than expected. Which in its turn results in the layer that could and should move quickly is getting deprioritised. I can see how having different frequencies for different layers really could make a difference here.