Writer as Coder: The Iterative Way to Write a Book

By Leo Babauta

The traditional way of writing a book is like the old Microsoft model of developing software: you write it in isolation for a year or two, and then put it out as a fully-formed product.

The problem with that method is that it’s never been tested in the real world. You don’t know if readers (or users) will want it, you don’t know where you’ve made huge mistakes, you don’t know how it will work in the wild.

That “Microsoft” model of making programs has been replaced in the last decade or so by iterative programming, where you make a Minimum Viable Product as soon as possible, and let a small group of people (alpha or beta testers) use it and give you feedback and report bugs. Then a new version is made, more testing and feedback, and so on, making the product better and better each iteration. I love this model, because it leads to a better product over the long run.

Unfortunately, we authors are still stuck in the Microsoft model when we’re writing a non-fiction book. We write in isolation and then launch the book, and hope it will be helpful, though it might not have been tested during the writing phase.

There’s no reason for that, so I used the iterative software model when I wrote my new book, “Zen Habits: Mastering the Art of Change“.

The process is one of the best things I’ve ever done as a writer.

It went something like this:

  1. Write a minimum viable book for alpha testers. I wrote each chapter for a group of 10 alpha testers who generously agreed to read early versions of the book and put it into practice. Because I was writing for them, I was more motivated to write regularly. Lots of times we writers will stagnate and procrastinate when we have a big book to write, but knowing that my alpha testers were waiting for my chapters kept my feet to the fire.
  2. Get feedback, improve. I’d give the alpha testers a mission at the end of each chapter, and they’d put the ideas into practice. Then they’d journal about it, and I’d read their journals. This was my feedback mechanism, and it was great, because I could see where there were questions, holes, objections, things that didn’t work, things that weren’t clear, things people just weren’t buying.
  3. Iterate quickly based on their feedback. First, I’d write responses to their questions in the journals, trying my best to address their problems. Next, these responses would often turn into new chapters that I’d share with everyone.
  4. Take the ideas to a larger group. After testing the ideas on my alpha testers, I would use them here on Zen Habits or in my Sea Change habits program. At this point, the ideas were more developed and I had a bit of confidence in them because they’d been tested by more than just me. I got feedback from these larger groups through Twitter, emails, polls, and forums in Sea Change.
  5. Use all the feedback to write the book. All throughout this process, I was writing the book … but about a month or two ago, I started from scratch, taking in all the feedback I’d gotten from readers and testers, and from my editor Juli, and wrote a whole new version of the book (just finished last week!). Then I threw the book onto Kickstarter, and asked for the support of my readers. And got it – the response has been overwhelming, humbling and incredibly gratifying.
  6. Keep getting feedback & iterating even after book is written. The process isn’t over. I plan to put the book up on the web for a small group of early-bird backers, and they’ll give me feedback next month, before the book goes to print. I hope to use that feedback to make some final changes before ink hits paper. And once this first, limited-edition print book is in people’s hands, I plan to revise it into a second edition to be delivered online later in 2015. At that point, I might just lay the book to rest.

This process might sound like more work, but I’ve found some tremendous benefits:

  1. I’m more motivated to write when people are waiting on each chapter.
  2. Instead of having to write a huge book, I can focus on smaller iterations, which are much easier to make.
  3. If I see that it helps, I feel great about the writing.
  4. If I see objections or problems, I can fix those before putting it into print.
  5. My method gets better with each iteration, making it more useful over time.
  6. I write in solitude but I’m creating with a community, which makes the entire process more enriching.

I highly recommend it.

See all posts »