Seth Godin, as always, writes so eloquently in this post about why top speed is over-rated, and it resonated with me so much.
I recently read The Lean Startup by Eric Ries, where he makes a similar point with regards to product development. He says that rather than optimize for development sprint velocity (how fast engineers build and ship features), we need to be optimizing for the entire product development cycle that ends in the validation (or invalidation) of an idea.
We can build extremely quickly and we can build a lot, but if we aren't learning by validating our ideas fast enough, then all that quickness in building fast means nothing.
Paraphrasing Seth Godin's example from the article above, anyone who has gone from Bangalore to Chennai by flight will know that the end-to-end journey is very likely faster by car than by flight even though the top speed of the flight is a lot higher than that of a car.
Similarly, fast development velocity is overrated and what we need to be optimizing for is the learning and validation velocity.
On a broader note, we tend to focus on the peak states and make decisions on them rather than the overall state. For instance, when I moved from Amsterdam to Dubai, a lot of my friends talked about the unpleasant summers of Dubai. Which is fair, four to five months a year is quite horrible in terms of the weather. But the unpleasantness is not dissimilar from the four to five months of Amsterdam winters. So, when looking at the pleasantness of weather alone, there isn't any real difference between Amsterdam and Dubai. But, we tend to focus on the extreme while making decisions.
Deciding on what area to live in (close to great restaurants even though we might only go there once a week) is another example where peak states play a bigger role than they should.
Like top speed, all peak states are overrated. What we need to be considering is the overall state.
I recently read The Lean Startup by Eric Ries, where he makes a similar point with regards to product development. He says that rather than optimize for development sprint velocity (how fast engineers build and ship features), we need to be optimizing for the entire product development cycle that ends in the validation (or invalidation) of an idea.
We can build extremely quickly and we can build a lot, but if we aren't learning by validating our ideas fast enough, then all that quickness in building fast means nothing.
Paraphrasing Seth Godin's example from the article above, anyone who has gone from Bangalore to Chennai by flight will know that the end-to-end journey is very likely faster by car than by flight even though the top speed of the flight is a lot higher than that of a car.
Similarly, fast development velocity is overrated and what we need to be optimizing for is the learning and validation velocity.
On a broader note, we tend to focus on the peak states and make decisions on them rather than the overall state. For instance, when I moved from Amsterdam to Dubai, a lot of my friends talked about the unpleasant summers of Dubai. Which is fair, four to five months a year is quite horrible in terms of the weather. But the unpleasantness is not dissimilar from the four to five months of Amsterdam winters. So, when looking at the pleasantness of weather alone, there isn't any real difference between Amsterdam and Dubai. But, we tend to focus on the extreme while making decisions.
Deciding on what area to live in (close to great restaurants even though we might only go there once a week) is another example where peak states play a bigger role than they should.
Like top speed, all peak states are overrated. What we need to be considering is the overall state.
CONVERSATION