I turn complex software into intuitive 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. A knowledge base existed to serve all three, but it wasn't doing the job. The entire documentation set — roughly 1,000 articles — was maintained by a single technical writer with part-time assistance from an SQA specialist.

The problems compounded each other. Coverage was thin relative to three separate products. Existing content had no consistent structure or voice, because there was no style guide and no article templates to enforce one. Nothing existed to keep published articles current as the products changed. The practical result was that neither clients nor internal staff trusted the knowledge base enough to use it, which meant support absorbed volume that documentation should have deflected.

• 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 from 1,000 to 2,500 articles 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 different and equally problematic documentation situations. One product had no documentation at all. 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, while a third product had no coverage whatsoever. Customers had no single place to look. 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, a substantially larger customer list, and another established knowledge base. That knowledge base was maintained by two technical writers as a wiki-style menu embedded inside the platform itself. I inherited that team as a manager, reporting to the VP of Product.

The core problem was fragmentation at scale. 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 company's web academy content needed dedicated attention that no one on the team was positioned to give it.

• 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.

My own role expanded in step: I moved from manager to director, reporting directly to the Chief Product Officer.

I joined 6sense as Director of Technical Writing, reporting to a VP of Product. The customer-facing knowledge base was maintained by two UX writers and built on WordPress — a platform never intended for this kind of content, and one that required more than 30 software add-ons simply to function as a knowledge base.

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 the technical writing function had no formal place in the software development lifecycle.

Migrated to a dedicated content management system

• Researched alternatives and piloted a portion of the knowledge base in Document360 to validate the fit with real content.
• 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.

6sense moved from a knowledge base held together by add-ons to a purpose-built platform, and from two writers covering one surface to a nine-person organization spanning technical writing and UX content design. 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.