A customer asks whether cancelling their subscription deletes their data. Your help centre says one thing. An old support reply says another. The product behaves a third way.
A product manager should treat that mismatch as a product defect. The customer needs a dependable explanation before making a decision, whether they read a page, ask a support agent, or delegate the question to software.
Knowledge belongs in the product contract: the expectations people can reasonably form about what a product does, who can use it, and what happens next. I mean an operational promise here, not a claim about legal obligations.
That makes maintaining company knowledge a product-management responsibility, even when someone else owns the publishing system.
What the knowledge-engineering argument gets right
Hahnbee Lee’s post on knowledge engineering describes a shift from publishing accurate pages to maintaining systems that keep information accurate, accessible, and consistent. The canonical Mintlify article, credited to David Isquick, makes the responsibilities concrete: authoritative sources, named owners, release-linked updates, permissions, and measurement of unanswered questions and retrieval failures.
I’m using “knowledge engineering” in that operational sense. This is about maintaining information people and agents can rely on; it does not require a knowledge graph or a new job title.
The attention-grabbing number needs care. Mintlify reports that agents accounted for 66% of measured web traffic across its documentation platform in July 2026. Its underlying traffic report, published before the month ended, describes July-to-date activity. It compares classified agent web requests with human client-side page loads, excludes MCP calls from those web totals, and explains limitations in identifying visitors.
That is a vendor observation about Mintlify-powered documentation. It does not establish agent share across the web, customer adoption, successful tasks, or sales. Mintlify also notes that failed retrieval can generate extra requests. More traffic can mean more wasted work.
My PM conclusion is narrower: wherever customers or their agents depend on product information, teams should test whether that information supports the decision they need to make. The operating model below is a proposal, not a result demonstrated by Mintlify’s traffic data.
Add knowledge changes to the release scope
A release changes more than code when it changes the answer to a customer’s question.
Eligibility rules, usage limits, cancellation behaviour, migration steps, and feature availability all deserve an explicit knowledge-impact check. A working feature with an obsolete explanation can still produce a failed customer experience.
For each affected answer, put a small record alongside the release work:
- Authoritative source: Where is the approved rule or verified behaviour recorded?
- Accountable owner: Who resolves contradictions and signs off on the answer?
- Affected surfaces: Which help pages, in-product messages, support replies, and agent retrieval paths depend on it?
- Applicability: Which customers, versions, regions, and effective dates does it cover?
- Verification: How will the team check that a person or agent gets the right answer?
An authoritative source need not mean one enormous document. Engineering may own the API schema while product owns eligibility policy. The important part is deciding which source governs each claim and what happens when policy and implementation disagree.
“Last edited yesterday” is weak evidence of accuracy. Tie review to the change that could invalidate the answer. A release, policy decision, or support escalation should trigger review of its dependent content.
Work through a cancellation-policy change
Consider a hypothetical subscription analytics product. The team changes its cancellation policy so that eligible customers can export reports for 30 days after cancellation. Previously, access ended immediately. Older accounts remain on the previous policy until their renewal date.
Those details are invented for this example. They show why “update the cancellation FAQ” is an incomplete release task.
The PM records the approved policy, effective date, eligible account cohort, and exceptions. Engineering confirms that the access-control behaviour matches it. Support identifies the questions customers are likely to ask, including “Can I still export?” and “Why does my colleague have access when I don’t?”
The public page explains both policies and how to determine which applies. An authenticated assistant can use an authorised account lookup to establish eligibility. A public assistant without that information should explain the distinction and direct the customer to an appropriate check, rather than guess.
The team then updates the cancellation screen, help article, support macro, and machine-readable documentation. It checks search results and retained copies for the obsolete claim that access always ends immediately. Historical material may remain useful, but it needs a clear date and applicability boundary.
Release acceptance should include observable behaviours:
- An eligible customer receives the correct export window and instructions.
- A legacy customer receives the applicable policy, not the newer promise.
- A question without account context produces a conditional answer or a request to verify eligibility.
- A user cannot retrieve another customer’s cancellation details.
- A conflicting or unavailable source produces an honest limitation and escalation path.
If the system cannot distinguish the cohorts safely, the team should restrict automated answers for that question until it can. A confident wrong promise is a poor substitute for a bounded handoff.
Share the work without blurring accountability
Assign one person to coordinate the knowledge system, then give the domain decisions to people with authority to make them.
Product owns the intended customer promise. The PM identifies changed rules, affected journeys, and launch risks. They resolve ambiguity about what the product is supposed to offer and make room for knowledge work in release scope.
Engineering owns verification against the implementation. Engineers check that examples run, limits match enforcement, and retrieval respects access controls. They also help connect source changes to review tasks, rather than relying on someone to remember every affected page.
Support owns a structured feedback route from real questions. Support contributes misunderstood terminology, missing exceptions, and contradictions seen in conversations. It should have a clear path to an owner who can correct the source, instead of maintaining an unofficial competing policy in macros.
A writer, product educator, or knowledge engineer can coordinate structure, reviews, and distribution. That person needs authority to request corrections and flag release risk. Making someone accountable while leaving every contributing team free to ignore them is an organisational dead end.
Permissions belong in this arrangement from the start. Specify what is public, employee-only, or customer-specific, and test those boundaries through the actual retrieval path. A warning inside a document is not an access-control mechanism.
Measure answered questions, not published pages
Start with a representative set of customer questions from the journey you are changing. Include common requests, expensive misunderstandings, ambiguous phrasing, outdated assumptions, and attempts to access restricted information.
For each question, record the expected answer or refusal, the governing source, and the context needed to answer. Evaluate retrieval and the final response separately. Finding the right document does not establish that the answer applied its conditions correctly.
A useful scorecard would track:
| Measure | What to check |
|---|---|
| Retrieval failure | Did the system miss an available, authorised source needed for the question? |
| Answer correctness | Did the response match the approved rule and its exceptions? |
| Unsupported certainty | Did it invent an answer where evidence or account context was missing? |
| Update delay | How long did an affected surface remain stale after the change took effect? |
| Permission failure | Did any response expose information the requester could not access? |
Define denominators and severity before turning these into percentages. A suite dominated by easy questions can conceal a serious cancellation-policy failure. Track critical cases individually, and set release gates according to customer harm rather than borrowing an arbitrary industry target.
Run the questions before release, after publication and indexing, and when support uncovers a new failure. Keep sensitive customer information out of shared evaluation logs unless there is an approved reason and access policy for retaining it.
Improve the information before adding another channel
Mintlify’s article lists Markdown, llms.txt, APIs, and MCP tools as ways to publish or expose knowledge. These are delivery options. None guarantees that a rule is current, that an agent will select the right source, or that the answer will respect permissions.
Give people explanations of choices and consequences. Give agents explicit conditions, terminology, examples, and applicability. Derive both from the same approved decisions where practical, and test the paths your customers actually use.
For the next release that changes a customer-facing rule, choose one affected journey. Name its source and owner, map its dependent answers, and add a small evaluation set to release acceptance. After launch, use failures to decide what to fix next. Expand the process when that loop works; a company-wide documentation migration can wait.
Sources
- Hahnbee Lee’s knowledge-engineering post, September 17, 2026. Starting point for the topic.
- David Isquick, “Rise of the Knowledge Engineer,” Mintlify, September 16, 2026. Vendor perspective on responsibilities and ownership; the canonical article is credited to Isquick, not Lee.
- Mintlify, “The state of docs traffic: a 2026 midyear report”, July 29, 2026. Source and methodological caveats for the platform-specific traffic observation. The operating model and hypothetical example above are this article’s analysis.