I help teams turn complex software into products people enjoy using.

FocusVision supported three distinct software product lines: a web survey platform, a panel management platform, and a qualitative focus group diary platform. One knowledge base served all three products, built when the portfolio was smaller. Roughly 1,000 articles supported three products against a team sized for one — a ratio that made proportional coverage structurally out of reach.

The problems compounded each other. Coverage was thin relative to three separate products. The documentation set had grown organically, ahead of any shared style guide or template system. Nothing existed to keep published articles current as the products changed. The practical result was that the support team was carrying volume that a fuller self-service resource could absorb.

• Redesigned the knowledge base and the documentation processes behind it, addressing both the structure of the content and the workflows that produced it.
• Created a style guide and a set of article templates to establish consistent structure, voice, and quality standards across all three product lines.
• Sourced additional writing support from the support organization, recruiting support agents into the documentation effort to expand capacity without waiting on headcount.
• Established a content refresh program that brought engineers, product managers, support agents, and technical writers together for a weekly review of existing articles.

The documentation set grew substantially over two years, with the quality of existing content improving alongside the expansion. The knowledge base became a resource clients and staff genuinely relied on to self-serve, and the cross-functional refresh program gave the content a maintenance model that didn't depend on any one person.

FocusVision acquired a new software platform that arrived as a pair of products, with two very different documentation situations. Documentation had not yet been built for one of the two products. The other came with an established knowledge base built in Freshdesk, managed by support agents and entirely separate from FocusVision's primary knowledge base in MindTouch.

This left the company maintaining customer-facing documentation across two platforms with two sets of standards. The documentation set was growing faster than the existing team could absorb, and the team had no structure for distributing that work.

• Migrated the acquired content into the primary knowledge base, consolidating customer-facing documentation onto a single platform and a single set of standards.
• Made the case for and hired two additional technical writers, expanding capacity to match a documentation set that had grown well beyond what the existing team could sustain.
• Took ownership of the technical writing team and established mentorship as part of how the team operated, moving from individual contribution into leadership.

Customers gained one authoritative knowledge base instead of a fragmented set of destinations, and the documentation organization had the capacity to support the expanded product portfolio. The team grew into a structured group with defined ownership and an internal development path.

FocusVision merged with a larger market research firm that brought with it a new software platform and another established knowledge base. That knowledge base was maintained by two technical writers as a wiki-style menu embedded inside the platform itself.

Documentation now lived across multiple platforms in multiple formats, each with its own authoring approach and its own publishing constraints. No single tool let writers manage the full documentation set, which made consistency, reuse, and shared ownership effectively impossible. Meanwhile, the merged customer base raised expectations for both coverage and quality, and the web academy needed dedicated ownership the team wasn't yet staffed for.

• Researched authoring solutions capable of supporting a documentation set of this size and complexity, and selected MadCap Flare as the best fit for the organization's needs.
• Built the supporting infrastructure: set up a Git repository for version control and collaborative authoring, and procured the necessary publishing licenses from MadCap.
• Connected each existing doc set into Flare, giving the technical writers one environment from which to manage content originating across several different platforms.
• Hired four additional technical writers to support the expanded documentation set.
• Hired two instructional designers to take ownership of the company's web academy, establishing learning content as a discipline distinct from technical documentation.

The combined organization moved from several disconnected documentation systems to a single authoring and publishing toolchain with proper version control. The team scaled from two technical writers to eight content professionals across two disciplines, with clear ownership of both product documentation and customer education.

When I joined 6sense, the knowledge base was hosted on WordPress, which wasn't built for this kind of content. The platform problem was the visible one, but it wasn't the whole picture.

Content ownership was concentrated in two writers covering customer-facing documentation, while in-app content had no dedicated discipline behind it. There were no style guides for either surface, no article templates, and no defined path for the rest of the organization to request documentation updates. Content practitioners sat at a distance from the product managers, engineers, and designers whose work they documented, and technical writing had not yet been integrated into the software development lifecycle.

Migrated to a dedicated content management system

• Evaluated purpose-built alternatives against maintenance overhead, authoring workflow, and search performance, and piloted Document360 against real content to validate the fit.
• Used the pilot results to build the case with the leadership team, then procured Document360 and migrated the full documentation set onto it.

Built the team and established two disciplines.

• Hired two additional senior-level technical writers to own product documentation.
• Took ownership of in-app content and hired three additional UX writers to support it.
• Championed content design as a practice, transitioning the UX writers into UX content designers and embedding them alongside the product designers.
• Positioned the technical writers closer to product managers and engineers, aligning each discipline with the partners whose work it depended on.

Established standards and governance.

• Created separate style guides for knowledge base and in-app content, partnering with Marketing to ensure both matched the 6sense brand voice and tone.
• Created knowledge base article templates and built a Confluence intranet so the content teams and the product organization could work together more effectively.
• Established a ticketing system giving anyone in the organization a defined route to submit knowledge base update requests.

Integrated content into the product lifecycle.

• Procured Ditto so content designers could manage in-app content in step with designers working in Figma and engineers working in GitHub.
• Introduced the technical writers to the software development lifecycle and took ownership of release documentation and release notes.

The organization moved from an extended WordPress instance to a purpose-built documentation platform. Both disciplines operated with documented standards, brand-aligned voice, reusable templates, and tooling that connected them directly to design and engineering workflows. Content requests had a defined intake path, release documentation had a clear owner, and content had a standing role in the development lifecycle.