Day 130: Give Every AI-Facing Capability a Product State
A product page can be factually correct sentence by sentence and commercially wrong when summarised.
The page says one capability is generally available. Another works only on an enterprise plan. A third is open to a small pilot group. A fourth is planned for a future release. A fifth has been paused. A sixth has been replaced, although its original launch note remains accessible.
Then the page introduces all six in the present tense: “The platform automates reporting, supports regional analytics, connects to specialist data sources, forecasts demand, manages approval workflows, and exports legacy reports.”
Every phrase came from somewhere real. The combined description still turns six different product states into one apparently current offer.
For CMOs, Marketing Directors, and founders, that is a commercial scope problem. A buyer can build an enquiry, demo request, internal brief, or procurement assumption around work that is conditional, unfinished, unavailable, or no longer sold. An answer-led system may also summarise accessible product pages, documentation, launch notes, and status language under recorded conditions. It cannot see the private roadmap meeting that explains which verb still applies.
The fix is not more promotional copy. Give every AI-facing capability a product state.
A generalised page that promises six products at once
Consider a fictional B2B analytics platform. This is a generalised failure-mode illustration, not an observed buyer, client, company, or answer-engine result.
Its public footprint contains these statements:
- automated performance summaries are available across current paid plans;
- regional analytics are available only in selected markets and on an enterprise plan;
- a specialist data connector is being tested with a named pilot cohort;
- demand forecasting is listed on the roadmap;
- an approval workflow has been paused while the product team revisits its design;
- a legacy export function has been retired and replaced by a newer reporting route.
Each statement could be accurate in its original context. The problem appears on the main capability page. Its opening paragraph compresses the catalogue into a fluent present-tense promise, while the conditions sit in separate help pages, release notes, roadmap entries, and historical announcements.
A short synthesis could reasonably flatten the footprint into:
“The platform provides automated summaries, regional analytics, specialist connectors, demand forecasting, approval workflows, and legacy report exports.”
That sentence is not evidence that any real system would always produce the same wording. It shows the interpretation risk created by the page itself. “Provides” erases plan limits, pilot access, future intent, a pause, and a replacement.
The buyer then has to discover the truth after the claim has already shaped the brief. Sales may receive a demo request centred on forecasting that is not live. Procurement may compare the platform as if a pilot connector were standard scope. A delivery team may have to explain that a workflow is paused. These are plausible risks, not claimed outcomes. The point is that the public material makes the wrong interpretation easy.
Product truth needs a clock and a condition
A capability name answers only what the product may do. It does not answer when, for whom, or under which conditions the statement is true.
Those questions matter because product truth is temporal and conditional. “Supports regional analytics” may be accurate for one market, plan, or version and inaccurate for another. “Offers a connector” may mean generally available, available through a pilot, planned, or previously available. “Includes forecasting” may describe a roadmap intention rather than something a buyer can purchase today.
A useful lifecycle vocabulary can stay compact:
| Product state | What it should mean publicly | Safe buyer interpretation |
|---|---|---|
| Live | Available now within the stated normal scope. | The buyer can evaluate it as current, subject to the named plan or product terms. |
| Limited | Available now only under explicit plan, market, version, capacity, partner, or account conditions. | The buyer should check whether the stated condition matches their situation. |
| Pilot | Being tested with a bounded cohort; access and future availability are not assumed. | The buyer may ask about eligibility, but should not scope it as standard delivery. |
| Planned | Intended or being explored for a future point; not currently available. | The buyer should make today’s decision without treating it as committed scope. |
| Paused | Work or access has stopped pending a decision, redesign, dependency, or review. | The buyer should not expect delivery unless a new current status is published. |
| Retired or replaced | No longer offered in the old form; a successor or alternative route may exist. | The buyer should evaluate the current replacement, not the historical capability. |
These labels are not ranking markup. They are commercial language. Their value comes from helping a human or machine interpret the claim without inventing its lifecycle.
Build a capability-state record, not a larger feature list
The smallest useful record holds more than a badge beside a feature name.
For each buyer-relevant capability, preserve:
| Field | Question it answers |
|---|---|
| Capability | What exact function or service is being described? |
| Product state | Is it live, limited, pilot, planned, paused, or retired or replaced? |
| Conditions | Which plan, market, version, partner route, cohort, capacity, or other boundary changes the answer? |
| As-of date | When was this state last confirmed for public use? |
| Owner | Which product, service, commercial, or operational owner can confirm a change? |
| Safe next buyer action | Should the buyer evaluate now, check eligibility, request pilot information, wait, use a replacement, or exclude it from current scope? |
Applied to the fictional platform, the record changes the page from a vague catalogue into usable commercial truth:
- Automated summaries — Live. Current paid plans; confirmed as of 28 August 2026; compare plan detail.
- Regional analytics — Limited. Enterprise plan in named markets; confirm market and account eligibility before scoping.
- Specialist connector — Pilot. Named cohort only; ask about pilot criteria, not standard access.
- Demand forecasting — Planned. Not available today; exclude it from the current buying case.
- Approval workflow — Paused. No active availability; use the published alternative route where suitable.
- Legacy export — Retired and replaced. Evaluate the current reporting export instead.
The example date and capabilities are fictional. The pattern is the useful part: capability, state, condition, date, owner, and action stay attached to one another.
Keep confidential roadmaps private without hiding current limits
Explicit state does not require publishing confidential release dates, internal dependencies, technical architecture, or commercial negotiations.
“Planned; not currently available” may be enough. “Pilot access is limited to an approved cohort” can protect the cohort and selection process. “Paused; no current delivery date” gives the buyer the fact needed for today’s decision without exposing why the work stopped. “Limited to these markets and plans” reveals the commercial boundary without disclosing the machinery behind it.
The test is simple: could the missing detail cause a reasonable buyer to treat unavailable or conditional work as current scope?
If yes, the current limitation belongs in public decision material. The private explanation can remain private.
This is also why vague phrases such as “coming soon”, “available for selected customers”, and “supported in some configurations” need care. They indicate uncertainty without giving the buyer a safe action. A useful qualifier says whether the capability belongs in today’s evaluation and what the buyer should verify next.
Clear states support GEO, but they do not control answers
Accessible, useful, current product pages and documentation may inform how answer-led systems describe a company under particular conditions. Explicit lifecycle language can reduce the interpretation burden when current scope sits beside pilots, roadmap items, pauses, and historical material.
That is a bounded content hypothesis, not a guarantee.
State labels cannot guarantee inclusion, ranking, citation, recommendation, buyer behaviour, attribution, or revenue. Different systems may retrieve different material, use different contexts, or produce different summaries. A clear page also cannot erase every third-party description or historical trace immediately.
For Google AI features, the ordinary Search caveat remains. Google’s guidance points to core Search eligibility, usefulness, accessibility, and quality. It does not require llms.txt, special AI markup, arbitrary chunking, or over-focused structured data as switches for AI visibility. Product-state language should improve the underlying public account for buyers and ordinary Search, not masquerade as an AI-only technical tactic.
Run the present-tense test
Choose one product page, service matrix, integration directory, or capability overview and underline every present-tense verb: provides, supports, includes, connects, automates, works with.
For each verb, ask:
- Is this capability available now?
- Does plan, market, version, cohort, capacity, or partner route change the answer?
- Is the source describing a pilot, intention, pause, or historical release?
- When was the state confirmed?
- Who can confirm it again?
- What is the safest next action for a buyer reading it today?
Then rewrite the summary so unlike states cannot share one unqualified verb.
Do not turn the exercise into a maintenance campaign or a giant governance taxonomy. The objective is narrower: prevent non-current work from entering current commercial scope through compression.
A buyer should not need a demo to learn that the centrepiece of their brief is still planned. Sales should not have to translate “pilot” back out of “available”. Procurement should not compare a retired function as if it remains part of the offer.
Capability truth changes over time. Make the state travel with the claim.
If the capability is live, say so. If it is limited, name the condition. If it is a pilot, planned, paused, retired, or replaced, make that boundary visible before the buyer builds a decision around the wrong tense.