Each week for a little over a year, I've been recording a little podcast and video. It's called “60 Seconds of Johanna's Writing WIP.” I'm doing this as an experiment for two reasons:
- Market the writing before I publish it. (Yes, the “launch” is a form of marketing, but I'm also planning to experiment with book launches.)
- Show other people the value of making small progress on large writing projects.
Nonfiction books tend to take time to write and finish. But the more often writers can make small progress, the faster we finish the book. Or learn that what we thought had to be in the book is not in this book.
I write nonfiction to solve problems for ideal readers. That means I don't outline anything because outlining shortcuts my thinking and learning. (I explained how I start books in How to Start a Nonfiction Book to Educate, Inspire, or Influence Your Ideal Reader to Act. That's all about the user/reader journey.)
While I try to write a title and a blurb first, I can't always do that. I often cycle as I write to hone my message and make sure I'm writing something only I can write—not a commodity book. That cycling informs the next bit of writing.
Past Value Informs Future Writing
The more I write, the more I learn what is unique about this book. That allows me to choose what to write next and where I think that writing belongs.
Yes, this is exactly like refining the product strategy and the features after you deliver some value to a customer. I need to deliver to discover—and discover to deliver. That's often about clarifying the ideal reader and the specific problems they have. I wrote a little about that in 60 Seconds of Johanna’s Writing WIP for June 7, 2024.
While I always write forward (no editing), I don't write in just one chapter. I write a little in one chapter and realize I need to add or change a section or piece in another chapter. (See Writing Secret 12: Subheadings Help Guide Readers Through Your Content to see an image and explanation of my writing process.) This past week, I realized that what I thought was an appendix is actually a chapter. That surprised me a little, but I always reorganize a book as I write it. I was able to reorganize a little earlier than usual. That makes the reorganization easier.
That helped me see what I have remaining to write.
In that way, writing feels just like programming—product development—to me. That means that I learn exactly as product development teams do.
Three Useful and Surprising Learnings
I've known about the value of demos, recognizing errors earlier, and finding my errors faster for many years. Back when I wrote code, I showed my code as often as possible to someone else. I used Tell Your Problems to the Duck a lot to recognize where I was stuck and where I had errors. But I still missed plenty of errors. I was quite capable of writing compilable code that did exactly the wrong thing.
That's why this podcast and video surprised me:
- Because I have to demo something every week, I always make time to write, record, and publish. That weekly commitment means I always make progress on a large project.
- Every so often, as I demo (record), I realize I made an error in my writing. That's what the Outtakes playlist is for. I give myself total permission to laugh. Then, I fix the error in the manuscript and in my recording script and continue.
- Because I'm reading the words out loud and recording, I'm finding some errors faster. Those are the kinds of errors I always missed as a programmer. I don't see/hear these errors when the computer reads to me, either. (My brain fixes those errors.) I never wanted to read an entire book out loud, because I already wrote it. But a section or two? Yes, I can read that and learn from it.
My demonstrable cycle time is one item of value each week. I'm making much faster progress than I expected on this book because I'm learning as I proceed. When I'm ready for editing, the book will be as clean as I can make it.
Many teams would like to have this level of agility.
Expected and Surprising Learning
You can learn these lessons too:
- Use a weekly (or more frequent) demo as a forcing function to make progress on value. That avoids implementation across the architecture and increases the chances of implementation by feature. (See Three Reframes to Reduce Risk: Focus on Adaptability and Resilience for more info about weekly demos. See How Activity-Based Plans Differ from Deliverable-Based Plans for implementation by feature.)
- Have fun with those obvious errors. The “two templates” and “three kinds of slides” mistake cracked me up, so I shared that with my listeners. You can demo that, too.
- Do the equivalent of speaking the words out loud as often as possible. Yes, more often than those weekly demos. Writers can speak words out loud every time we finish a section. That's a way of doing things you might not like more often. When we reduce the task size, we can make the task easier—and integrate it into our various checks.
Focus on your various minimums to make demonstrable progress. Demo often. See how often you can test (before for design, and after for checking) to create a better product.
Back to writing. (Which feels just like programming!)
If you want to write faster and better, see the writing workshop page and add yourself to the notification list. If you'd like to write a nonfiction book, here's the notification form: