3 ms·
I feel like at a certain point you are moving too fast. The author makes it seem like he is chasing after speed at his own peril. Isn't it better to take an e
by zdgman 14y ago
I feel like at a certain point you are moving too fast. The author makes it seem like he is chasing after speed at his own peril.
Isn't it better to take an extra week to polish a feature than to just "ship it" and then patch it later? At a certain point as your organization grows and your product becomes more mature shouldn't your focus shift from quantity of features released to actually shipping quality releases?
I know there is a balance here. Don't be so worried about polish that you don't ship anything but don't be so blinded by speed that you ship everything within a week. You just can't make blanket rules like this.
- naval 14y agoThe problem is that there is an incentive to always pad estimates. By forcing a one-week schedule, you counterbalance that tendency, and make it possible to measure yourself more accurately. Despite this, I'd say that many of our projects fail, never ship, ship and have to be rolled back, or ship and have to be iterated 5 or more times until we get them "good enough." But it still beats taking 3 months to ship something interesting, which is the cycle most startups are on once they're out of an incubator or done with their initial release.