Time to Reliability

Adam Bahret
Adam Bahret
Screen Shot 2021 11 23 at 3.20.21 PM

One metric we always keep front and center in our product program dashboard is “Time to Market.” It is without a doubt the most dishonest metric we keep in program development. In using this metric, we are not just lying to our peers, customers, and stakeholders, but also to ourselves, collectively, like a dirty little secret that we only speak honestly about in the dark corners of our conference rooms.
Why am I calling Time to Market a lie? Well, it’s because the phrase time to market implies we have finished development and are in production of a mature product that requires neither further development nor all the required resources that go with it.
In actuality, what we know is true (and choose to leave out of the quarterly report) is that we have a laundry list of items we plan to address once the product is released. Additionally, we often have an entire list prepared of potential unknown issues that will consume a great quantity of resources, many of which the customer will be informing us of shortly after launch.
In the end, however, we say that time to market went as planned. We celebrate it and move on, only to act surprised when we all get pulled back into a growing hurricane of issues. Tiger teams are formed, new projects put on hold, money re-allocated for further investigation and re-engineering, and the growing cost of warranty expense. Then there is the impact that is most difficult to quantify, but that is often the biggest cost; brand damage and loss of future sales.
But hey, it’s ok, we got the product out on time. Well, in reality, we got a prototype out on the date that we had planned to release a mature product. Maybe we should put that cake back in the fridge.
So, when is the real Time to Market? It’s when you deliver what you planned to deliver when the program started; a product with X functions, at X cost point, with X reliability.
Since we seem to refer to Time to Market as when we first release the product, I would like to introduce a new term that we can use when the final product is in production. I call it “Time to Reliability.”

How do I define Time to Reliability?
Time to Reliability is when a product that is capable of satisfying it’s reliability goals with the intended functions is in production. If a new product was released to the field with issues, then Time to Reliability will be the moment when the Tiger Team is disbanded (sent back to the Zoo or wherever they came from) and budgets are no longer being hit and reallocated for recovery. New product development is turned back on in the manner intended because the development team is now free. This is the “Time to Reliability.
If a company has a mature product development process, then Time to Reliability and Time to Market are the same. When Time to Reliability (TtR) and Time to Market (TtM) are the same, the customer gets a mature product even if they receive the first one off the line. If TtR and TtM are the same, then the development team can move on to creating the next new great product when planned. Finally, and most notably, when TtR and TtM are the same, customers stay loyal, leaders can work on strategy, and the company thrives because things go according to plan.

I recommend you start measuring your products’ Time to Reliability. As a starting point, consider the following question: What are the costs associated with having a gap between Time to Market and Time to Reliability? Now, consider how you can take that new metric and pull it into program milestone reviews and see if it affects program decisions.

Share this post