Why Accelerate?

It seems odd to ask this question, Why accelerate?, since it’s obvious in the technology business that you die if you don’t release new products faster than your competition. Fast teams know this reality and communicate the “need for speed” to the engineering teams. In slow environments, this critical information is insulated from the technical teams and only reserved for marketing, finance, and leadership forums.

Fast teams understood the economics of delay and used this to create urgency well in advance of the projected market window. They knew that if they entered at the front of the curve, they could maximize revenue and profit margin. The longer they waited, the lower the market share would be and the more fierce their competition would be.

When we studied failed projects, we observed that late entry usually resulted in less market share, less revenue, lower margins, and higher development cost due to the extended development time frame. We’ve seen late entry actually kill companies completely.

We built an economic model to quantify time in terms of money in order to make the “time asset” more important. We use it with teams to determine the cost of delay for each day the project is late. We develop a simplified business case with the full team, data which is typically hidden in detailed financial models and rarely exposed to engineering teams. We use this tool with development teams to connect them with the economics of being on time.

In this example, we forecasted unit sales, average selling price, and costs to develop and make the product. To simplify the example, I’ve removed marketing/SG&A expense. You can seen the sum of each category below.

Example business case

Example business case

This project generates a 3x return on investment. We’ve worked in some environments where anything less than a 10x ROI would not get funded, but in this case a 3x is a very good return for this market.

Based on this business case, we’ve estimated the impact of a 3 month delay in the project. We assumed that we would take a 10% hit on our sales by entering the market late. We could have also looked at this by year, percent by year, or a simple shift to the right in the sales curve. Delay costs us $877,000 in lost profit per day.

This is not uncommon in Silicon Valley, where most projects we work on have delay values of between $200 and $800k per day.Earlier I made the point that schedule was king and time to market had the greatest impact on profitability. This model clearly illustrates the impact schedule has on profitability. In this example, schedule is twice as important than the next most important factor driving profitability, which is ASP. A 1% change in R&D expenses has little impact compared to an equivalent change in schedule.

The model reflects a common pattern for new technology-based products… if get to market faster, you improve your chances of profitability. Of course this assumes it is the “right product” you are getting to market, but this is another discussion. So being fast to market is obviously not the only determinant of success, since the wrong product at the right time can fail just as well as the right product at the wrong time.

Another advantaged of the model is to use it to make trade-offs during the project. We constantly see budgets restricted or cut to reduce burn rate or save money, without consideration for the impact the resource reduction would have on time to market.
Let’s turn it around and “spend to save a day” (one of the best practices of fast teams) and see what happens to the model. Increasing the budget by 30% to accelerate the schedule by 4 months gives me a net benefit of about $37M. I increased and accelerated PBT, but I took a hit on my return. I may decide that acceleration has a greater cost-benefit.

Lets do another interesting study… I have found a way to increase my selling price by adding functionality customers value, while at the same time I found a way to reduce the manufacturing costs through automation efficiencies. This effort requires more time from engineering, so my budget increased by 25%. This effort also required 4 more months of time, which is reflected as delay. Still the benefit out weighs the costs. We are still ahead on PBT with this decision.

The point is that time and money are connected. Go faster and your chances are better you will achieve higher share, margin, and a longer revenue cycle. The other opportunity cost not reflected here is the accelerated learning you get when you get to market faster — the faster you push, the faster you fail, and the faster you learn.

And for start-ups, the longer you wait to get to market, the fewer learning cycles you get with the cash you have in the bank. The trick to winning in this world is fast cycle-time and many cycles of learning. Accelerate learning cycle-time and you get the solution faster.