Why we agree a First Value Date before work starts

Your company has approved a new website for an important market. The site is live, but your sales director is still asking when it will produce qualified inquiries.

That gap is why we agree a First Value Date before delivery work begins. It gives both sides a date to judge against a defined business result, rather than treating publication as the finish line.

A launch date answers only part of the question

Launch day confirms that something was released. It may confirm that pages and workflows operate as specified. Those checks do not tell a CEO whether the investment has started to produce value.

For a Marketing Director, the question is what became measurable, in which market, and when. A regional product website could look complete while its inquiry form routes leads to the wrong team. An automation could be switched on while staff continue doing the same work manually. A training program could finish without evidence that people can perform the task independently.

There are two costs: the time between committing resources and getting a meaningful result, and how well that result holds up as requirements change. We use Value = Velocity × Longevity to keep both in view.

Velocity concerns how quickly value arrives. Longevity concerns how long that value remains useful. A prompt launch followed by months of repairs or dependence on a supplier is a weak outcome, even when the launch date was met.

The First Value Date is a testable commitment

A First Value Date is the agreed date when the first measurable result will go live. We establish it in the Value Map before work starts, alongside the starting position, the business measure, and the scope required to reach that date.

The agreement needs a calendar date, an observable first result, a baseline showing the current position, and a KPI (key performance indicator) that your company already uses. It also needs a reliable source of evidence, so both teams can check the same milestone.

Consider an illustrative example. An industrial equipment supplier currently records eight qualified inquiries per month from one market in its CRM. The agreed KPI is qualified inquiries from that market, using the same definition of “qualified” before and after the release. The First Value Date is May 15. By that date, a focused market-specific product path, inquiry form, and correct CRM routing must be live, with a verified record showing that an inquiry can pass through the process and be counted.

That is a measurable first result: a functioning, verified path from buyer interest to an inquiry the sales team can handle. It does not prove that monthly qualified inquiries have already increased from eight. That movement needs real buyer activity and a later measurement period. If an illustrative target of twelve inquiries per month is agreed for a later checkpoint, it remains a target until the records support it.

In B2B markets with long sales cycles, we can commit to putting the agreed first result into use by a date. We cannot call an unobserved commercial improvement an accomplished result.

The date matters because everyone can check what became measurable, not merely what was published.

The date connects all four stages of the V² Framework

The V² Framework is organized around Value Map, Value Sprint, Value Transfer, Value Growth. The First Value Date gives those stages a shared definition of done.

In Value Map, we agree what exists today, which first result is worth reaching, and how it will be checked. We also decide what work belongs in the first release and which ideas can wait. The date is a commitment recorded before delivery, not a deadline reconstructed after the project has moved.

Value Sprint concentrates delivery on that result. The stage closes against the agreed first value, with evidence of what went live and whether it was on time and within scope. Shipping extra features does not compensate for missing the result both sides selected.

Value Transfer is where the client receives the access, source, documentation, and training required to operate the work. A useful first release should not create a permanent dependency for routine changes. Transfer also makes it possible to check whether the capability survives beyond the original delivery team.

During Value Growth, we examine the KPI and the durability of the result. The V² Report records measurements at 30, 90, and 180 days after launch. It can show improvement, a flat result, or decline, alongside the factors that may explain the movement. For a closer look at the evidence and scoring, see how a V² Report is structured.

A firm date changes decisions for both sides

For you, the First Value Date makes approval more concrete. Instead of asking whether a proposal includes every possible page or feature, you can ask whether the planned first release supports the agreed result. That makes it easier to compare a broad project with a smaller one that gives the business something useful sooner.

It exposes dependencies early. If the result needs product data, CRM access, a sales routing owner, or a decision about what counts as a qualified inquiry, those requirements belong in the Value Map. Your team can see which decisions it must make and what happens if they are delayed.

For us, the date creates a reason to keep scope narrow and specific. We prioritize the parts that deliver the agreed result, while still meeting the security, quality, and maintainability requirements needed for real use. We do not quietly add work because it sounds useful. A narrow scope is not permission to ship something unsafe.

New ideas have a place, but they go through a written change request. We estimate the extra work, explain its implications for the scope and First Value Date, and seek approval before starting it. The same principle applies across our services. It protects your ability to make an informed trade-off and our ability to keep the original commitment visible.

Missing the date must be visible in the report

An agreed date has little value if a missed commitment disappears into revised project notes. If we miss the First Value Date, the V² Report should state the original date, what did or did not go live, why the result was missed, and the new date. It should also record the effect of approved changes rather than rewriting the original plan.

A missing client approval, a changed dependency, and an error in our delivery plan are different causes. The report should explain the cause and consequence without obscuring the result.

The V² Score combines a Velocity Score and a Longevity Score, each on a scale of 0–10. It is a reporting tool, not a scientific measure of commercial return. A low score with dates and underlying evidence is more useful than a high score no one can explain. And when an external factor affects the KPI, such as a sales process change or seasonality, the report should say so rather than crediting every movement to our work.

Set the first value before you approve the project

You can use the same discipline with your internal team or any delivery partner. Before approving another digital initiative, get agreement on a small set of questions:

1. Which business result matters first? Choose something the responsible team already recognizes, such as qualified inquiries from a named market or the time needed to route an inquiry.
2. What is the baseline? Record the current measure, its source, and the period it covers. If no baseline exists, establish how to collect it before promising an improvement.
3. What exactly will be live on the First Value Date? State what a reviewer can use, observe, or verify on that day. Separate this from later KPI movement.
4. What is the smallest responsible scope? Include the capabilities, quality checks, owners, and dependencies needed to deliver that result. Put other ideas into a later decision.
5. Who approves a change? Agree how additional requests affect cost, scope, and the committed date, with changes recorded in writing.
6. When will you review the evidence? Plan the post-launch checks and identify who will own the system, data, and routine changes after handover.

You do not need a complete specification to ask these questions. Start by writing down the baseline, the first measurable result, and the date your team can verify it.

If you want to define those together with us, you can book a Value Map call.