Writing a good book proposal for Wrox

This is an updated version of a post from my old blog in 2005. Our editors and I get a lot of proposals from authors we know, and from new authors we don’t know at proposals@wrox.com. Here are some of my thoughts on what all of the editors here are looking for in a good proposal.

1. Show me you can write.

If you want to write a book that several hundred pages long, or even a chapter within a book, you should be able to construct enough sentences and paragraphs to fill a couple of pages. Especially if you are a first time writer and want to break into book writing, your proposal will be a big part of what we use to evaluate your writing skills.

2. Be specific in your topic.

Don’t write to me "I want to write an ASP.NET book." Tell me "I want to write a book on ASP.NET for experienced web developers. I’ll cover X, Y, Z and those are important to experienced developers because…"

3. Do a little research about other books on the topic or similar topics.

If you want to write on a topic that many books already exist on, you should have read some of those books and should be able to explain what they do well and what you’ll do better in your proposal.

If your proposal is for the first book on a topic, first, make sure it really is the first book on the topic before hanging your proposal on that. Once you’ve done that, tell me what other topic it’s similar too (DotNetNuke plays to the same people who might read IIS or ASP.NET books, Longhorn development books might be compared to Win32 API books, and so on) and tell me what you’ve read on those topics.

4. Include an outline

When you’re sending an unsolicited proposal, the outline doesn’t have to be detailed, chapter titles are a good start and show that you’ve given it some thought. Be prepared once the editor starts reviewing your proposal to put a lot of work into a detailed outline with topic subheadings and page count estimates.

5. Sell me on you.

Including your resume or CV is good. A one paragraph description of your expertise that relates directly to the book topic is better. When I originally posted this, our marketing manager added in the comments:

I’d like to stress the importance of Jim’s 5th point, "Sell Me on You." This is critical, and many authors focus too narrowly in this area. While an acquisitions editor is going to be very excited to get a proposal from somebody close to the technology, they’re just getting excited about the chance to work on what might become a Really Good Book. But the number of Really Good Books that didn’t sell would (and does) fill hundreds of warehouses.

When you’re selling the AE on You, it’s important to talk about the things about yourself that will help the book sell. Sure, you know the technology, but does anybody know you? If you are quietly competant in your area then you may well write a really good book. But unless you’re first to market on a hot topic, that’s not likely to be enough to get that AE’s sales and marketing teams excited about the book.

Your author platform is critical. Looking at Jim’s list of Upcoming Wrox Books, I know that the DotNetNuke title is likely to do really well. Not only are the authors subject matter experts, but they have the ability to talk about the book in places that potential readers visit frequently. They have a book cover on www.dotnetnuke.com, for example. One of the authors is actively blogging about the title. The authors have international connections that have offered the publisher a headstart in selling translation rights. [Jim’s note: Yes, David’s observation was dead on as the Professional DotNetNuke book he was discussing in 2005 did indeed go on to become a great seller.]

All of that falls under Sell Me on You. If you have a way to communicate to potential readers, make it part of your book proposal. Blogs, e-mail newsletters, topical websites, magazine articles, radio programs, or even podcasting would count. If you have both the expertise to write the book and a platform to help push the book, your proposal will have a better chance of getting from proposal to contract.

6. Be timely.

This has always been important but even more so in the last few years so I’ve added here even though it wasn’t on the original list. What does being timely mean? One, it means prompt responses to us on questions about your proposal and requests for more material. If we ask you to write a more detailed outline and it takes a month, you’re not selling us on your ability to write a few hundred pages or more for a book. Second it means look out at the horizon for topics. Right now in late 2009, we don’t need .NET 3.5 proposals or SharePoint 2007 proposals. But beyond that, we don’t even really need .NET 4 proposals and SharePoint 2010 proposals. While those books won’t publish until early 2010, the authors writing for us approached us (or we approached them) 6 months or more ago. If you’re trying to break in with your first, or even second, book, you need to get the publisher a proposal at the beginning of a wave, not the tail end.

If you can do all of that in a couple of pages, you’ll be several steps ahead of most of the "I want to write a book" email we get. That makes it that much easier for us to want to work with you if your idea is good and from there, we’ll help you refine the proposal, fill in details we need, get the TOC ready to be presented to a larger audience, and everything else that needs to be done to turn your idea into a book.

Tags:

Comments

