Thursday, April 26, 2012

So You Want to Publish Your Book (part 1/4)

Writing a book is one thing; making it available to the world is an entirely separate proposition. The world of book publishing has changed in recent years, as self-publishing and electronic books have skewed the economic value proposition for traditional publishers. While the new book author has other alternatives available, there are still numerous traditional publishers who look for good, marketable manuscripts. Once you've established a reputation as someone who can write books that sell, publishers are always happy to hear from you. Getting your foot in the door can be challenging, though. For this reason—and others—I'm eternally grateful to Wendy Eakin of Dorset House Publishing, who took a chance on a first-time author in 1995 and helped him craft a rather nice book, if I do say so myself.

In these four articles I will describe what I've learned about writing and publishing books. No doubt other authors have had different experiences. If you are such an author, please share your own experiences and suggestions through comments, or contact me about writing a guest post for this blog. I don't claim that this is the only way—or even the best way—to go about creating a book. It's just the approach I have taken for publishing six software development and management books, as well as a non-technical memoir of life lessons.

My friend Scott Meyers created an extensive web page that’s an excellent resource for the aspiring book author. Scott is a talented and prolific writer who is renowned for his expertise in the C++ programming language. He combined his own publishing experience with input from numerous other book authors into this page. If you're thinking of writing a technical book, read what Scott has to say carefully.

Even if you’re able to get a book written and published, you shouldn’t expect miracles. Don’t quit your job and buy that beach house, expecting book royalties to keep you in margaritas for the rest of your life. I don’t have any firm figures from the software industry, but here are my own heuristics. If your software book sells 5,000 copies, you should be pleased that you created something your colleagues find useful. If you sell 25,000 copies, you should be delighted. If you reach 100,000 copies with any book, you should be ecstatic. And if you sell more than that, you’re in a small but elite crowd of highly-respected authors. If any of you authors out there have different guidelines for judging “How’s my book doing?” please share your thoughts.

Targeting a Niche


I knew a consultant who envisioned publishing a comprehensive series of several books on a particular subdomain of software engineering. He had already drafted numerous volumes in the series, which he distributed during his training seminars. However, it's not easy to find a publisher who’s interested in releasing such an extensive series of books by one author in any specific niche. So far as I know, this consultant never did get any of these books published. It's rather a shame, because he had a lot of great material. I think he would have been better off to distill his vast quantity of material down into one or two focused, practical, and distinctive books in that area.

My writing approach has been to identify some area of software engineering that I felt was lacking an appropriate book and try to plug that gap. At the time I wrote the first edition of Software Requirements in 1999, just a few practical books on requirements engineering were available. None covered the breadth of requirements topics that I thought was essential, so I took a stab at it. A few years later, I realized that I had quite a bit of additional material, much of it developed in response to questions that people had asked me about requirements. That extra material eventually led to the second edition (what publishers call a “2E”) of Software Requirements in 2003. This edition was 60,000 words longer than the first; I guess I did have more to say on the topic.

As another example of plugging a hole in the literature, I've always been a strong proponent of software peer reviews and inspections. My own software work has been greatly improved by getting a little help from my friends through peer reviews. A decade ago there were several books in that niche already, but they were all hefty—350 to 450 pages—and they focused on the inspection technique, giving short shrift to other possible approaches for performing reviews. The topic just didn’t seem so complicated as to demand such long books. So, in 2001 I wrote Peer Reviews in Software: A Practical Guide. It was just 230 pages long, covered several review techniques besides inspection, and added some important content on review metrics and how to instill a review program into a software organization. I targeted this book at practitioners who were serious about software quality but might be daunted by a massive tome on inspection.

So, I suggest you aim your book at a niche that isn't already well covered in the existing literature for your domain. You can drill down into a specialized area, synthesize related topics into a comprehensive overview, improve on the existing books in a particular field, or invent something entirely new. A prospective publisher will assess how your proposal fits into a competitive marketplace. Something that's going head-to-head against numerous other similar titles (particularly from the same publisher) could be a tougher prospect than a book that stands alone. Publishers don't simply print interesting or well-written books; they need to publish books that sell or they go out of business.

The Elevator Pitch


You step into an elevator in a big hotel and press a button for the twenty-fourth floor. During the ride, you chat idly with the elevator's other occupant, who is heading for the nineteenth floor. Casually, you just happen to mention that you're writing a book. "Cool," says your fellow passenger. "What's it about?" You have perhaps thirty seconds to tell this prospective customer just enough about your book that he says as he exits, "That sounds interesting. I'll look for it when it comes out. Good luck."

This condensed summary of your book is called the elevator pitch or elevator story. The first time someone asked what my book was about, I confess that it rather stumped me. How do I distill the essence of a 400-page book into thirty seconds? This puzzlement was beneficial, though. It forced me to sit down and think carefully through just what my book was about and how I could explain that to even a normal (i.e., non-software) person concisely. That's a valuable exercise that I’ve applied to all of my subsequent books. With practice, your elevator pitch will roll right off your tongue whenever you encounter a possible reader.

I highly recommend that you devise your elevator pitch early in the writing process. It will help you keep your overriding objective and book themes in the front of your mind as you develop the contents. And if you have an initial phone conversation or e-mail exchange with a prospective publisher or agent, the elevator pitch is your first shot at piquing his interest. In the next article in this series I will address choosing a publisher and developing a compelling book proposal. Part 3 will address the contract and tracking your progress to meet your publishing deadlines. The final article describes my experience with self-publishing a book.

I've collected all of the blog posts about writing -- getting ideas, choosing a style, editing, proofreading, publishing, etc. -- into an eBook now available for just $5.00 at http://www.processimpact.com/handbooks.shtml#writing.

(If you found this article helpful, please consider making a donation to the Norm Kerth Benefit Fund to help a consultant who has been disabled since 1999 with a traumatic brain injury from a car accident. You can read Norm's story or donate here. Thanks!)

1 comment: