How to Work with Beta Readers to Finish Your First Non-Fiction Book

Steal this 5-step strategy — I stole it too

Photo by Marcos Paulo Prado on Unsplash

I stole the process of working with beta readers. Borrow it, let’s say.

I’ve been a technical editor for Manning, a publishing company that specializes in coding books. And after going through the process twice, I copy their process to work with beta readers for Street-Smart Coding, my last coding book.

Here’s what I did.

#1. Have something decent to share.

Beta readers are the first eyeballs that read your draft.

To work with beta readers, you don’t need a polished or finished book, just a decent draft someone can read. It’s OK if there are typos here and there.

The goal isn’t to line edit it, but to refine the overall book structure and content. I thought I had an impeccable draft and idea until I got feedback from my beta readers.

#2. Create a list of 10 people that can help.

I’m a fan of 10-idea lists, so that was an excuse to write another one.

I asked LinkedIn connections and friends for help. I used Google Docs to share the draft. (Each beta reader got a separate copy.) Manning has a custom platform for that. I did it the DIY way.

I shared half of my draft (15 of the 30 chapters I had planned) with half of my beta readers, and the other half to the rest. (Every chapter is independent of each other.) I didn’t want to overwhelm them with too many pages. They’re busy and helping for free.

#3. Offer something in return.

This is a strategy I copied from Manning to the tee.

I offered a free digital copy, a mention in the Acknowledgments section, and a shout-out in a LinkedIn post on launching day. Well, Manning doesn’t offer a shout out. I did. Point for helping me.

#4. Ask for specific feedback.

I asked my beta readers not to focus too much on typos or grammar issues, but on the overall book structure.

Here’s a list of questions I asked my beta readers to answer after their review.

• What did you like the most? What did you like the least?
• Any repetitive parts? Boring parts? Confusing parts?
• Any factual errors?
• Does the content deliver on the book promise?
• What can I do better? What should I include or remove?
• And of course, a name to use in the Acknowledgments.

I put those questions on page one of the Google Doc.

#5. Share a deadline.

I forgot to tell my beta readers my launch date.

Some of them gave feedback after a couple of days. Others never shared anything. I guess they were busy and I didn’t set a deadline. My bad!

And here’s the best piece of advice I’ve found on beta reading:

Listen to what beta readers say is wrong, but don’t rely on them for how to fix it. That’s your job as the writer.

Good luck on writing and launching your book!

If you’re curious, feel free to take a look at the Books tab under my profile. You’ll find short and actionable books on coding and personal growth.