How I'm writing this ebook
Someone asked if I was going to print the ebook for distribution. I might print one or two as keepsake, but definitely not for distribution. Why? Because a physical copy gets outdated the moment it's published. My thinking might have moved on. New ideas might have emerged. There might be errors. Someone might have a better answer to a FAQ than I do which I want to add on. There's no way to add community comments into the book, because the discussions that the book facilitated is richer and potentially more educational than the book itself. So that got me thinking:
What if we could write a book like it is software?
What if we saw a book as a product that we can design and launch, very much like how an indie maker launch MVPs? What would that entail?
I'm a designer and indie maker myself, so I'm curious to try out the very techniques and methods that we use to make products, on a book. I must admit I'm inspired by how levelsio wrote his Make book. Some early thoughts on how I would approach writing a book like an indie maker:
🛠 Prototyping: Getting early feedback on a prototype of the ebook and contents by closed group sharing with friends from the industry.
🚀 Launch and learn: Launch a book landing page with some free preview chapters, get sign-ups and pre-order payments committed to see if people even want it.
🤝 Co-creation by community: A collaboratively written book that integrates the collective knowledge of the govdesign community. Edit in public on Google Docs, post on 200wad, share it like crazy, facilitate discussions, seek comments from fellow practitioners, incorporate (with credits).
🔂 Iterative: A continuously updated book even after launch (much like software updates), because experiential knowledge is always growing, not static unlike a physical book. The book will facilitate further discussions, and the richness can be captured in the book updates.
What do you think of this approach? Bold, or BS? Let me know.
Next: Why write this ebook? Why should you listen to me anyway?