Since I started recording episodes for my podcast, only a few weeks ago, I’ve already had the chance to talk to some pretty amazing content people, such as Tom Johnson, Jacob Moses, Mark Baker and Christopher Gales (this last one still to be published).

Of course, each of them has different thoughts on many aspects of the writing job, but one thought has emerged in every one of these conversations (yeah, probably due to my own interest in it, I’ll admit). It can be summarized like this:

Looking at product development through a content-first lens doesn’t only improve the documentation; it improves the product itself.

So let’s talk a little about it. Think of a product team gathering inside a meeting room to discuss the first steps of a project that will eventually lead to a new product or feature. Who are the people inside the room? You probably see a Product Manager; maybe the CEO, if the product is really important or the company is a small startup; designers; developers; a support engineer? Maybe someone from QA? If you’re really lucky, maybe even a UX Writer.

You know where I’m going with this: the person you probably won’t see in the room is the tech writer. And that’s not because nobody likes her, but because technical documentation is usually not seen as part of a digital product itself. Most of the time it is seen as an appendix. And when you draw a project timeline on the whiteboard and ask people where the appendix comes in, the obvious answer will be “in the end”, after everything that is core and important has been figured out.

And what’s funny is that many times what is really an appendix will be included first, simply because it’s easy to think about it. The bike shed’s material before the design of the nuclear plant.

And what happens when the tech writer is finally called in is a series of unnecessary stumbles. After all, the feature is allegedly ready, so now the team needs to decide if:

  1. It will be deployed without documentation - it can be done later;
  2. They will hold the deploy while the writers rush to come up with something that resembles a piece of documentation (which is a poor way of working and, by the way, shows little respect for the writer’s job);
  3. There simply won’t be any documentation - that’s a user’s problem.

Also, let’s think of something else: if she was not working on the product documentation, what was that lazy tech writer doing while the product team worked hard on developing the whole thing? Well, she was trying to cover for the inconsistencies in the previous features of the company that were also built without synchronous documentation work. Because - by not having been built with synchronous documentation work - they were born with usage gaps.

Now you may be pondering that ensuring good usage is the job of designers - and they were in the room during that first meeting. My answer is that you are, once again, underestimating the impact of the tech writer’s work on the development of the product. Designers are definitely essential, but they are so close to the product that they can never assume the position of the user. QA engineers are also essential, but they’re there to make sure nothing will break. They are also not meant to assume the place of the user.

The tech writer, on the other hand, is very much in the position of assuming the place of the user. In fact, the tech writer is usually the first user of all. Only she can look at the product with the ignorance and curiosity that lead to the questions necessary to generate knowledge that matches the user’s mental model - which is to say valuable knowledge. Because she is not the strategist nor the builder nor the tester. She is the learner an then the teacher. And in order to teach, she needs to use the product, not like someone who created it, but as users would.

So what happens when the writer is in the room is that she will learn to use the product while the product team builds it. And in doing that she will teach you what you would only be able to learn much later, after the product is deployed, through tickets sent by angry users.

“Tech writer” or “documentarian” are deceptive names when it comes to assessing the real impact of this position when it’s well used. Put the writer in the room and you’ll have a great ally in making a better product.