How to add documentation to your product life cycle

As a tech writer, I’ve encountered a number of different processes that teams and companies have used to add documentation to their product development processes. Some of these are intentional and others are incidental—but all are used to create documentation across the software development industry.

At its most basic, the product development life cycle involves the following steps:

Rough sequential timeline of plan, design, develop, test, and release steps.

When you add documentation, that might look something like this:

Sequential timeline of two simultaneous processes, one for development with steps of plan, design, develop, test, and release, and another for documentation with a shorter step to coordinate timelines and resources, a shorter step to consult on UI text at the same time as design, a step to write documentation midway through development, a review and test step overlapping with the test step in development, and a publishing step coinciding with the release step.

The typical models I’ve encountered working as a tech writer can be categorized as follows:

The “throw it over the wall” model

The “throw it over the wall” model happens when engineering and documentation teams don’t have much interaction. Instead, in a waterfall-like approach, the development team creates something and tells the documentation writer about it after it’s built.

This can happen intentionally or incidentally. Maybe an entire feature gets developed, is ready to launch, and someone lets the documentation writer know—before or after the release.

A timeline showing four different job duties, PM, UX, engineering, and documentation. The first three start planning, then design happens, then development happens, then after development finishes, PM requests documentation and documentation plans, drafts, and reviews the documentation while development finishes testing, then there is a coordinated release.


The advantages to this model are largely to the organization:


The disadvantages of this model are both to the customer experience:

And to the organization and its writers:

The “put out the latest fire” model

This is a fairly common model, especially for overburdened documentation writers or those working as contractors or consultants on a project. You could be an external freelancer brought in to work on a specific project or be part of a documentation or content team that works with others on a project-by-project basis.

In this model, you join a project and work with that project team in an embedded or throw-it-over-the-wall fashion until the doc needs are met. You might only have one point of contact, like a product manager, and you deliver the documentation requested by them. After the project concludes, you join a different project.

A timeline showing four different job duties, PM, UX, engineering, and documentation. The first three start planning, then as design starts happening and engineering starts planning, documentation starts planning too. As design finishes, development has started, and PM (optionally) reviews and approves a doc plan. The doc writer drafts documentation while development finishes and goes into test, then there’s a short review cycle and a coordinated release process across all teams.


The advantages to this model are largely to the organization:


The disadvantages are borne by both customers and the organization:

The “I’m with the team” model

In this model, the documentation writer is treated as a full-fledged member of the engineering team, involved in all the same meetings, Slack channels, and most discussions.

A timeline showing four different job duties, PM, UX, engineering, and documentation. PM starts planning, then design, docs, and engineering are brought in to plan at the same time. Designing starts and documentation collaborates on UI text, and development starts. When development is mostly complete, documentation drafting starts and is reviewed while the product is being tested. Then there’s a coordinated release across all teams.


The advantages of this approach are mostly for the customer:


The disadvantages of this approach are borne largely by the organization:

Which model is the best?

It depends on your priorities and circumstances!

A decorative image showing the three models, a wall to symbolize throwing it over the wall, an orange and yellow flame to symbolize putting out fires, and three orblike people icons to symbolize being part of the team.

In an ideal world, I think that the “I’m with the team” model is the one most likely to produce the best documentation — but it’s also the most resource-intensive, and therefore might not be the most feasible option for every organization.

The “put out the latest fire” model can work well at a company with low-complexity projects and consistent organization-wide procedures, making it possible to plug-and-play writers on demand to different projects. Unfortunately, many projects that require documentation also benefit from strong domain expertise and local project context, so this approach is best suited for short term transition phases at a company. After you know what projects are going to stick around and need writing commitment, you can invest in a more proactive and embedded approach like the “I’m with the team” model.

For small companies like a seed-stage startup, or one that is great at asynchronous communication, the “throw it over the wall” approach lets you add documentation without changing your core engineering processes. If you’re at the early stage where you’re prioritizing moving as fast as possible most of the time, this approach probably makes sense.