Traditional book writing is like waterfall software development. But as you might know, I'm a big fan of agile software development.
Is there such a thing as agile book writing?
Let's talk waterfall
Waterfall development happens in phases, with the process flowing sequentially from one phase to the next, like water flowing down a series of waterfalls. Requirements, design, development, testing... The phases may have checkpoints between them to make sure the previous phase is done before moving on.
And, like with a real waterfall, it can be hard to go backwards. Changes to earlier phases - like requirements or design - are challenging if they are even allowed at all.
Eventually, the product is declared ready, or you've run out of time. At that point, there's a "big bang" deployment where the entire product is made available, all at once, to real users. (Yes, a "waterfall" that leads to a "big bang" is mixing metaphors, but you get the idea.)
The chances that this big bang deployment will go smoothly are very slim. But even if you're lucky and only a few minor problems arise:
You're about to get real feedback about your entire product, in production, for the first time.
Maybe...
- Requirements gathered months ago don't match the customers' needs now.
- The design doesn't handle the actual number of users.
- Users do things nobody anticipated, and the code can't handle it when they do.
And as fantastic as your quality assurance people might be, nobody puts your product to the test like real users.
An alternative: faster feedback by iterating
Development can take a more iterative approach. A small product is created and deployed early to start getting feedback right away. You then keep improving this small product in increments. There's no big bang.
Your initial product might be underwhelming, handling only the most basic functionality. However:
- You're delivering it earlier than you would have otherwise.
- With smaller, incremental changes, fewer things can go wrong, and it's easier to troubleshoot when they do.
- Users can help guide the future of the product.
- Actual usage data gives you accurate feedback.
That feature we were sure would be a winner? Only 3% of users try it, and even they only use it once. Why? Let's find out before we enhance or remove the feature.
If you're in software development, you might recognize this iterative process with frequent delivery, fast feedback, and adapting to changing requirements as the heart of agile software development.
Can it work for books?
With traditional book publishing, an author writes the whole book largely in isolation, getting feedback only from editors or a few beta readers after the direction of the book is largely decided.
You get the most actual user feedback on your writing after the "big bang" of printing the book. But by then, it's too late. Users are already leaving you lukewarm or worse reviews saying that they lost you in chapter two. Ouch.
What can you do? It's not like you can publish part of your book before the whole thing is done...right?
Yes, yes you can.
In the manufacturing world, as in the traditional print publishing world, you'd better have the product as close to perfect as you can get it before you go to production. If it's got a major flaw, it will be an expensive mistake if you've already produced thousands of copies.
But in the software world, as in the modern publishing world, you can release the product repeatedly—even in print, with print-on-demand systems. And there are options for releasing a product with a more limited scope as an experiment to get feedback.
Experiment and learn
Luvvie Ajayi Jones does this. She "beta tested" her writing on her blog, her social media, and her mailing list. She'd publish content to her community, get their thoughts, see what got the most interaction, and refine based on the feedback she was getting.
It was also evidence for her publisher that her ideas had traction, that people were interested in the topics she was writing about. She knew the demand was there before she published.
Trying things out and learning from the feedback is also coming up in the books I'm reading. (Affiliate links here.)
- The Lean Startup, by Eric Ries, outlines an approach involving experimentation and rapid learning.
- So Good They Can't Ignore You, by Cal Newport, references Little Bets by Peter Sims (which I haven't read), in recommending learning from small experiments.
There's also LeanPub for ebooks, which allows multiple rounds of publishing.
In the meantime, I'm writing not just this newsletter, but also my blog, to try out content. I'm cross-publishing the blog on both Substack and Medium:
And as a newsletter subscriber, you're getting content I'm not publishing on the blog.
Poll
Would you be interested in receiving email for the blog posts too, in addition to the newsletter? It would mean more email than the once-per-week, but you wouldn't miss any content or need to go to a website to see it.
| In addition to Leaf's newsletter, want to also receive Leaf's blog posts by email? |
|
|
|
Drop me a note
I would love to hear from you. Hit reply and let me know what's on your mind.
Know someone else who would enjoy this? They can subscribe here: https://www.beyondwritingcode.com/connect/
Thanks for reading!