In the meantime, I see the same book on the agenda for the next meeting from another editor here in the building.  Ironically the book aimed to teach business readers the importance of being “open” and “transparent” in the Web 2.0 Age.  Since the editor had prepared a very nicely done presentation for the book, it was obvious that they had been working on it with the author for quite some time.

Now don’t misread me – I think it is absolutely fine to shop your book proposal around.  This is a very competitive industry, and you absolutely should be sure you are partnering with the right publisher for you.   But if you know you are sending your proposal to multiple editors at the same publishing house, be sure you let them know that.  We aren’t all going to publish it after all and frankly if several of us know we are looking at the same thing we can collaborate to be sure we place it in right group for maximum sales potential.

(Image credit: Mekong Virus)

You probably won’t get it right the first time.

I’m not trying to be negative here, so hear me out. Every once in a while I get a proposal where the author just absolutely nails it, but the majority of the time the first draft outline is a great start that needs some fine tuning to get it ready for the shelf.

I look at the book proposal process as a collaborative effort with the author. If I believe in your book idea and you as an author, then I am going to take the time to help you develop your ideas into something that I think has the best chance of success.

An exercise I like to suggest to authors who are bogged down in the outline is to forget that it’s a book. We will worry about turning it into a book a little later, but for now imagine you are creating something other than a book outline. How would you think about your outline differently if I told you were:

• Drafting a presentation for SxSW, Microsoft TechEd or TED (insert the most appropriate conference here)
• Writing the script or talking points for a podcast or video
• Preparing a series of blog posts on a subject

Sometimes thinking about content as just a book is limiting. As publishers move to providing content in a variety of formats – not just books – I think it’s important to open our thinking up a bit during the proposal process. Not everything will necessarily end up in the book per se, but the ideas that don’t may make for great supporting materials, or interesting marketing and promotional angles.

Thinking beyond the book allows you to be a bit more creative with your ideas. Couple that with an editor who is willing to work with you to develop those ideas into a great book is a winning combination.

(Photo credit: Massdistraction)

Here are 9 tips for writing a book proposal that will get attention.

1. The Sell Before the Sale
2. Writing a Good Book Proposal: Introduction
3. Pitching Your Book
   
4. Knowing Your Competition
5. Manuscript Details
6. Writing Great Author Biographies
7. Writing Great Book Outlines
8. Understanding Your Book’s Audience
9. 5 (Sarcastic) Ways to Get Me to Reject Your Book Proposal

(Photo credit jm3)

However, from time to time I do get proposals that look like very little effort was put into them. Always remember the book proposal is the first indication of your knowledge, commitment and ability. Here are 5 ways to not get my attention:

1. Don’t do any research. Be sure you have no idea about the books we have already published on your topic or related topics, or books we have announced. Never check Amazon.com, and certainly don’t come to our website. I actually had someone pitch me recently on a “…beginner’s book on using a computer. You guys should do a For Dummies book like that.” Why didn’t we think of that?
2. Tell me there is no competition for your book. Yes there is – it might not be a book. See also Know Your Competition.
3. Tell me you don’t have any ideas for interesting ways to market or promote your book. Really, you don’t have any suggestions? Authors should want to be involved in the promotion and marketing of their book.
4. Send me a poorly written proposal. Be sure you leave several sections blank, or give me 1-2 word answers to the proposal questions. Typos and misspelled words are a bonus.
5. Be sure the outline is a mess. I am going to help you develop your outline, but you need to give me something to work with.

If you are going to submit a book proposal, you may find my series on the topic useful.

(Image credit: WhatDaveSees)

When defining your target audience, consider these points:

1. Your audience is probably not as broad as you think. Avoid statements like “all programmers,” or the simple “web developers.”
2. Tell me what your audience already knows, or what prerequisite knowledge must they have before they tackle your subject.
3. Tell me what your audience wants to do, or how they will benefit from your book.
4. If possible, break the audience down into at least 2 camps – the primary audience, and secondary audience and what each will get from your work.

For example:

Professional XNA Game Programming is for readers who want to use their existing programming skills to create games for the Xbox 360 and Windows platforms. It is intended for readers with previous experience with C# or a similar .NET language, although no game programming experience is required.  Readers with experience using DirectX will find that it proves useful in tackling the 3D portions of the book, although it is not required.

(Photo credit: jambe)

1. Details
2. Structure
3. Did I mention details?

A great outline might tell me a few key things about an prospective author:

• They understand the topic of the book in a deep and detailed way and are able to communicate that understanding to readers
• They are committed to their book enough to have carefully thought it out to certain level of detail
• They are able to organize their thoughts

The more detail you can get into your draft outline the better. (read that sentence again – I am looking for details.) I almost always work with a potential author to further develop outlines for books I want to publish, but the further along you are with the first draft the faster I can get a proposal approved. Therefore its good for everyone when your proposal includes a detailed, well conceived outline. Here is a list of items I look for in a tech book outline:

1. Each chapter title is “active” and accurately describes what we are doing, discovering or learning in the chapter. We should be building, creating, programming, developing, understanding etc.
2. Each chapter has an estimated page count
3. Each chapter has at least 2 levels of headings and should clearly be broken into main headings, and then into subheadings where possible. A third level of detail gets you bonus points.
4. The outline should flow either chronologically or in increasing difficulty of topic. The flow of the book should be logical.
5. Chapters are grouped logically into Parts
6. Bonus if you include a short descriptive paragraph with each chapter that indicates what will be covered in the chapter and what the reader will learn
7. Are series elements included? For instance, all Wrox Beginning books use 3 mandatory elements in each chapter – “Try it Out,” “How it Works,” and “Exercises.” If you are submitting a proposal for that series, I expect you to know this either because you read the series guidelines I sent you, or you are already familiar with the series through your research.

In addition, there are a few tips to pass along:

• Don’t use the Microsoft Word outline feature. I know it is technically correct, but we editors like to see things like Chapters and Parts
• Parts have more than one Chapter
• Chapters have more than 1 subheading

And last but not least, don’t forget the details.

A good bio tells your prospective publisher you who are, and why you are uniquely suited to write your book. In fact, the bio should be tailored to your book’s topic, expressing your expert qualifications in the field. When you write this section of the proposal, consider the following advice:

1. Write your bio as if I was going to copy and paste it onto the back cover of your book.
2. Consider providing a short and an extended biography.
3. Tell me why you are qualified to write your book.
4. Be sure to include where you work and what you do if it’s pertinent, some of the big clients you may have done work for, and any certifications you may have.
5. Finish it off with a personal bit such as your hobbies, or something about your family

Here is an example that includes many of the suggestions above:

Chuck Freedman is the Sr. Flash Developer for Yahoo! Maps, leading development for both the consumer and API versions of the Flex-based Map application. With a Communications degree in Film and Television from Boston University, Chuck’s development approach combines his education in multimedia with expertise in content management, server-side scripting and database and interactive design.

In recent years, Chuck has produced some of the most highly visible dynamic Flash content, developing modules for the homepages of eBay, eBay China and Fidelity. Born in Boston, Chuck relocated with his wife Jamie to sunny Santa Clara, CA to join Yahoo! in 2005. Still a season ticket holder, he is planning many trips back east to see his beloved Red Sox win another World Series.

Many of these details are estimates at the proposal stage, but take the time to seriously consider them. Never send me a proposal with these details flagged as “unknown.” Here is a list of items to include in the Manuscript Details section of your book proposal:

1. Page count – this is critical, and one that I too often see listed as “unknown.” If you are serious about your book, then you must have an idea as to how long it will be. Until the manuscript is edited and composed, of course we don’t know exactly how many pages it will be, but give me something to work with. Is it about 200 pages, 600, 1000? Consider how long similar books are – will yours be shorter because your approach is distilled, or will it be longer because you want to provide more detail than current titles? You should be able to get a fair estimate if you include page counts per chapter in your outline. (more on that in a later post)
2. Expected completion date – I need to know when I can publish this book should it be approved. How will I know? Well, I know how long it takes our group to take a book from complete manuscript to shelf, so knowing when you are going to be done is where I start counting. I might want to target a particular buying/selling period or make a book available for an event or time it to a software release, so getting you to commit to a due date is important.
3. Images – what types of images should I expect to find in your book? Are they all screeshots, or will there be some tables, charts, or other illustrations? How many do you expect? If you are unsure how to estimate, you might think about comparable books and how many images they have – one every few pages, every page, etc. The number of illustrations is particularly important since if we are going to be creating some of the images from your sketches we will need to schedule that time with our illustrators.
4. Hardware and software used – you wont find this on all types of proposals, but we ask for it on our tech books. I need to know what software you will be working with to be sure its compatible with our editing and production processes. In many cases your publisher will ask you to use a particular program. (In our case it is MS Word and our templates.)

Yes there is.

Never leave the Competition section for your book proposal blank, nor should you use statements like the ones above to try to enforce the unique nature of your book. The fact is with more than 190,000 books published each year some of them must compete with yours in some way.

You should change the way you think about “competing” titles to also include similar or related books. Ask yourself, “what other books are my intended audience reading today?” These may not always be on the exact topic as yours, but do appeal to the same readers as your book.

For technology authors this is often a challenging way to think, especially when you may be writing on an emerging topic. Be sure to consider the current technology the new technology aims to replace or supplement. What are the leading books in that category?

Here are 5 simple tips for creating a killer Competition section for your book proposal:

1. Start with what you know. Which books in similar or related topics have you read, or know to be top sellers?
2. Take advantage of the tools offered by Amazon.com. If you are searching on your book’s topic, be sure to sort by Bestseller – it is not the default option. Then pay attention to the Customers who bought this item also bought section of the book listing. These are other titles that the audience is reading.
3. Understand the pros and cons of each of the competing titles. Actually reading the books is certainly best, and if you truly are of the audience you are writing for you should have read these books already. Also consider reader reviews to get additional viewpoints on what others found good and bad about these books.
4. Provide a summary of the good and bad points of each of the competing titles – what do they do well and where are they lacking. Including supporting information such as reviews can be helpful. Most importantly, you need to detail how your book fills the gap listed by each competing in a real and measurable way. Avoid general statements about your book such as “provides more detail on topic X” or “more practical” unless you can back those sorts of general statements with real examples.
5. Be sure to include the relevant data on each competing title including full title, ISBN, price, page count, author and publisher. This will make it easier for your publisher to review each of the titles and complete their own research.

(Photo Credit: Jennerally)

This section of the proposal is your chance to tell your editor that you really understand what you are working on. This is your “wow” section, and should be thought of as a sales pitch or marketing piece for your book. If it’s written properly, your editor should be able to use portions of this section in his or her presentation materials.

Here are 5 things I like to see in a proposal’s About the Book section:

1. Write this section as though it were your book’s product description at Amazon.com.
2. Refer to the book by it’s title in its first reference. I don’t particularly like reading “this book” or “The book” over and over. This is a personal preference, but it goes to point #1.
3. Include references to the target readership and what they will learn, or why they would want to buy the book – what problems does it solve?
4. Write about the book in present tense. Again, this is probably a personal preference, but it goes to point #1 above.
5. Use active words that speak to the approach of your book. If you are writing a tutorial you would be “teaching” or “guiding.”

Here is an excerpt from the proposal for the recently published Flickr Mashups:

Flickr Mashups is a nuts and bolts guide to building applications that use the Flickr API. With a very hands-on approach it guides the reader through a series of connected projects, each one introducing new aspects of Flickr and highlighting various techniques to get the most out of the API. By providing clear, well-structured examples, Flickr Mashups shows the reader how to quickly and easily construct real-world applications.

While most readers are likely to have some familiarity with the Flickr web site, the book starts by looking at Flickr from a user’s perspective and walks the reader through the different aspects of the site. In doing so, it identifies the different Flickr features that will be used in later chapters during the programming projects. Many of the common questions that are frequently asked in the FlickrHelp forum are also answered during this introductory tour, providing a common base from which all readers can then progress.

Readers then begin a series of projects; each one is designed to introduce new concepts or new aspects of Flickr functionality and builds upon the software built and lessons learned in the previous projects. The initial projects are straightforward tasks that allow the reader to quickly understand the basic mechanics of building a Flickr application whilst the later projects provide the groundwork for significantly more complex applications. There are a total of seven projects, which once completed, will provide the the reader with a fully functional application and a useful framework on which to build their own applications.

The projects all use PHP as the development language. PHP will already be familiar to many readers, and is very easy to learn. Syntactically, it is very similar to many other commonly used languages such as perl and Java, so translating the examples given in the book into other environments should be a straightforward task for any readers who have a specific interest in those languages and environments.