A while ago, I ran into a strange product problem.
A domain expert was convinced a capability existed. It was not some random nice-to-have either. From their perspective, it was a normal part of how the product should work. The expectation was so natural that there was no reason to question it.
The problem was that the product did not do it.
It had not been implemented. The developers did not think it had been implemented. Product did not have a clear shipped requirement proving it had been implemented. Yet somewhere between domain knowledge, previous conversations, interface expectations, and team memory, the feature had become real.
It existed everywhere except production.
Nobody was lying. Nobody was trying to hide missing work. Everybody was operating from a slightly different version of the product.
That is the uncomfortable thing: a team can be aligned in conversation while being completely misaligned with reality.
One Product, Several Realities
We talk about the product as if it is one stable object everybody can point at.
In practice, there are several versions of it living at the same time.
There is the product somebody intended to build. The product people discussed in meetings and Slack threads. The product that was actually specified in tickets and designs. The product that was shipped to production. And finally, the product that users and domain experts believe they are using.
Those versions overlap, but they are not the same.
A domain expert may describe a business rule as obvious because, inside the domain, it is obvious. Product may hear that as an accepted requirement. Design may represent it as the natural next state. Engineering may assume it belongs to another workflow or was intentionally left out of scope. QA may test the visible action without checking the downstream effect.
Then support explains the expected behavior to a user.
At every handoff, the statement sounds a little more official.
Domain expectation becomes meeting language. Meeting language becomes a summary. The summary becomes a ticket. The ticket becomes a partial implementation. The partial implementation becomes documentation. Documentation becomes user expectation.
At no point does somebody necessarily decide to invent functionality.
The gap forms gradually.
This is why “we discussed it” is not evidence that something exists.
Neither is “the ticket is done.”
Neither is “the interface suggests it.”
Neither is “the AI summary says this is how the workflow works.”
The Most Dangerous Product Assumption
We spend a lot of time worrying about assumptions around future demand.
Will users want this? Will this solve the problem? Will people understand the workflow? Will this move the metric?
Those are valid questions.
But I think the more dangerous assumption is often simpler:
What does everybody believe has already been built?
A future hypothesis still feels uncertain. People challenge it.
A belief about existing functionality feels settled. It moves into customer communication, onboarding, support instructions, roadmap decisions, and new requirements without being checked again.
That is where the situation becomes slippery.
The team is no longer debating the future of the product.
It is debating the present.
And once a team cannot agree on what the product currently does, every later decision becomes weaker. New work is planned on top of capabilities that may not exist. Bugs are reported against behavior that was never promised. Missing functionality is treated as a regression. A reasonable domain expectation becomes indistinguishable from a shipped feature.
The argument becomes emotional because everybody has evidence, but they are holding evidence from different realities.
One person has a memory of a meeting. Another has a completed ticket. Another has production behavior. Another has what the user was told.
All of them are real signals.
They just do not prove the same thing.
Assumption Debt
Technical debt is code that makes future change harder.
I think product teams also accumulate assumption debt: unverified understanding that makes every later decision less reliable.
Assumption debt grows in small, boring ways.
A meeting decision is not recorded clearly. Planned behavior is written as if it already exists. A completed ticket is confused with a deployed and verified capability. Product assumes engineering filled in missing domain detail. Engineering assumes missing detail was intentionally excluded. Old documentation survives after implementation changes.
None of these mistakes looks dramatic on its own.
That is why the debt is easy to ignore.
But it compounds.
An unverified assumption enters a specification. The specification creates a new feature dependency. A later team reads the documentation and treats that dependency as fact. Support explains it to customers. Product starts planning improvements to it. Engineering is eventually asked to fix something that was never there.
The cost is not only rework.
It is the loss of shared orientation.
Once assumption debt becomes large enough, the team starts building on folklore.
And folklore is a terrible source of truth for software.
AI Adds a Cushion to the Assumption
AI did not create this problem.
Teams misunderstood one another long before large language models arrived.
What AI changes is the amount of discomfort between not knowing and having an answer.
Before, incomplete context often looked incomplete. A messy meeting note looked messy. A vague ticket looked vague. Somebody had to stop and ask another question.
Now the gaps can be filled immediately.
A model can turn five fragmented notes into a confident workflow description. It can infer acceptance criteria. It can explain why a capability exists. It can generate test cases for behavior nobody actually agreed on. It can make the whole thing sound internally consistent.
The output may be coherent.
That does not make it true.
AI adds a cushion to the assumption. It smooths the edges that might otherwise force a team to stop and verify.
This connects directly to what I wrote in Up Is Not Up When You’re Stuck in an Avalanche. Polished output can create motion and confidence while moving a team further away from ground truth.
In this case, the danger is not a spectacular hallucination.
It is something quieter: synthetic reality.
A complete-sounding version of the product assembled from incomplete evidence.
Synthetic reality is persuasive because most of it may be correct. The names are right. The domain language is right. Most of the workflow is right. Only one crucial connection may be invented.
But one invented connection is enough to change what the team believes it has built.
Trace the Gap, Not the Blame
When this happens, teams often move quickly toward blame.
Who wrote the bad ticket? Who failed to implement it? Who told the adviser it existed? Who did not test it?
Those questions may matter later, but they are a weak starting point.
The better investigation is a trace:
- Where did the belief originate?
- Was it ever accepted as a requirement?
- What exactly was specified?
- What was implemented?
- What was deployed?
- What did production actually do?
- What did the user or domain expert experience?
- Which documents now describe the wrong reality?
This turns the situation from an argument about memory into an investigation of evidence.
It also exposes an important nuance.
Sometimes the implementation is correct according to the ticket and still wrong according to the domain expectation. Sometimes the domain expectation is completely reasonable but was never prioritized. Sometimes the interface creates a promise the backend does not keep. Sometimes everybody agreed on the idea but nobody agreed on the exact behavior.
There is no universal villain.
There is usually a broken chain between expectation and verification.
For important capabilities, teams need to be able to distinguish a few states clearly:
- Assumed — somebody believes the behavior exists.
- Planned — the behavior has been accepted for future work.
- Implemented — code exists for it.
- Deployed — the code is running in production.
- Verified — the production behavior was checked against the expectation.
Those words should not be interchangeable.
“Implemented” and “verified” are not the same state.
“Planned” and “available” are not the same state.
“Discussed” and “accepted” are not the same state.
A team should be able to say which one it means.
Product Alignment Needs Evidence
Alignment is often measured by whether everybody nodded at the same meeting or accepted the same ticket.
That is not enough.
Product alignment is not everybody agreeing with the same sentence.
It is everybody being able to trace that sentence to the same reality.
For a domain-heavy product, that trace is even more important. Business rules carry assumptions that feel obvious to experts and invisible to developers. Technical constraints create behavior that feels obvious to developers and arbitrary to users. Product sits between them, translating both directions while delivery pressure keeps increasing.
Without evidence, the translation slowly becomes folklore.
And once folklore enters tickets, documentation, onboarding, and AI context, it starts looking like architecture.
That is a dangerous transformation.
Closing
The feature everyone thought existed was not really one missing feature.
It was a warning that the team no longer had one shared map of the product.
The answer is not more documentation for the sake of documentation. It is not another generated summary. It is not a larger ticket template.
It is a clearer distinction between what was expected, what was decided, what was shipped, and what was verified.
AI can help organize that evidence. It can compare documents, surface contradictions, and ask where the trace breaks.
But it should not be allowed to turn missing evidence into confidence.
Because once an assumption becomes a requirement, and the requirement becomes documentation, and the documentation becomes user expectation, the feature starts to feel real.
Even when the code was never there.
Related field note
AI Can Help Product Discovery. It Cannot Do Product Discovery. separates evidence, inference, and invention—and looks at how AI can support discovery without manufacturing user truth.