From one sentence to a product: the first version of GEO
“Get the brand into the AI’s answer.”
That sentence can explain why I want to work on GEO, but it is not enough to define a product.
A one-sentence idea has no boundary. It can grow in any direction: a monitoring tool, a content generator, a brand knowledge base, a publishing platform, a reporting system, even a full marketing suite. Each direction sounds reasonable, but putting all the reasonable directions together does not automatically produce a reasonable product.
The hard part is choosing among them. Who does the first version serve? Which problem comes first? Which pieces have to connect, and which seemingly important abilities can wait?
Looking back, BeanInsight’s first version definition did not start from a feature list. It started from a series of scope cuts.
01 Who the first version serves
I did not start by defining it as a turnkey GEO SaaS for every enterprise.
The first version was more specific: it was a work platform for an internal GEO delivery team.
This decision matters. “Usable by every company” and “useful for a real delivery team” look like a one-line difference in audience, but they produce two completely different product priorities.
If the first version aims at a general SaaS, the product quickly fills with account systems, plan billing, permission matrices, template marketplaces, and configuration screens. They will be needed eventually, but they cannot prove that GEO’s core work actually holds up.
An internal delivery team faces more direct questions. Which questions to monitor today? Which AI answers expose a brand gap? What content to produce? Who reviews the article? How do we verify the result after publishing?
So the first version’s goal was not to acquire the most users. It was to let a real team run a complete delivery through it. Validate the workflow first, then decide if it should grow into a SaaS.
That was the first cut: serve a concrete person, not an imagined everyone.
02 What the first version has to prove
Once the user is set, the second question is: what does the product have to do to be useful?
Counting pages is a quick way to get a wrong answer. Brand pages open, articles generate, monitoring shows charts. None of that proves the product works. Each feature might just be an island.
In the first version spec, I wrote down the smallest closed loop:
Brand and questions → real monitoring → GEO opportunity → content → WeChat draft → human publish → re-measure and attribute
This became the earliest skeleton of the product.
Brand and questions define who we are working for and which user needs we are addressing. Real monitoring tells us what AI actually said. GEO opportunity turns observed gaps into a direction worth discussing. Content and publishing turn the direction into action. Re-measurement and attribution answer what happened after the action.
Without any of these, the loop breaks.
Content without monitoring leaves the team unable to explain why they wrote, or whether the writing changed anything. Monitoring without action turns the product into a dashboard that only raises problems. Publishing without re-measurement makes “done” a task status rather than real improvement in brand understanding.
So the first version’s success criterion was not a GEO concept demo. It was letting a new brand start from a question, collect traceable monitoring evidence, produce content, land in a WeChat draft, get human-published, and return to the same set of questions for re-measurement.
That was the second cut: prove one closed loop, not every possible feature.
03 Why start from questions, not articles
Among all entry points, article generation is the easiest way to make a product feel capable. Drop in a few sources, get a complete article, and the demo looks impressive.
I did not make “generate one article” the core task of the first version. Without a real user question, articles easily become unfocused content inventory.
GEO does not deal with abstract “brand exposure.” It deals with concrete questions: what the user is comparing, what they are worried about, what decision they are about to make. Only when the question is fixed do we know what to monitor, what the content should answer, and how later results can be compared.
The first version therefore required a brand profile and a question library before any baseline monitoring started. A question is not a sentence typed into a generator. It is a business object that runs through monitoring, opportunity, content, and re-measurement.
The same question leaves a full path: which AI answer it once received, whether the brand was mentioned, which GEO opportunity it formed, which article it later linked, and what changed after the article went out.
That is why, as the product kept evolving, I still treat the question library as the starting point. It is not another name for a keyword list. It is the anchor that keeps context across the whole GEO workflow.
That was the third cut: do not start from the most eye-catching feature; start from the object that connects the whole flow.
04 Why real answers must be preserved
The first version also made a non-trivial choice: monitoring must rely on the AI product pages real users actually use, not only on model API responses.
APIs are easier to integrate and easier to demo. But API output is not necessarily what users see on the real web page, with their real account and real search capability. Whether the platform turns on web search, which citations are shown, and how login state changes the result all matter.
If the product wants to answer “how does this brand perform inside AI answers,” it cannot quietly treat a different environment’s result as evidence from a real page.
So the first version included a Chrome browser extension. It runs monitoring on the AI platforms where the user is already logged in, captures answers and citations, and keeps API as an analysis, generation, and clearly-marked fallback path — never a substitute for real page observation.
This decision raised the implementation bar, but it protected the most important thing: the evidence boundary.
A failed real monitoring run cannot be recorded as “brand not mentioned.” An API fallback result cannot be merged into the same trend as a real page result. Only when we know how the data was produced do the later opportunities, content, and verification have a credible basis.
That was the fourth cut: rather admit something is temporarily unavailable than wrap different sources of evidence in the same kind of success.
05 Why the product stops at the WeChat draft
On the publishing side, the first version deliberately stopped at the WeChat official account draft box.
From an automation perspective, finishing the publish itself looks more complete. But before an article goes public, there are still facts, phrasing, imagery, account permissions, and brand risks to consider. Especially early in the product, I did not think a model-generated text was the same as a piece of content ready to be published.
So the workflow kept a human review step. After the content passed fact-checking and review, the system synced it into the specified WeChat draft box. The operator did the final check in the WeChat backend and decided whether to publish.
Only when the public URL and publish time were confirmed did the product treat it as a real publish and schedule a re-measurement.
This boundary makes the flow less “fully automatic,” but it makes responsibility clearer. The product can help generate, organize, and sync, but it cannot make the final brand judgment. A draft created does not mean the article has been published, let alone that AI has seen it.
That was the fifth cut: automate to the right level and leave the final decision to a person.
06 What the first version explicitly did not do
A product definition is not only “what to do.” It is also “what not to do.” The latter is often harder, because every deferred direction can be argued for.
The first version did not include a paid media marketplace, supplier inventory, or transaction settlement. It did not start with complex plan billing. It did not try to cover every content platform at once. It did not do unattended final publishing. It did not ship complex sentiment reports, sales-style diagnostic reports, or a white-label report center.
These are not worthless. They simply could not answer the most important question at that moment:
Can we use credible evidence to run an executable and re-measurable GEO improvement starting from one user question?
Without an answer to that, the more peripheral abilities a product has, the harder it is to see clearly.
The first version’s boundary was therefore deliberately tight: a small number of real projects, a limited set of platforms, a clear question library, one content and publishing path, and a verification mechanism that can return to the baseline.
07 The first version was not copied as-is, but the core question stayed
The product of course changed a lot after that.
Tech stacks shifted. Pages and domain objects kept being refactored. Monitoring had to distinguish different goals. GEO opportunity had to evolve from a simple anomaly into a verifiable improvement hypothesis. Publishing had to connect more channels and evidence. The knowledge base stopped being a place to upload files.
Many concrete plans from the first version did not survive. That is normal. A product definition is not an unchangeable blueprint. It is the answer to the most important question at the current stage.
But that minimal loop never disappeared: questions, monitoring, opportunity, action, publishing, verification.
Today’s BeanInsight covers more capability than the first version imagined. But when I judge whether a new feature is worth doing, I still return to the same test: does it make this loop clearer, more credible, and easier to run? Or does it only add another item to the menu?
08 What I learned from the first version definition
From one sentence to a product is not a matter of attaching a feature list. It is a series of trade-offs.
Serve a real delivery team first, not an imagined audience. Prove a verifiable loop first, not cover every module. Anchor the user question first, not chase content volume. Hold the real evidence boundary first, not chase pretty numbers. Reach the draft box and accept human review first, not treat automation as a goal in itself.
These decisions together make the first version definition of a GEO product.
Looking back, it is of course not perfect. But it confirmed one thing: a product’s first version does not need to explain the whole future. It only needs to turn the most critical assumption into a workflow that can really run and expose its own weaknesses.
The next step is to keep asking what this workflow actually serves.
When a user says “I want to be seen by AI,” do they want one mention, a nice-looking report, or to be understood, trusted, and finally enter the user’s choice? That is the question for the next article.