When you buy a cool new gadget, you can’t wait to bring it home and start using it. We all want instant gratification. Business software buyers are no different. Once they decide to buy, they want to see results ASAP.
The concept of time to value describes how long it takes for a technology buyer to actually get value from their purchase. In the enterprise software world, it typically describes the lag from signing the purchase order until the initial launch of the new system. This is a pretty short-sighted view. Think about the broader customer journey, the clock really starts ticking during the early stages of the sales cycle – once a company decides they need to buy a new platform, and it extends beyond initial launch until the system is truly in production and delivering the benefits that spurred the purchase in the first place.
The typical view of a single measure for time to value is just too macro. There are multiple points along the journey where customers receive value and each one should be measured and celebrated. I recall a semi-fast-food restaurant where each step of the way was time-stamped and the staff was quota-driven for efficiency. The clock started when you checked in with the hostess, and progress was measured from being seated, taking the order, delivering food, delivering the check, and completing the payment. If you wanted an efficient dining experience, it definitely fit the bill. The point is that this restaurant divided the value journey into micro steps and focused on each element of the experience.
There are similar micro steps in enterprise software deployment. Each step is an opportunity to measure and influence time to value, and drive efficiency into the process. Remember, it is human nature to want instant gratification, so consider every delay as a disappointment. The faster a customer gets through all of the steps from the decision to buy, to ultimate production, the happier they will be.
Returning to the idea of expanding the definition of time to value, a typical approach is to measure only the implementation time from contract signing to initial launch. This is a vendor centric view, rather than a customer-centric view. It drives implementation teams to focus on their own stats instead of the customer’s view of success. Customers have a problem to solve, and in an enterprise setting, that usually involves deploying a platform for a range of constituents and departments. Simply making the system work does not mean the problem has been solved or all of the potential users are satisfied.
Real customer value will not occur until there is a broad launch and the customer sees engagement and repeat usage of their new platform. “If a tree falls in the forest and nobody hears it, did it make a sound” is an apt analogy. If we stand up a new system and only the project team is using it, did we really launch anything? Did the customer get any value? Should we expect them to be happy and renew? The answers to these questions seem obvious. Engagement and usage are the measures of success, not completion of tasks and delivery of features. Therefore, we need to expand the concept of time to value beyond simple implementation, and consider the entire journey from determining need to full deployment and broad engagement.