3 responses to “Writing a good book proposal for Wrox”

  1. Alexei Gorkov says:

    May I share some thoughts regarding point 6 of the list? More precisely, about its second part which declares an importance of being at the "beginning of a wave". I am acquainted a little with the timing of the process and it seems to me, as a programmer, that such approach is beneficial for a publisher, not for an actual reader of a book.
    The statement that I want to discuss is that at the moment (October 2009) publishers "… don’t even really need .NET 4 proposals and SharePoint 2010 proposals".
    Ok, fair enough, but let me try to analyze what it may really mean, taking into account, that from what I read .NET 4/VS 2010 release is planned on March 22, 2010.
    Then, let’s abstract from actual product and say that some development framework or tool is going to be released in five months. Let’s also assume that we have a crew of experts in the field who were approached about writing a book on the subject six months ago. And my final assumption is that the book is targeted to professional programmers (the audience of my interest).
    It is publisher’s side of the equation with a potential reader of the book on the other side.
    As a professional programmer what I am really interested in to read in any programming book is DETAILS.
    I do NOT need a) IDE screenshots, b) lists of members of a class or c) basic code examples. Screenshots are mostly useless, members’ lists with detailed annotations are available on MSDN and the same is true for basic code examples. But from my experience items from this list of useless content constitute not less than 50% of content of an average programming book on the market (especially the one from "beginning of a wave") with another 30-40% of the book filled in with the unneeded spacious explanations for the basic sample code. Depending on the authors’ expertise the other 10-20% of the content may be actually useful or (more often than not) even more useless materials.
    Again, I am interested in details, insights and tips which one can only gain through REAL work with the framework or tool on some REAL project. And any complicated project usually takes not less than six months per se.
    With the framework or development tool in question still in beta (with a potential for breaking changes) NOBODY, with all my respect to the hypothetical crew of experts can possess those details.
    One can argue that:
    a) an author or authors usually communicate tightly with a development team of the product to get insider information
    b) chapters of the book are going to be re-edited an continuously updated with each new beta/final release available and should contain current content upon product’s release.
    On the first point: Even with a development team members willing to share inner details (?) and have enough time (???) for such communication, it is not enough. Developer can give you information regarding design goals behind some feature of the product and technical insights regarding inner implementation of the feature but, once again, without months of REAL work on some project of any substantial complexity nobody (even the developer of the product or tool, however stupid it may sound) can assess whether the feature suits particular needs or convenient enough to use and give you nuances regarding its usage from the programmer point of view. And do not forget that the feature may still contain bugs when the product is first released.
    On the second point: With the bulk of the book content written on the early stages of the product development it will be very hard (and highly error-prone I should say) to keep the content current and relevant.
    Thus, my point is that good programming book on any subject related to specific version of some framework or development tool just does not have many chances to be mature enough if it was written prior this version of the product in question is even released. It is all good in terms of “sales” and not so good in terms of usefulness for an average professional programmer.
    I have several volumes on my bookshelf that were published simultaneously with a related product which the books were intended to cover. And I’ve never even tried to find an answer to some real-life programming question in one of these books. I know for sure there is no answer there. Just a cover that looked current at that time and a lot of basic stuff in between with the sentences like “… unfortunately, there is not enough space in this chapter to cover …”. But what did you spend all this space on? Sure, those IDE screenshots, and code which nobody would use in the real-life projects.  
    On the other hand, I often use some books written back then in the age of .NET 1.1 and which are still useful and packed with valuable information.
    Summary:
    Good book is not about winning a race for the first decent-looking proposal. It is about detailed, insightful, exhaustive coverage of the subject. One should have a feeling that he or she knows the subject better than anybody in the whole world (it does not really matter if he or she right about it but such feeling must be present). And where one can gain such confidence if he or she did not have enough time to write something really complex using this particular version of the framework or tool?
    We have an industry, an assembly line which stamps books in a timely fasion on one side and a programmer on the other and their interests seem do not always converge. 
    Sorry if the thoughts are naive. Just a point of view.

  2. Alexei Gorkov says:

    So, it was a voice in the wilderness?

  3. Will Strohl says:

    I edited a few couple DotNetNuke titles books fors yous. Can I is write books for your too?  Hehehe…
    Seriously though… Those are some outstanding tips.  This process is so foreign to pretty much everyone out there. Thanks, Jim!

Leave a Reply

Your email address will not be published. Required fields are marked *