Building an Enterprise
Knowledge Ecosystem

Transforming fragmented product knowledge into a governed system for documentation, learning, search, contextual help, and AI-assisted retrieval.

Project Snapshot

The Challenge

Product knowledge was distributed across multiple knowledge bases, Confluence spaces, acquired product environments, and individual teams. Customers and employees needed reliable answers, but the information architecture and platforms had evolved separately.

The Approach

I developed a strategy that connected previously separate knowledge experiences. I led platform migrations and established the standards and access models behind the new architecture, then expanded it to support structured learning and contextual guidance. Search behavior provided an ongoing source of evidence for improving findability.

The Result

A governed knowledge ecosystem supporting customers, employees, and partners through more than 1,000 maintained articles, structured learning programs, contextual product guidance, optimized search, and reusable source content.

Metrics

1,000
Live knowledge articles
________

150
Learning videos
________

500+
Assessment questions
________

~40%
Increase in course completions

The Problem: Fragmented Knowledge

When I joined Kibo in 2020, I was initially assigned to documentation for Monetate, a recently acquired product whose customer-facing Zendesk content had become outdated.

The problem quickly proved larger than a documentation backlog.

Knowledge existed across Kibo, Monetate, and Certona in separate knowledge bases, Confluence spaces, and internal sources. The systems had grown independently, which meant customers and employees could encounter different structures, terminology, levels of detail, and publishing practices depending on where they looked.

Updating articles individually would improve the content, but it wouldn't solve the underlying problem.

| The organization needed a knowledge architecture, not simply more documentation.

From Repositories to a Knowledge Architecture

The first challenge was deciding how knowledge should be organized before deciding where it should live.

I evaluated knowledge-base platforms against the needs of the people who would use, maintain, and administer them. Search and usability mattered, but so did permissions, migration requirements, administrative control, vendor support, and cost.

After selecting Helpjuice, I planned the migration sequence, developed a documentation style guide, worked with a UX designer on the new experience, and audited migrated content rather than treating the move as a simple transfer from one platform to another.

The architecture continued to evolve as the organization changed. When Kibo and Monetate separated, the content needed to be divided into two knowledge bases without losing the structures and governance we had established. Later, performance and vendor-support issues with Helpjuice led me to reevaluate the platform itself.

I selected KnowledgeOwl as the replacement and led another migration, completed in February 2023. The new environment formalized the structure and governance we had been building:

defined information architecture and content organization
reader groups for different audiences
employee authentication and internal-only content
metadata and tagging conventions
parent-child content relationships
documentation standards and reusable publishing practices
governance for ongoing releases, reviews, and updates

The goal wasn't to create a perfectly organized repository at a single point in time. It was to create an architecture that could continue working as products, audiences, and organizational needs changed.

| Design principle: Structure knowledge for change, not just for the environment that exists today.

More about the knowledge-base migrations

The knowledge platform changed twice during my time at Kibo. Each decision was based on the needs and evidence available at the time.

Helpjuice initially provided a way to consolidate content that had been distributed across Zendesk, WordPress, and other sources. I compared platforms and costs, coordinated the migration plan, established documentation standards, and worked with UX on the customer-facing design.

As the environment evolved, Helpjuice's performance and vendor-support limitations became increasingly significant. Rather than continuing to work around those problems because we had already invested in the platform, I reopened the evaluation process.

I selected KnowledgeOwl and led the transition while preserving the information architecture, governance practices, and content improvements we had already established. The migration was completed in February 2023.

The experience reinforced an important part of platform ownership: a technology decision isn't permanent simply because you were the person who made it. New evidence should be allowed to change the decision.

Designing for Findability

A knowledge base only works if people can find the right information when they need it.

Once the content architecture was established, I began treating search quality as something that could be deliberately designed and continuously improved.

I started with the search configuration, adjusting how the system weighted content and handled typos or variations in phrasing. A synonym dictionary and in-app glossary helped bridge differences in terminology, while stronger titles and metadata gave the search engine better signals to work with.

But configuration was only part of the work.

I reviewed search behavior monthly, paying particular attention to zero-result searches and the terms people actually entered. I also compared those patterns with support trends to identify places where customers were struggling to find an answer, where existing content needed improvement, or where a knowledge gap existed.

