The Product is Docs: Writing technical documentation in a product development group

I've been a technical writer or technical editor for decades. But not until 2020 did I serve on an Agile development team. I should have read this book in 2020! I thought I was doing all I could to help my readers and my team. I wasn't ... but soon I will.I read eight to twelve books on writing each year. But most deal with the art of crafting sentences a paragraphs. Thanks to this book, I plan to read more books devoted to the tech writing as a process.Let me add that the Splunk book ranks as one of the best-written, best-edited writing books I've had the pleasure to read. Try as I might, I couldn't find more than five or six nits to pick. Most were about concordance of grammatical person. The Introduction begins, "In the course of doing our work, the Splunk documentation team strives to adopt—and adapt—industry best practices whenever we can find them." "Our work" promises that the main subject will be the first person "we." Nope: It's the third person "the ... team." Then it's back to "we" in "whenever we can find them." But again, I see this practice everywhere. In 10 years, no one will understand why people like me ever cared.

I just finished this book. It's excellent. I work in the technical documentation field. It struck me as more practical and real-world based than the way technical documentation is often presented elsewhere. When you're in the weeds, the day-to-day of software creation and its documentation, rigid processes tend to break, complex processes tend to break down, and sometimes what seemed like simplification of the overall process turns out to slow it down or reduce quality.

This book described many ways to in which strengthening the relationships between the docs and other functional teams is instrumental in delivering a high quality product, maintaining customer trust and staying competitive in a modern world. The author and his team present down to earth strategies for establishing constructive and collaborative relationships in often tight timeline environments.Help executives notice the positive impact the docs team has on the bottom line because of the collaborative foundational guidelines and processes this book helps you build and maintained. Encourage engineers to be heavily involved and responsive to the documentation process by using tips and tricks in this book to adapt to their workflows and minimize their disruption. The book offers advice on developing cross-team initiatives and workflows to help keep you in the loop with the marketing team and their initiatives.

This is an excellent overview and guide to technical writing as currently practiced. This is useful for people new to (or considering) a career in technical writing, for experienced writers who want to update their skills, and for managers looking for guidance. The topics are relevant to anyone who wants to learn more about technical writing in a modern software company, including how to work in an Agile environment, the need for extensive collaboration, how and why to create task-based documentation, and how to measure the results of your work. Even better, this book is concise, and each section gets to the point quickly and without filler.

This book has given me a lot of good advice to consider as I've been considering my own role as a technical writer for a software company and how I'll collaborate with other teams to do my best work!

From the team at Splunk, this book gives us not just a window into the ins-and-outs of technical writing. It gives helpful advice along each step (organized in short, punctual chapters) to navigate and do well. The focus is on producing good documentation within a team, whether it's a team of software developers or corporate management.Some chapters have greater detail than others. (Hey, nobody's perfect.) If that's the only caveat though, you've got a winner on your hands. I would gladly recommend this book to people interested in tech writing, novice writers, and even writers in other fields looking to switch to documentation.

This is really a good book. I read it on Kindle. May be that is why I have the formatting comment. Besides that, I'd also love to see summary of key points in each chapter - say at the end. Technical writing templates would add to usefulness of this book. For example in Technical Editing chapter, I'd have loved to see some examples or links to GitHub projects that have 'awesome' technical writing - that would be really useful for new, first time, non-experienced writers (read SW developers).

As a technical writer of more than 15 years, I found this book inspiring, packed with real-life examples and advice, and lots of “yes, have been there, too” moments. A good read. And probably the best book on technical writing that you can currently find on the market. Kudos to the team of authors.