When search engines and AI assistants cannot explain what your company does, pause the feature roadmap and fix the product’s public meaning first. New features add little when customers, partners and machines cannot identify the problem you solve.
In 1985, Coca-Cola chairman Roberto Goizueta faced a problem in Atlanta that product testing had failed to predict. The company had replaced its original formula with New Coke after extensive taste tests, yet customers rejected the decision. The formula had tested well. The meaning attached to the old product had barely been tested at all.
The product can work while the explanation fails
Constance Hays documents the episode in The Real Thing: Truth and Power at the Coca-Cola Company. Coca-Cola had treated taste as the decisive variable. Customers were making a broader decision involving memory, identity and ownership of a familiar product.
The company brought the original formula back as Coca-Cola Classic roughly 79 days after introducing New Coke. That reversal became the useful part of the story. Management had enough evidence to launch a major change, then had to accept that its evidence measured only part of what customers valued.
My Tuesday version carried lower stakes, but the mechanism was familiar.
I checked how the company appeared outside the language we used internally. Search results could locate the site, but their descriptions did not give a clear account of the work. AI assistants produced answers that sounded plausible while drifting across several categories. One response emphasized technology. Another leaned toward consulting. Neither could state the customer, the problem and the outcome in a form I would have used in a sales conversation.
Two customer-facing features were already moving through the roadmap. Both had reasonable use cases. Both could have shipped.
I paused them.
The immediate constraint was no longer engineering capacity. It was interpretation. Shipping more surface area would give search engines, AI systems and potential customers more material to misunderstand.
A confused machine often reveals confused positioning
It is tempting to treat a weak AI summary as an AI problem. Sometimes it is. Models make errors, search indexes lag, and generated answers vary.
But repeated confusion across search results and multiple assistants deserves a harder question: what evidence did we publish that would let any reader reach the right conclusion?
A founder usually carries context that the website does not. I know why a feature exists, which customer request triggered it and which trade-off shaped the build. A visitor arriving from Accra, Lagos, Berlin or New York sees a homepage, a few page titles and whatever fragments a search engine selects.
If those fragments point in different directions, the visitor has to assemble the company’s position alone. Most will not.
This resembles a problem I have seen in product pitching. A founder describes the system, the integrations and the planned release, while the buyer is trying to decide whether one broken workflow will still be broken next month. The practical lesson from a broken order workflow applies here too: urgency becomes visible when the problem is named in the buyer’s terms.
Machines need the same basic clarity. They need consistent, explicit language about who the product serves, what it helps them do and what evidence supports that claim.
The audit starts with three plain answers
I would test the public story before rewriting every page.
First, ask a search engine and several AI assistants the same three questions: What does this company do? Who is it for? What problem does it solve? Save the answers without correcting them.
Then compare those answers with the sentence used in an actual customer conversation. Differences matter more than elegance. If the sales explanation says “we automate weekly reconciliation for small finance teams” while the website says “intelligent operational infrastructure,” the machines did not create the ambiguity. They exposed it.
Next, inspect the pages supplying the evidence. Titles, opening paragraphs, product descriptions, case studies and founder profiles should reinforce the same category and customer problem. They do not need identical wording, but they should not imply five different businesses.
Finally, delay additions that widen the story before the core description holds. A feature can be valuable and still make the company harder to understand. On limited runway, that cost belongs in the roadmap discussion.
This is the same discipline required when an AI product produces a confident answer that users cannot verify. In Youssef’s closing-balance problem, the launch risk came from trust, not the amount of code completed. Public positioning has a similar trust boundary.
Resume building when the explanation survives contact
The roadmap should restart when an unfamiliar reader can reach the intended conclusion from the published evidence.
That does not require perfect agreement across every model or search result. It requires a stable core. The company should appear in the right category, serve a recognizable customer and solve a problem specific enough to repeat.
New Coke passed the test Coca-Cola had designed. Customer rejection revealed that the test had excluded part of the product’s meaning.
A founder can make the same mistake with a roadmap. We test whether a feature works, whether customers requested it and whether the team can ship it. We sometimes skip the prior question: can anyone outside the company explain why this product belongs in their decision?
On Tuesday, the two features stayed paused. The next work item was smaller and less impressive: write the plain sentence, place it where people and machines could find it, then test whether they repeated it accurately.
Comments
No comments yet.