Search data became another form of user research.

| Design principle: Don't require users to know our terminology before they can find an answer.

More about improving search quality

Search optimization was an ongoing process rather than a one-time configuration task.

I used KnowledgeOwl's search controls to adjust how different content elements influenced results, including search weights, typo tolerance, and phrase matching. I maintained synonyms so that different terms for the same concept could lead users toward relevant content, and I used glossary functionality to help establish consistent terminology.

Each month, I reviewed search analytics to identify patterns such as frequently used queries and searches returning no useful results.

A zero-result search didn't automatically mean we needed a new article. Sometimes the content existed but used different terminology, weak metadata, or a structure that made it difficult to retrieve. Other times, the search exposed a genuine gap.

Those signals helped me decide whether the answer was new content, a revision, better metadata or synonyms, or a change to the search configuration.

I also reviewed support trends quarterly. When search behavior and support questions pointed toward the same problem, that gave us stronger evidence that the issue represented a genuine knowledge need rather than an isolated query.

Extending Knowledge Into the Workflow

Improving search made the knowledge base easier to use, but it still assumed that someone would stop what they were doing, open the help center, and look for an answer.

Some knowledge could be delivered closer to the moment of need.

Using Product Fruits, I helped create contextual guidance within the product experience, including walkthroughs, tips, and links to relevant help content. I mapped in-product guidance to governed knowledge-base articles and categories rather than creating a separate body of disconnected instructional content.

That distinction mattered.

When the underlying guidance changed, the knowledge base could remain the authoritative source while the product experience directed users toward the appropriate information.

This extended the same knowledge architecture into another delivery channel without creating another source that had to be independently maintained.

| Design principle: Move knowledge closer to the work without creating another source of truth.

Building a Learning System, Not a Course Library

Documentation could help someone solve a specific problem, but some users needed a more structured way to develop knowledge over time.

I evaluated several learning-management platforms, including TalentLMS, Docebo, and Absorb. The decision had to account for more than features and cost; administration, reporting, and the needs of different learner populations would determine whether the platform could support the program over time.

The challenge wasn't simply producing training content. We needed a learning architecture that could serve customers, employees, and partners with different goals and levels of product knowledge.

I structured the Academy into three branches for those audiences and developed learning paths that included full-stack, feature-specific, and developer-focused certification. Employee learning also supported role-specific onboarding for teams including Sales, Development, and Support.

The content itself was designed for reuse. Courses, videos, and assessments could be organized into different learning paths rather than recreated whenever audiences shared the same underlying knowledge.

Over time, Kibo Academy grew to approximately 150 videos and more than 500 assessment questions, with about 200 unique learner logins per month.

| Design principle: Build learning around what people need to accomplish, not around how much content you can produce.

More about the learning architecture

Kibo Academy needed to support multiple audiences without requiring completely separate course libraries.

I used TalentLMS branches to create distinct experiences for customers, employees, and partners while reusing appropriate learning content across them. Modular course design allowed common material to serve as building blocks for different learning paths and certifications.

Certification paths could then be assembled around different goals. A learner who needed broad product knowledge could follow a full-stack path, while someone focused on a particular feature or development work could follow a more specialized sequence.

Assessments were also treated as part of the learning system rather than simply as completion gates. The Academy eventually contained more than 500 assessment questions. I reviewed learner feedback and performance and adjusted requirements, including pass scores, when the evidence indicated that the learning experience needed refinement.

I also used AI-assisted workflows to accelerate parts of assessment development. Transcript content could be used to generate candidate question and answer options, which I then reviewed, refined, and organized before publication.

The goal was to reuse knowledge intelligently while still giving each audience a learning experience appropriate to its needs.

Example: Designing a Certification Path

A certification wasn't simply a collection of available courses. I designed paths around the knowledge and capabilities someone needed for a particular role or objective.

I started with the knowledge and capabilities required at the end of the path, then worked backward. Existing modules could be reused where they fit, prerequisites established the sequence, and assessments verified understanding before learners progressed or completed the certification.

Because learning components were modular, the same course could contribute to more than one path without maintaining duplicate versions. Changes to shared material could therefore flow into the learning experiences that depended on it.

