Implementation
Stop measuring go-live
Time-to-first-value is a harder number to produce and a far more useful one to manage.
3 min read

Go-live is a date on your plan. It means your work is finished.
First value is a date in the customer's life. It means they did something with your product that they could not do before, and it mattered to them.
These are not the same date, and they are often weeks apart in either direction. Most organisations measure the first and manage to it, which is a little like a restaurant measuring the time it takes to cook rather than the time until someone eats.
Why the gap exists
Go-live before value is the common case. The system is configured, training is delivered, the project is closed, and then nothing happens for five weeks because the customer's team is mid-quarter and nobody has time to change how they work. You have delivered. They have not benefited. Your dashboard says success; their renewal instinct says something else.
Value before go-live happens too, and it is a gift most teams waste. A customer gets real use out of one module in week two while the full scope is still six weeks from completion. That early win is the strongest retention signal you will get all year, and in most organisations it is not recorded anywhere, because it is not a project milestone.
Defining first value without it becoming a philosophy project
Keep it concrete and specific to the product. A workable definition has three properties: a named person does it, it produces an outcome they care about, and you can tell from the system that it happened.
Bad: "the customer is realising value from the platform."
Good: "the operations lead runs the weekly exception report themselves, without us, and acts on it."
Good: "the support team resolves a ticket using a knowledge base article rather than escalating."
Good: "a customer-side manager logs in on a Monday without being prompted."
That last one is underrated. Unprompted repeat usage by someone who is not your project sponsor is the most honest signal of value there is.
What changes when you manage to it
You sequence differently. If first value is the goal, you deliver the module that produces it first, even when a different sequence would be tidier for you. Tidy sequencing is a delivery preference, not a customer benefit.
You notice the silent failures. A customer who went live and then stopped using the product is invisible on a go-live dashboard and glaring on a first-value one. This is the population where churn is manufactured, and they almost never complain — they just quietly do not adopt.
Your CS handoff gets a real trigger. Instead of handing over at project closure, you hand over at first value, when there is something to build on.
The measurement problem
This metric is harder to produce than go-live, and that is the honest reason most teams do not track it. Go-live is a field someone sets. First value requires knowing what is happening inside the product.
Which means it is a question about your systems: can you see, per customer, whether a defined action has occurred and who performed it? If your project tool and your product usage live in separate worlds, you cannot, and you will keep managing to the date you can see.
Holding the customer record, the project and the product's own activity in one place is what makes the metric available at all. PlaNath is built that way — customer, project and workplan, defects, support and customer success against the same record — so the question "has this customer actually started using what we built?" has an answer that does not require a survey.
Go-live is your milestone. First value is theirs. Only one of them predicts the renewal.
PlaNath keeps customer, project and product activity in one record. planath.com
Start free trial

