“But we’ve done this before.”
That sentence ends a surprising number of product arguments inside mature companies.
A large customer needed something unusual. The company assembled the right people, created a custom extract, added a manual review, wrote a small integration, escalated the exceptions, and delivered the result.
The customer was satisfied. The organization recorded a success.
Then the next product plan quietly converts that success into a capability assumption.
Possible is not the same as repeatable
An outcome achieved once is evidence of possibility. A capability exists only when the organization can produce that outcome reliably enough to depend on it.
Those are very different standards.
A useful progression is:
We have done it → We can do it → We can repeat it → We can scale it → We can productize it.
Companies routinely jump from the first statement to the last.
The missing steps are where most of the risk lives.
What looked like “the system supports this” may actually have been a system plus a spreadsheet, a specialist, an account manager who remembered a customer preference, and an executive sponsor who personally cleared two blockers.
From the customer’s perspective, it worked. From inside the company, the outcome may have been fifty-five percent capability and forty-five percent scaffolding.
Exceptions create organizational memory
Successful exceptions are especially dangerous because they leave behind a story: we can do that.
The mechanics disappear from memory faster than the result.
A strategic customer asks. The company cannot quite do it. People invent a workaround. The outcome succeeds. The workaround becomes familiar. The next customer is promised the same thing. More manual machinery accumulates around the promise.
Eventually the Stack becomes a fossil record of things the company once said yes to.
That weird integration may exist because of a customer from six years ago. The nightly reconciliation may be compensating for a decision made during an acquisition. The spreadsheet may be the only place where a rule actually survives. Nobody designed the whole structure. It accreted through promises.
The test is customer number two
The most revealing question is not whether the first case worked.
Ask: What would make customer number two easier than customer number one?
If the answer is “we now know who to call,” that is learning, but not yet much capability.
If the answer is “the decision rule is maintained, the input is available through an owned interface, the exception path is defined, and ordinary operators can run it,” the company has changed.
That change is a Stack Delta.
The distinction matters because one-off success can fool a roadmap. A future product is then designed on top of capabilities that exist only under concentrated attention. When volume arrives, the organization discovers that the platform assumption was actually a heroics assumption.
Count the hidden machinery
Before treating an old success as proof of readiness, reconstruct it.
Who touched the work? Which systems were used? Which data was copied somewhere else? Which decisions required judgment? Who had authority to override the normal process? Which customer-specific knowledge mattered? What happened when something failed?
Then remove the names of the people from the story and ask what remains.
This is not an argument against custom work. Custom work is often exactly how a company learns what the future capability needs to become. The mistake is confusing a successful experiment with an operating capability before the scaffolding has been made visible.
“We did it once” is useful evidence.
It is the beginning of the capability discussion, not the end.
Adapted from PRODUCT PATH: How to Build What Your Company Isn’t Ready to Build by Alex Vale, published by Interoperability Press. Read Product Path.