Over the years Dan and I have built a lot of technology products and have internalized the product development process. Fundamentals for Founders is our first book, and while writing it we often joked about how it felt so much like shipping software again. No matter how different common perceptions might be about the types of people who become writers and engineers, we’ve noticed that these two professions share a lot of similarities. With hindsight it’s not that surprising: both are building a product, so many of the same principles apply. We thought of our book-writing process in terms of the following stages:

Looks a lot like an engineering project, doesn’t it?  Here’s a breakdown of some of the shared points:

Project Management. Both writers and product teams need to trade off three dimensions:

1. feature set
2. quality
3. schedule

For writers in particular, those dimensions are manifested as:

1. the breadth and depth of content
2. quality of the writing style
3. timing of the book release

As they work on their book, they’re making decisions where they need to balance those three aspects. For example, we faced questions like: Should we add an extra section to this chapter? Is it worth our time to do another set of revisions on this excerpt, or is it good enough? This piece of content doesn’t meet our quality bar — should we fix it up, or remove it? Making those calls is also the daily job of product owners at technology companies — so we felt right at home.

Quality Bar. How do you decide if a piece of writing is good enough to sell to your readers? We established a couple of criteria for our book:

1. no clichés (we’re allergic)
2. The “Theron” test. My friend Theron is a super-smart engineer who recently quit his corporate job, so he fits perfectly into our target market of people looking for some guidance on how to start a business. For sections not directly related to product development (Theron’s home-field), we’d ask “Would Theron find this useful?” If not, cut it.
3. The “Ripan” test. Our mutual friend Ripan is one of the smartest guys around and has a finance background. For anything outside of finance, the Ripan-Test asked “would we feel comfortable telling this to Ripan’s face over dinner?” That was a helpful bar not just for keeping an appropriate depth of content, but also for keeping our writing style fresh and targeted at a demanding reader.
4. Last but not least, the “would we want to pay for this ourselves?” test, a good bar for keeping our content useful.

Keep Raising the Threshold for Accepting Changes. Fixing a bug in a software product always carries both the cost of having to re-test, as well as the risk of introducing new bugs (called regressions). It’s the same with a book. As you edit your writing, you’ll need to then recheck the whole section for consistency, and you’re running the risk that your changes have unintended consequences like changing meanings, removing context that’s required elsewhere, etc. So as you’re nearing the end of your project, you’ll need to keep raising that quality bar. When in doubt, err on the side of minimizing changes.

Write Ship-Quality From the Beginning. I started writing my parts of this book at a hostel in Taiwan and was having breakfast with a local newspaper reporter. Being new to writing myself, I asked her whether she goes for quantity first when writing a piece, or whether she polishes each sentence right from the start. Definitely the latter, she said, and apparently most other professional writers do the same. It took some time for that to sink in for me. At first I preferred just sitting down and writing from a stream of consciousness. It felt so productive to churn out thousands of words in a day! But we’d find out later that my high-quantity but unpolished content would take more time to clean up and rewrite than had I simply written it more carefully from the beginning.

In software terms, fixing the bugs took more time than writing the code in the first place. (That’s one reason for fascinating research results showing that software teams working 40 hours per week sometimes produce more work and at better quality than teams working longer hours. The over-worked teams write bad quality code that takes disproportionately more time to fix up.)

Lastly, an off-beat example about product quality that might serve as food for thought and discussion: I’ve been terrorized by my electric toothbrush recently. It turns itself on in the middle of the night, wakes me up, and then the OFF button does’t work. (Why does a toothbrush wake me up despite a wall and two doors being in the middle? I live in China and suspect that the toothbrush heads I purchased are fake… they make an enormous amount of noise when spun by my Oral B.)

So what to do? It’s 3am, you’re holding your vibrating toothbrush, and it won’t turn off? It’s an iPhone-style toothbrush — can’t remove the battery. Tossing it out the window isn’t an option. The solution: wrap it in something soft, then seal it in the washing machine. Nice and quiet.  Charge it again during the day, then stuff TB back into the washing machine before you go to bed. What does this teach us about product development and keeping a high quality bar? Should Oral B have spent more time testing this toothbrush? Or generalized: faced with a choice to fix only one bug, which one would you pick: a low-severity issue that many people will see early on (such as an imperfection in the coloring), or a high-severity issue that only a few people will see and only after years of happily using the product (like the tooth-brush alarm-clock bug I ran into)?