Commit 157b21a1 authored by Victor Wu's avatar Victor Wu

Clarify two way door decisions

parent 7c217561
......@@ -113,7 +113,7 @@ However, if we take smaller steps and ship smaller simpler features, we get feed
1. **Under construction** - As we get more users they will ask for stability, especially in our UX. We should always optimize for the long term. This means that users will be inconvenienced in the short term, but current and future users will enjoy a better product in the end.
1. **Low level of shame** - When we talked to Nat Friedman he said: "A low level of shame is intrinsic to your culture.". This captures the pain we feel by shipping something that isn't where we want it to be yet.
1. **Do things that don't scale** - First optimize for speed and results, when it is a success figure out how to scale it. Great example are in [this article by Paul Graham](http://paulgraham.com/ds.html).
1. **Don't wait for a two way door** - Most decisions are easy to reverse, have the [directly responsible individual](/handbook/people-operations/directly-responsible-individuals/) make them without approval. As [Jeff Bezos describes](http://minimumviablestrategy.com/lessons/leadership/one-way-and-two-way-door-decisions/) only when you can't reverse them there should be a decision process.
1. **Make two way door decisions** - Most decisions are easy to reverse, have the [directly responsible individual](/handbook/people-operations/directly-responsible-individuals/) make them without approval. As [Jeff Bezos describes](http://minimumviablestrategy.com/lessons/leadership/one-way-and-two-way-door-decisions/) only when you can't reverse them, there should be a more thorough discussion.
1. **Changing proposals isn't iteration** - Changing a proposal isn't iterating. Only when the change is rolled out to users can you learn from feedback. When you're changing a proposal based on different opinions you're frequently wasting time, it would be better to roll out a small change quickly and get real world feedback.
A few challenges have arisen with how we approach iteration. The best example may be the proposal of a 2-month release cycle. The argument was that a longer release cycle would buy us time for bug fixes and feature development, but we don’t believe that is the case. As detailed above, we aim to make the absolute smallest thing possible and that doing otherwise will only slow us down.
......
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment