Last summer, I spent weeks creating test accounts, scheduling sales calls, and carefully evaluating documentation tools for a migration at my company. I had a specific problem to solve and a lot of opinions about how it should be solved. In the end, I chose GitBook — and eight months later, I work for them.

The problem

I was the only technical writer at a startup that had outgrown its knowledge base. We were using Intercom's KB, which wasn't built for what we needed — it wasn't scalable, and it wasn't something anyone else on the team could easily contribute to. Everything ran through me. 

We needed something that could grow with the product and open up contributions to people with very different technical backgrounds. Some of our team wanted Git-based workflows and Markdown support — the ability to work the way developers work. Others weren't technical at all, and asking them to learn a new system was already a big ask. I needed a tool that could do both without compromising either.

On top of that, I wanted something that actually looked good. A modern UI, AI-powered search, and — most importantly — real data about how users were engaging with our content. But it couldn’t just show me page views. I wanted to know what people were searching for, what questions they were asking, where they were getting stuck.

That combination turned out to be harder to find than I expected.

The search

I created accounts with a lot of products and met with a lot of sales reps. I had a pretty clear checklist: 

• Technically flexible enough for developers

• Approachable enough for non-technical contributors

• A UI I'd want to spend time in

• Genuine insight into user behavior — not vanity metrics, but signals I could act on.

Most tools did one or two of these things well, but very few checked every box.

Choosing GitBook

GitBook made it through the selection process. But honestly, the experience of getting there mattered as much as the product itself.

I'd been through enough stiff, scripted sales calls by that point that the GitBook team stood out immediately. They were warm, collaborative, and genuinely easy to work with. It felt less like a vendor relationship and more like a collaborator. Addison, GitBook’s developer advocate, was responsive to my questions and feature requests in a way that built real trust. 

When I sat down to start building, I got somewhere I was confident about quickly, ran it past leadership, and started the migration. The product was a fit. 

What we could finally see

Before GitBook, our sense of how the docs were performing came mostly from support tickets and gut feel. After launch, we had actual data: search queries, unanswered questions, patterns in what users couldn't find. 

For the first time, our content had a real feedback loop — we could see where we were falling short and make specific decisions about what to fix. And that changed how we worked.

Joining the team

When I heard GitBook was hiring their first documentation lead, I was in an unusually good position to think about what that job could be.

I'd just gone through the full customer experience: the research, the evaluation, the migration, the months of working inside the product. I had recent, specific opinions about what documentation tools get right and wrong, and what writers of all kinds actually need. The technical writer who wants to live in a terminal, and the non-technical contributor who just wants to share what they know without learning a whole new system.

I'd also been a technical writer for AI products since before generative AI was mainstream, writing docs for Alexa's NLU team at Amazon, then spending three years at Google Cloud working on AI products, including some of the first generative AI documentation Google published. I understood, from the inside, how AI products get explained to developers and how hard that is to do well. Watching documentation tooling start to incorporate AI seriously, I had strong opinions about what was missing.

What drew me in wasn't just the writing part. It was the chance to think about documentation from a product perspective: helping other writers make better decisions, being close to the work of building the tool, and advocating for people in roles I know really well. It was exciting to be part of conversations about where content, technical writing, and AI are all heading together.

30 days in

The first month has been about orienting: understanding the beat of the product and its launches, getting to know my colleagues, getting into the docs, and figuring out where my work fits.

Part of that was flying to Amsterdam to meet some of the team in person — the best possible way to onboard! Spring had just arrived, the flowers were in full bloom, and so was the energy of a kind team that cares about what they're building. 

One early highlight was GitBook shipping AI Insights during my first 30 days — a feature I would have genuinely valued as a customer. It shows which topics users are asking about most, how many of those questions got resolved, and where the gaps are. 

Questions are grouped by topic so you can spot patterns quickly, with the ability to drill into individual conversations for the full picture. The output is a prioritized backlog of where your docs could be improved.

When I was evaluating tools last summer, this is almost exactly what I was looking for. Not just page views, but signals I could act on.

———

Something I've been thinking about a lot lately is what it means for technical writers and content teams to plug into AI workstreams more directly. The feedback loop that tools like AI Insights create — real questions and real gaps surfaced automatically — is just the beginning of what's possible. 

For a long time, writers have sat downstream of product decisions. I think that's changing, and I think the people who understand both content and how AI systems work are going to have a real role in shaping what comes next. I'm curious to explore that, and glad to be doing it somewhere that's building in that direction.

It's been a good first month.