![](\"https:\/\/www.intercom.com\/blog\/wp-content\/uploads\/2026\/06\/Two-ways-to-handle-a-product-launch-scaled.png\")
<\/p>\nWhen you work at a company that\u2019s constantly shipping new product features, keeping your knowledge base up to date can be a challenge.<\/p>\n
When you\u2019re using an AI Agent, the consequence of having an out-of-date knowledge base is high. It means every time the product team ships a new feature and customer questions start to land, the Agent doesn’t have the information it needs to answer. It hands conversations off to a human, and within hours, your team is fielding a backlog of questions the Agent should have handled, right when volume is at its peak.<\/p>\n
Over time, your customers start to lose trust in the Agent, and your team loses the capacity it was supposed to gain.<\/p>\n
Making sure your Agent is ready for every product launch comes down to following a process that updates your knowledge as part of every new release. At Fin, we call this our \u201cnew product introduction\u201d (NPI) process. Here\u2019s what that looks like.<\/p>\n
<\/p>\n
If you\u2019re relying on your customers to find your content gaps and then racing to fill them, you\u2019ll always be one step behind. A more productive approach is to move Agent readiness upstream into the launch process itself. A feature should only be considered \u201cshipped\u201d when the Agent can answer questions about it correctly.<\/p>\n
One of the most important changes you can advocate for is getting support involved in the launch planning as early as possible. Have someone from your team join product and engineering walkthroughs and product marketing kick-off calls, and test the new features before they ship.<\/p>\n
This level of involvement helps catch bugs and unexpected behavior early and gives your team a firsthand understanding of how the feature actually works. It also makes it easier to see what existing information needs to be deprecated, so you can retire old content as you make updates. At Fin, this is what I take on as our new product introduction (NPI) Manager, but a knowledge manager or support lead could own this too.<\/p>\n
The closer support is to product and marketing, the faster Agent readiness becomes a natural part of how launches get done.<\/p>\n
Getting your Agent ready ahead of a launch requires you to prepare new content, review what exists and remove anything outdated, and test how your Agent performs before customers start interacting with it post-launch. As NPI Manager, I oversee this process at Fin. However, you could split this responsibility up across the team. Your knowledge manager might own the preparation and review stages, while a QA manager runs testing.<\/p>\n
Here\u2019s a checklist for areas to work through at each stage.<\/p>\n
![](\"https:\/\/www.intercom.com\/blog\/wp-content\/uploads\/2026\/06\/NPI-Checklist-scaled.png\")
<\/p>\n
As you prepare new information for your Agent to learn about your latest launch, you need to ensure your content is as clear and easy to follow as possible. The quality and structure of these articles will be the biggest determinant of how well your Agent answers questions.<\/p>\n
As you draft content for the launch, write in your customers\u2019 language rather than just your internal terminology. For instance, your product team might call a new feature \u201cautomated workflow triggers,\u201d but your customers are searching for \u201chow to set up automatic replies.\u201d Use the language your customers will actually use alongside feature names so it\u2019s surfaced properly when they ask about it.<\/p>\n
Your Agent reads content literally, so make sure your writing is easy for it to understand. Explain internal nuance, spell out acronyms, and define key product terms. If you feed the Agent vague or ambiguous language, it\u2019ll return answers that your customers might find confusing.<\/p>\n
Don’t assume your Agent can infer meaning the way a human reader would. If you’ve just launched a new feature on a specific plan and a customer asks whether they have access, a one-line “it depends on your plan” isn\u2019t enough. The Agent needs the full picture: which plans include the feature, what it does, how to access it, and any setup steps required. Write every answer as if your Agent has no surrounding context, because it doesn\u2019t.<\/p>\n
Your Agent can\u2019t rely on visuals alone. Always pair product screenshots, GIFs, or video walkthroughs with clear written steps covering the same ground.<\/p>\n
Once you\u2019ve mapped out all the new content you need to support the launch, review what\u2019s already in existence, what you\u2019ll need to update, and what you\u2019ll need to remove from your knowledge base entirely.<\/p>\n
Search for every article, macro, or any other piece of content related to the launch topic. If your knowledge management tooling can flag stale or contradictory content automatically, use that to speed up the process.<\/p>\n
If the same topic has more than one article, confirm the canonical source is the one you want your Agent using. An outdated duplicate will compete with your new content and introduce inconsistency.<\/p>\n
Before the feature officially ships, test how your Agent handles the new content so you can catch and fix problems before they reach customers.<\/p>\n
Use your knowledge management tooling to generate likely FAQs from your new launch content and fold in any beta feedback or early support conversations if available. These reflect real customer language, not just what you think people might ask. Test how your Agent responds to these in the same environment your customers will use. Rate each answer, and if the results are poor, identify what the root cause is. It\u2019s likely there\u2019s still a content gap, the information exists but it\u2019s inaccurate, or it exists but is too poorly structured to be retrieved. Apply each fix accordingly and then run the tests again.<\/p>\n
Before you go live, check whether the launch introduces nuances the content alone can’t cover \u2013 for example, if a feature is being rolled out to customers in stages, or if specific queries should always route to a human. If the launch has no such conditions, you can skip this step.<\/p>\n
Decide which metrics you\u2019ll monitor on the launch topic. Start with resolution rate and customer satisfaction score, at a minimum. This will help you catch problems as soon as they surface, rather than discovering them later in aggregate.<\/p>\n
Ahead of a launch, product managers and engineers submit their new feature along with a \u201cwhat we built\u201d doc to our product release tracker. This captures who built and manages the feature, beta start date, planned release date, plan availability, product description detailing how it works, and troubleshooting guidance.<\/p>\n
Our knowledge managers and I are then looped into calls and Slack threads with the product and engineering teams early to understand the product changes, including walkthroughs and demos. We\u2019re also invited to GTM kick-off meetings to align on messaging and rollout strategy. Any notes, demo summaries, or GTM briefs from these sessions are captured and combined with the \u201cwhat we built\u201d doc as a single input package for content.<\/p>\n
Fully equipped with this input package, we upload it to Operator<\/a>, our Agent that builds, tests, and ships improvements to Fin on our behalf, with a prompt such as: This prompt helps us identify what existing content needs updating, what Fin might answer incorrectly if it\u2019s only pulling from existing material, and where there are gaps that we need to fill. We then follow up with a secondary prompt that asks Operator to take action and draft new public-facing content and internal guidance for teammates:<\/p>\n Note:<\/strong> If you\u2019re using Fin, here\u2019s a full guide<\/a> to using Operator for knowledge management, including setup, prompts, and the content readiness framework.<\/p>\n![](\"https:\/\/www.intercom.com\/blog\/wp-content\/uploads\/2026\/06\/Fin-Operator-prompt.png\")
<\/p>\n\n
\n