Can’t we take shortcut X?
When can we consider this done and ship it?
These are discussions that come up all the time in product teams.
It seems to be human nature to strive for perfection to increase the chance of success. This logic is flawed and leads to suboptimal outcomes.
Speed actually increases your chances of being successful. How?
Let’s answer that question by looking at two teams working on the same problem:
Team A is building a product in 3 months.
Team B is building a “better” product in 6 months.
How does focussing on speed make team A more successful?
1. Speed helps to validate quicker, accelerating learning
Before you have built out your idea, you can not be sure if you are building the right thing. Your goal is not to build exactly what you had in mind when you started planning, your goal is to build something that solves someone’s problem.
Team A will find out if their idea works in 3 months instead of 6. This means they will learn twice as fast. As Bezos says: Our [Amazon’s] success is directly related to the number of experiments we run. If you can manage to structurally learn twice as fast as your competitors, you have a good chance of winning the race.
2. Speed decreases the cost of being wrong
If your hypothesis turned out to be incorrect, but you found out quickly by moving fast you will still have time to course correct. Being twice as fast makes the cost of being wrong twice as small. In addition to that, when your team knows that being wrong is okay they become risk tolerant and thereby more creative.
3. Speed increases the user value of what you are shipping
If you are right, your users can enjoy the value of your product for a longer time.
Let’s say both our teams start building in January. The users of team A’s product can enjoy it from April on, whereas the users of team B’s product can only use it for half a year. By building faster team A creates 50% more value for their users in that year.
4. Speed leads to simpler solutions
People prefer to add stuff when trying to solve a problem, instead of making things simpler. The more complex the system, the more can break and the harder it becomes to change things or even add new functionality. Speed keeps things simple.
Implementation
Of course you already knew all of this. The problem is that it will never work in your organization because of Y, X and Z. Your boss or your organization is simply not buying it. Don’t just roll over and accept that you can never build product in the best way possible.
As a PM you need to shape your organization in such a way your team can thrive.
Next time when you need to make a decision on the scope or timeline of a new product or feature, try to rephrase the conversation:
Explain choosing speed decreases risk
By moving fast and placing bets, you are actually de-risking the process. “I know you think this would make the feature incomplete, but are you willing to take a bet with me on this?” Explain that if you are wrong you still have 3 months to fix. But if you are right you have 3 months to build more valuable stuff.Take an investor’s view
Ask your boss or co-founder how they think they can be most successful in 1 or 2 years from now: By betting big on one feature? Or by placing multiple small bets? How do they manage their investment portfolio? And how is this game of investing time and effort any different?
Let me know if this is helpful or if you have any feedback!