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

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).

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.