Alfred AnyanInsights
← All insights

Kofi’s obsolete product citation. Six weeks of runway put his proposal at risk.

A laptop on a sunlit office cabinet, ideal for professional or corporate contexts.

Photo by Jakub Zerdzicki on Pexels

When an AI answer cites a promise for a product you have already killed, correcting the old post is necessary but incomplete. The useful response is to preserve what you originally claimed, explain what changed, and show readers which promise the current product can still keep.

On Tuesday morning, I found our original launch language inside an AI-generated answer. The sentence was clean, confident and obsolete. It described the product we had intended to build, before customer conversations and shipped work pushed us elsewhere.

Imagine Kofi, a composite founder in Accra, reading that answer before a partnership call. He has six weeks of runway, a half-finished proposal open on his laptop and one decision to make: build around the capability the answer describes, or choose another supplier. If he trusts the citation and learns during the call that the product has changed, the proposal may collapse. Worse, he may conclude that we hid the change.

For a few minutes, I considered editing the old post until it matched the current product. That would remove the inaccurate sentence. It would also erase the decision that made the post worth reading.

The old promise contained useful evidence

Launch posts freeze a company at its most confident moment. They record what the founder believed customers wanted, what the team thought it could deliver and which uncertainty had been edited out of the announcement.

Our old promise had become wrong as a description of the product. It remained valuable as evidence of our reasoning.

That distinction matters because AI answers flatten time. A launch claim, a later product page and a retrospective can appear beside one another as if they describe the same moment. The citation may be technically faithful to its source while giving the reader a false picture of what exists now.

Deleting the original language would make the archive tidier. It would also hide the gap between our assumption and what we learned after shipping.

I have seen a related problem when an AI output looks plausible but conceals the step that produced it. In Youssef’s AI showed the wrong closing balance. Monday’s launch risked merchant trust., the dangerous part was the confidence of the result. Here, the confident result was ours, preserved in an old post and repeated without its history.

I chose an amendment over a quiet rewrite

I wanted the page to answer three questions plainly: What did we promise? Why did we stop building that version? What should a reader expect now?

So I left the original claim visible and added context around it. The correction needed a date, a clear statement that the product had changed and a short account of the decision behind that change. A reader arriving from an AI answer should be able to identify the mismatch without comparing several pages.

The harder part was explaining why we changed direction without turning the post into a victory story.

Product changes rarely arrive as one clean revelation. A capability takes longer than expected. A buyer values a narrower outcome. A workflow that impressed people in a demo fails to survive daily use. The founder then chooses between protecting the launch narrative and protecting the remaining runway.

That choice can still feel unresolved after the product changes. Killing a version removes its engineering cost, but it does not remove every promise attached to it. Those promises remain in screenshots, posts, sales decks and now AI-generated answers.

This is why a migration plan covers language as well as software. Kwame’s broken product promise affected customers directly. Our case started earlier in the journey, with a reader forming expectations before speaking to us. The trust problem was smaller, but the mechanism was the same.

Citations have turned old copy into product surface

Founders often treat archived marketing pages as finished documents. Search engines and answer engines treat them as available evidence.

That changes the cost of an abandoned promise. A claim can continue distributing itself after the team has stopped using it. The original page may rank because it is older, clearer or more widely linked than the correction. An AI system may then repeat the strongest sentence while dropping the paragraph that would qualify it.

The practical response begins with an inventory. Search the exact phrases used at launch. Check old posts, public documents, cached sales material and pages that compare the product with alternatives. Then decide what each page needs.

Some claims should be removed because they are simply false. Others deserve an amendment because the change teaches readers how the product evolved. A few may still describe the underlying job, even though the implementation changed. Those can be rewritten with a link between the old promise and the current one.

The goal is accuracy with a memory.

The next reader should see the decision

Later that morning, I returned to Kofi’s imagined proposal. In the revised version of the scene, he still finds the old citation. This time, the source tells him that the product changed and why. He may decide the current version does not fit his plan. That costs us a lead, but it prevents him from building a deadline around a capability we no longer offer.

Or he may see something more useful: a founder willing to show where the original reasoning failed.

That is the credibility I want an old launch post to carry. Not the appearance that every early prediction came true. A visible decision, made under constraint, with enough context for the next person to judge it.

On Tuesday afternoon, the original sentence was still there. Beside it sat the date, the changed promise and the reason we stopped trying to keep the old one.

Comments

No comments yet.