Every company instruments the promise and hopes for the delivery. Why pre-sales and professional services are the only instrument that measures whether a new product is still connected to what customers actually expect, and why most organisations find out eighteen months too late.

Eighty percent. That is the share of features in the average software product that are rarely or never used, based on Pendo's analysis of feature usage across 615 subscriptions, which also estimated that publicly traded cloud companies spent around 29.5 billion dollars in a single year building them. The Standish Group, using a different method a decade earlier, reached a similar verdict: roughly two thirds of features in a typical product are rarely or never used.

Now put a second number next to it. In Gartner's annual product manager survey, only 11 percent of organisations reported that all of their products met 100 percent of their defined internal launch targets, and 45 percent of launches were delayed by at least a month.

Two different measurements, one conclusion. The problem is not that we cannot build. The industry has never been better at building. The problem is that between the moment a product is conceived and the moment a customer actually uses it, something breaks the connection, and almost no company has an instrument pointed at the break.

That instrument exists. It is called pre-sales and professional services, and in most organisations it is treated as the last mile of the launch rather than its measurement system.

We instrument the promise and hope for the delivery

Look at what a launch dashboard actually tracks: GA readiness, feature completion, enablement sessions delivered, pipeline generated, logos closed, bookings against plan. Every one of those metrics sits on the pre-signature side of the business. Every one of them measures how well we told the story.

And the single best predictor of whether the product survives its second year, the distance between what was sold and what was delivered on the first ten accounts, is measured by no one.

This is not an oversight. It is structural. The people who can see that distance, the pre-sales engineer who watched the buyer's face when a use case did not fit, the delivery lead in week three of the first deployment, sit at the end of the organisational chain, and their reporting line runs into a delivery review rather than into product and marketing.

The root problem is truth latency

I would give the failure a name: truth latency. The delay between the moment a customer experiences your product and the moment your company knows what they experienced.

In most enterprises that delay is measured in quarters. And it compounds, because the cost of a correction rises with every quarter of latency. In month one, the fix is a slide and a conversation. In month twelve, the pitch is in the field, the roadmap is committed, thirty accounts have bought the same promise and the correction now requires a repositioning, a release and a set of uncomfortable customer calls.

A few years ago I was asked to look at a red account. Flagship module, biggest logo of the launch, eighteen months in, renewal at risk. Ordinary fire-fighting. I asked the delivery lead to send me whatever documentation existed.

She sent me a folder. In it was a five-page note she had written in week three of the very first deployment, months before the account went red, before it was even late. It listed four things that would break. All four had broken, in the order she had written them.

She had sent it to her manager, who raised it in the delivery review, where it was logged as a project risk. Which is exactly what it looked like. It was not a project risk. It was product feedback, and pricing feedback, and pitch feedback, and it sat one floor away from the two teams who needed it for nine months, correctly filed, in a system working exactly as designed.

Nobody was negligent. The organisation simply had no channel through which the truth could travel upstream.

Here is the asymmetry that follows. We pay analyst firms six figures for a picture of a market we are already standing in. Meanwhile the unfiltered evidence, watching a real customer with real data try to use the thing we just built, is generated at zero marginal cost every week by pre-sales and delivery, and routed into a risk log where it dies quietly.

Most product gaps are promise gaps

One of the four items in that note was not even a defect. The demo had promised connection to existing systems in a day. That was true, for one system, with a clean schema. The customer had nine.

Fixing the product would have taken three quarters. Fixing the sentence took an afternoon: we turned it into a qualification question asked in the second sales meeting. How many systems, whose schemas, who owns them.

Win rate on that module went down slightly. The churn cause disappeared entirely.

This is the part that gets skipped in launch reviews, and it explains a fair share of that 80 percent of unused features. When delivery reports a gap, the reflex is to route it to product, because a gap sounds like something missing. But a roadmap item takes two quarters and a trade-off, while a promise can be rewritten on Tuesday. Send the gap to sales first and to product second, do it for six months, and most organisations discover that a meaningful slice of their roadmap was compensating for their own marketing.

The corollary matters for anyone leading a professional services organisation. The qualification questions your delivery teams wish sales had asked are not sales collateral. They are a product artifact, the shortest available description of the conditions under which the product actually delivers value. They should ship with the product.

A product does not exist on the day it ships

It exists on the day a delivery team that did not build it deploys it for a customer who did not co-design it. Everything before that is a hypothesis with a launch party.

Design partners do not count. Neither do the two friendly accounts a VP of Product personally shepherded, because those customers were sold by the founder of the idea, supported by people who wrote the code, and forgiven for things a paying customer will not forgive. Your real market will be sold by an account executive with a quota and a slide, and served by a consultant who joined last quarter.

The gap between those two populations is where launches go to die, and pre-sales and services are the only functions that stand in both.

Five decisions for the executive committee

If I were structuring this for a launch this quarter, five moves.

• Give pre-sales and PSO a veto on the GA gate. Not a seat at the table, a veto. A product is not generally available because engineering has closed its backlog. It is generally available when a delivery team that did not build it can deploy it, on customer data, with a written playbook, in the time the pitch claims. If that has not happened three times, it is a pilot with a press release.

• Run the first ten customers as an experiment, not as accounts. One named senior delivery lead across all ten, a written hypothesis per account of what value looks like and by when, and one readout every two weeks to product and sales leadership in the same room. Not a QBR, a lab notebook. Ten accounts is not a statistical sample and does not need to be. It is the entire population of humans who have used the thing.

• Route every pitch-to-delivery gap to sales before product. Two thirds of what gets escalated as a product gap is a promise gap. Fix the sentence first, then decide whether the feature is still worth building. Publish the corrected sentences to the field weekly for the first two quarters.

• Put a delivery metric on the launch dashboard. Time to first value on the first ten accounts, variance between quoted and actual deployment effort, and the number of pitch corrections issued. Three lines, all available today, all measuring the post-signature side of the launch that nothing else on the dashboard sees.

• Instrument the feedback loop with AI, not just the product. The same models that read your support tickets can read deployment notes, implementation call transcripts and scoping documents, and surface the recurring distance between what was promised and what was delivered. Truth latency is a data-routing problem, and it is now a solvable one.

The AI era sharpens both sides of this. Launch cycles are compressing, which makes latency more expensive per quarter, and competitors iterate on your positioning faster than you can correct it. At the same time, the evidence produced by delivery has never been easier to capture, structure and route. The organisations that win the next decade of product launches will not be the ones with the best launch narrative. They will be the ones that shortened the distance between a customer's Tuesday and their own roadmap.

The launch, redefined

Stop thinking of a launch as the moment your product meets the market. It is the moment your company meets its own assumptions, and pre-sales and services are the only functions standing where the two collide.

They are not the last mile of the launch. They are the instrument. Treat them as a cost centre executing a plan and you will learn what your customers think in eighteen months, from a churn report. Treat them as your primary sensor and you will learn it in three weeks, from a five-page note, while everything is still cheap to fix.

The product you launched is a hypothesis. The first ten deliveries are the experiment. Somebody in your building already wrote the results. Go and read them.

This article is adapted from edition #16 of my LinkedIn newsletter, Professional Services & Tech. Subscribe on LinkedIn to receive future editions.

Sources:

Pendo, "The 2019 Feature Adoption Report", based on feature usage across 615 subscriptions;
The Standish Group, CHAOS research on feature usage;
Gartner, "Survey Data: Gartner's Annual Product Manager Survey", on launch timeliness and internal launch targets.

---

Mathilde HENRY
Executive Leader in Enterprise Software & AI Transformation. 20 years at the intersection of software, consultancy and business transformation.