A metric we keep coming across in our training and coaching work is time to revenue. I believe the intended desire here is to measure how quickly we can go from either the conception of work or the deployment of a feature until we start seeing money coming in from that work. I can understand the desire to understand that and to see if we can reduce it. After all, the faster we can start making money from our work the faster we recoup the investment to launch it in the first place. However, most of the teams we work with are rarely in a position to take credit for revenue strictly on their own. So, is time to revenue even worth measuring in most situations?

Simple B2C situations where time to revenue makes sense

If your company sells directly to consumers and has a relatively simple path to production, measuring time to revenue might make sense. You can conceive an idea quickly, build a version of the product with one or two teams max and get a first version out to production in days or weeks. In this situation it’s easier to understand how long it takes from conception to launch to revenue due to the small number of dependencies. 

Your customers (or some segment of them) get access to the new product or feature and can purchase it directly. They don’t need approval from anyone and can use their own money to make the purchase. If you deliver something valuable to them, revenue should start flowing quickly. Measuring time to revenue here can give you a sense of how better monetize your audience because you get direct feedback from them. 

Complex B2B situations make time to revenue more difficult to measure

In large enterprises that operate in B2B contexts measuring time to revenue becomes much more difficult to measure effectively. Teams don’t operate independently. The sales cycle depends on entirely different organization. Simply getting the product into production means that anywhere from 2-5 different teams have to touch it. In even more complex organizations, the product is “made” in one part of the organization but then sold in various business units or verticals that have to agree to do so in the first place. 

Understanding how long it takes a product to start making money is (a) inconsistent from product to product and (b) wildly variable from team to team. In addition, the team that built the product is often not responsible for the sale of that product. Putting a “time to revenue” metric on the product team puts them in a situation where they are not in control of their success metrics. For example, let’s say a team builds a new service for their enterprise customers. Before it’s even presented to the buyer, the sales team has to understand it and learn how to sell it. Already the product team is out of the loop. If anything, the time to revenue metric should apply to the sales team. But here as well, the sales team is dependent on the product team delivering something of quality that they can sell consistently. 

What does a time to revenue metric even look like?

Finally, even if we did want to measure TTR, what would that metric look like? One example could be the time from official launch to the time the first dollar comes in. Is that valuable? Or, instead should it be how long it takes for the first actual sale of the product? It could also be the time it takes for the product to sell enough to break even. What if the payment terms for the product stretch out over a year and the first payment isn’t due to come in until 90 days from now? Have we made a sale that we can count?

TTR is likely not a good measure of success

The variability in how to measure it means the value of the metric itself comes into question. Adding in the complexities of anything other than a small, straight to consumer B2C environment and forcing teams to come up with meaningful, actionable time to revenue measures means they’re setting themselves up for failure.