Treating documentation as an evolving product
Cloudflare’s Product Content Experience (PCX) team approaches content the way the company approaches software: as a product that must be designed, shipped, and maintained over time. The team’s stated goal is to create world-class content that anticipates user needs and helps make Cloudflare’s products accessible. That mission is carried out by intentionally designing, packaging, and testing content rather than treating it as a series of one-off deliverables.
Project mindset vs. product mindset
The difference between a project and a product is feedback. A project has a clear start and end, and success is defined by completing a defined task. Product content, by contrast, is iterative and responsive to user needs.
Many teams operate in project mode: a writer is assigned a document, produces it, and moves on. The PCX team instead borrowed from product management and agile software development to build a system where content is continuously updated and refined. This means technical writers and content designers behave much like engineers — shipping, reviewing, and iterating in sync with the product lifecycle.
Agile principles, adapted for writers
When the content team was first formed, it adopted traditional agile methodologies wholesale. Sprint planning, stand-ups, and retrospectives were useful for keeping pace with a technical organization, but the rigidity of the framework did not always fit content work. Over time, the team kept the parts of agile that supported its priorities and dropped the rest.
That does not mean abandoning process entirely. For tasks that require predictability and consistency — such as ensuring inclusive terminology across all documentation — both automated checks and manual workflows are in place. The process exists where it serves the user, not for its own sake.
Aligning content development with the product release cycle means that when a feature ships, the corresponding developer documentation is ready to publish. UI changes are reflected in updated screenshots. New features come with how-to guides and configuration references. This tight coupling with product teams keeps content accurate and user-focused, and it lets writers prioritize shipping fast and often.
Keeping pace with rapid releases
Cloudflare ships on a demanding cadence, with multiple innovation weeks per year. For a content team, that pace is a real constraint. In the early days of PCX, the challenge was balancing quality with the sheer volume of content demanded by a fast release schedule.
The team responded with two major shifts. First, writers established that their focus was on the most important content for the user, which naturally aligned them with product goals. Second, they moved the documentation to an open source platform. This consolidated authoring tools onto fewer systems and placed writers in the same environment as their users.
Within months, the content team was publishing at the same speed as the products themselves. Once the writers understood the product team’s release cadence, they cleared the initial backlog in under six months. That freed them to focus on larger initiatives: making content accessible, consistent, and approachable to a wider audience.
The open source authoring environment at developers.cloudflare.com has continued to evolve since 2020. The documentation platform now runs on Cloudflare Pages, which speeds up review and builds and gives writers direct feedback into the Pages team. The open source model also supports a growing community of external contributors.
Why this model scales
Treating content as a product requires buy-in from product managers and engineers, but once established, the model scales because everyone is aligned around user value rather than the mechanics of a content operation. The PCX team applies the same planning, research, and analytics that a product team would, checking whether the docs are solving real problems for readers.
The content strategy itself is deliberately positioned as a means to an end. The goal is not to execute a content plan, but to enable a great user experience — with documentation maintained as a living product alongside the software it describes.