This approach allowed the Academy to support broad product certification, feature-specific learning, developer education, and employee onboarding while maintaining a manageable content system.

Preparing Knowledge for AI-Assisted Retrieval

As AI-assisted search and chatbot capabilities became part of the knowledge experience, the quality of the underlying source content became even more important.

Many of the practices that improved traditional search turned out to matter for semantic retrieval as well. Clear structure and consistent terminology gave the system better source material to work with. So did useful metadata, well-scoped articles, and content that was actively maintained.

My role wasn't to build the AI technology itself. I focused on the knowledge layer it depended on.

I optimized content for both keyword and semantic retrieval and tested chatbot responses against the governed knowledge base. When an answer was incomplete, misleading, or difficult to retrieve, I could investigate the source content and determine whether its structure, terminology, metadata, or coverage needed improvement.

This changed the way I thought about knowledge quality. Content no longer needed to work only when a person navigated to and read an article. It also needed to function reliably as source material when another system retrieved and synthesized that knowledge.

| Design principle: AI can only retrieve trustworthy knowledge if the source itself is trustworthy.

Leading the Knowledge Program

As the knowledge program expanded, my role grew from creating documentation to leading the people, platforms, standards, and processes behind it.

I managed a four-person documentation team, including hiring and performance management. I set goals and priorities while also focusing on longer-term career development. That included creating a career path for the team, supporting promotions and compensation changes, and mentoring writers as their responsibilities grew.

I also owned major knowledge-platform decisions and coordinated documentation work with product releases. Biweekly release cycles required us to identify affected content, plan updates alongside development work, and keep customer-facing guidance aligned with the product.

Quarterly audits provided a second maintenance rhythm, giving us a structured way to identify outdated or underperforming content beyond immediate release changes.

The work increasingly became less about managing individual deliverables and more about keeping the entire system working. People and platforms mattered, but so did governance, workflows, analytics, and the content itself.

| Knowledge management became an operating discipline rather than a publishing function.

Results

1,000+ live knowledge articles
A governed content system supporting customer and internal knowledge needs.

500+ assessment questions
Supporting certifications, learning paths, and knowledge verification.

150 learning videos
Structured into reusable learning experiences for customers, employees, and partners.

~40% increase in course completion
Following improvements to the Academy experience and learning program.

What changed

Knowledge became easier to maintain.
Content standards, information architecture, governance, and reusable structures replaced a more fragmented approach to managing product knowledge.

Search became a source of user insight.
Search configuration, synonyms, zero-result analysis, and support trends created an ongoing feedback system for improving findability and identifying knowledge gaps.

Learning became a structured system.
Customers, employees, and partners could follow learning paths designed around their needs while shared content could be maintained and reused across audiences.

Knowledge moved closer to the point of need.
Contextual product guidance connected users to governed source content without creating another independent body of documentation.

The knowledge system became better prepared for AI-assisted retrieval.
Structured, maintained source content could support both traditional search and emerging semantic-search and chatbot experiences.

Reflection

The most important lesson from this work was that knowledge management isn't primarily about managing content.

Content was the visible output, but much of what determined whether it worked happened around the content. Information architecture affected where it lived. Governance determined how it stayed current. Search behavior showed whether people could find it. Platform decisions, learning design, analytics, and the people maintaining the system shaped everything else.

The work also changed how I thought about findability. A technically correct article isn't useful if someone can't locate it, doesn't recognize the terminology, or encounters it too late to help. Search analytics, support patterns, contextual guidance, and learner behavior all provided evidence about whether the knowledge system was actually working for the people who depended on it.

The emergence of AI-assisted retrieval reinforced the same lesson rather than replacing it. New technology could provide another way to reach an answer, but it increased the importance of having accurate, structured, maintained source knowledge behind that answer.

By the end of the project, I was no longer thinking about the knowledge base, Academy, contextual guidance, search, and AI retrieval as separate initiatives.

They were different ways of connecting people with trustworthy knowledge at the moment they needed it.

A knowledge system isn't successful because it contains the answer. It's successful when people can find that answer, trust it, and use it to accomplish what they came to do.

_____________________________________________________________________________________

Explore Another Case Study

Redesigning a Complex Metadata Workflow →

Google Sites

Report abuse

Building an Enterprise Knowledge Ecosystem