Linear project timelines can be useless or damaging in product/tech organizations. Most product development cycles look more like a decision tree and less like a Gantt Chart as noted in the graphic above. This sounds controversial, especially within software vendors and companies who are accustomed to RFP’s but hear me out. Before getting to my point, a few caveats; #1 I’m talking primarily about web development, not manufacturing. #2 Lightweight relative T-shirt sizing (small, medium, large for days, months quarters) is a helpful distinction for debating opportunity cost. What I’m referring to is the traditional date driven timeline based on specifications (or release planning in Agile methods.) Those timelines are costly and potentially damaging. Here’s a few reasons why.
1. Product development, especially finding product / market fit - is not linear. I’ve never built a great product linearly, in order to find the right product fit, the team may need to change their mind a few times and try something totally different than what they imagined at first. We call this learning and it doesn’t always fit neatly into a schedule.
2. Estimates are largely wrong. Technology estimates are incorrect more than half the time. Estimating substantial complexity is near impossible. In over a decade of development, I’ve observed dev teams ability to estimate two weeks worth of work to roughly 80% accuracy. When you stretch that to 4 weeks estimate, the accuracy drops to 50% and so on as the work gets more abstract. Add to this the fact that people are generally optimistic and you end up with a gap between expectations and reality.
3. Poor allocation of resources (i.e; you are wasting precious time estimating. You could be building something). Estimates are not worth the time they take to generate. A litmus test I often use is having a conversation with my associates about the time / cost of estimating. It goes like this, “Ok guys, how important is the estimate? Is it so important that we are cool with the development team spend the next month estimating instead of building ” 9 times out of 10 the answer is no, we’d rather have something real completed (even if it’s wrong) than spend time estimating - and that is because the estimate itself is rarely a deciding piece of information.
4. The timeline is abstract. Unless you are building the same thing over and over again, your team will not be able to get a realistic assessment of what it will take until they get started. This is because there are too many unknowns that only become known when you try to build. In David Allen’s book Getting Things Done: The Art of Stress-Free Productivity he promotes adhering to specific next steps rather than abstract larger goals. "The latter looming in the back of our mind like a nagging mother, never fully silenced until specific actionable steps are taken."
5. There are better tools for accountability. I often hear that dates are a good way to motivate teams and there’s some truth to that. I’ve found short sprints to be a decent gauge of accountability. At the end of a short period, either the team finished all their work, or they learned that something else was more important and shifted during the iteration and that’s a helpful to know. However, creating accountability around abstract concepts like a date far off in the future is potentially damaging because your teams don’t’ understand what they are signing up for.
If you build the same thing repeatedly, there are big efficiency gains to be had by optimizing timelines. The same can be said for hardware development where adherence to process quality and timelines is important. On the web, we work in a world of uncertainty, where we rarely build the same thing twice. In this world, timelines aren’t a very helpful tool. So, for those of you in the same arena, let’s have more productive conversations today.
* Product people - Let’s talk about priority instead of haggling feature trade-offs related to a date.
* Leadership - let’s debate user value / metrics instead of timelines. (T-shirt sizing is good enough)
* Engineering - let’s build a prototype instead of “scoping and estimating” abstract concepts.
Happy Building.
-Wyatt Jenkins