Spread the Word

Always be selling! You never know where it might lead (maybe to paid guest blogging or a corporate bulk order of your books). My encounter in Starbucks with Startup Monthly² founder Yuri Rabinovich led to the Rapid Prototyping with JS training course and consequently to my first book.

Have a Platform

A platform—as in Michael Hyatt’s platform³, is the surest and the slowest path to success. In the simplest form, the platform is a blog. But it can also be an Instagram⁴, YouTube⁵, Twitter⁶, or other following. The idea is to have an audience and a two-way communication. I prefer the platform and blog route for technical authors because

• It can develop writing style, habit, and skills gradually: Markdown, apps, the best time to write, and more.

• It can judge demand for a certain topic, for example, What is hotter: React.​js⁷ or Anguar.​js⁸?

• It can provide drafts and code examples for the book or even become a book, that is, blog to book.

• You can sell books much more easily, because your audience is already familiar with your works; for example, Practical Node.js ⁹ reached #19,595 in Books on Amazon.com just a few weeks after its release (shown in Figure 5-1). The rank is for all books on Amazon.com, with millions of titles being sold there.

So based on these points, I recommend starting your book with a blog. Of course there are exceptions¹⁰, authors who created a following once their books became popular. But this is more an exception than the rule, because not validating your idea but testing it by writing 200-300 pages is time consuming. I would do it only if I absolutely wanted to write on some topic and didn’t care about readership at all.

In other words, for readers familiar with lean startup and lean manufacturing, with blog posts you can validate book ideas faster.

Marketplace vs. Storefront

Amazon.com is on the other end of the marketplace spectrum. It has more traffic and better discovery, if Amazon.com’s algorithm picks your book, but no way to notify readers about updates or promotions.

It’s fairly straightforward to build your own landing page, and hook up PayPal¹¹, Stripe¹², Plasso¹³, SendOwl¹⁴ or Gumroad¹⁵. The advantage is that you get customers’ e-mails, better royalties, and more creative freedom. The disadvantage is that there is no additional exposure via marketplace search, and some readers trust unknown websites less than recognized brands such as Amazon.com (and its reviews).

My recommendation is to go to a storefront if you’re generating traffic. My personal favorite is Gumroad, because it covers transfer fees and its interface is beautiful (e.g., Figure 5-2).

If you’re optimizing for revenue and/or have a solid platform already, then don’t use marketplaces: their interfaces are clunky, they don’t provide customer e-mails, and royalties are dismal.

Improve Amazon Sales

In other words, the more sales and positive reviews a book has, the higher in the Amazon.com search result it will be placed. Survival of the fittest. Think about the algorithm as a Google search algorithm.

So the title and subtitle are paramount—that’s obvious. Don’t choose them lightly. Spend some time and maybe even some Google AdWords money to test different titles.

Another important component is categories, as shown in Figure 5-3. The narrower the category, the easier it is for your book to become a #1 Best Seller. But don’t try to trick the system by putting your book into a completely unrelated category. This might decrease exposure.

Be sure to fill in the keywords in the KDP form. A bonus is if the keywords appear frequently in the title, subtitle, and description.

Amazon has a service called Author Central²² where authors can create their profiles, so have one! Also, authors can link printed books to Kindle versions, monitor sales, and write additional descriptions for books.

Sadly, there is not much anyone can do with Amazon reviews. What’s even worse is that some people will write negative reviews if your books start to gain momentum. Try to monitor bad reviews, and if a person just needs a clarification, try to help. This might help potential readers to vote for vs. against after they see that the issue the reviewer brought was moot or that the author (you) cares a lot and you’re here to help.

Pricing

Pricing is more of an art than a science. It all depends on the real and perceived values you bring to the table and on competitors. The competitor part is easy, because you can do a Google search or lookup on Amazon.com to find out what similar authors and their publishers—if it’s a traditionally published book—are charging. It often varies from category to category; for example, Angular books are in the $40 range while JavaScript books are in the $5 range.

Self-published authors tend to charge higher prices ($50) mostly due to their small platform (and the effort that they’ve put in and the need to recoup). I personally disagree with such pricing, because they get way better royalties and usually their books are inferior to traditionally published ones. Most of my self-published books are priced two to four times below what a similar traditional book would cost.

Overall, the market for software and IT books is not as saturated as for fiction, therefore somewhere about $15-$40 is a good spot.

If you plan to sell on Amazon.com, the highest price that makes sense is $9.99, because for higher prices the marketplace will take your arm, leg, and unborn child (70% royalty). The way it works, you can choose between two modes of selling: 70% royalty, with a $2.99-$9.99 price window, or no price limitations, but only a 30% royalty. There’s fine print as well—if you opt for a 70% royalty, Amazon can lower your $9.99 price at any time (let’s say to $7.99) to fight with Barnes &​ Noble²³, or Google Play²⁴ marketplaces.

Therefore, for some authors it makes sense to sell only print books on Amazon.com.

As mentioned before, most authors opt to make their books free online (to get attention) and then charge for PDF/EPUB/MOBI if someone wants the convenience. In my humble opinion, this is a flawed strategy because most programing books are better to read on a laptop or desktop so you can run examples (not on Kindle or iPad). Nevertheless, there are a lot of success stories of authors open sourcing their books, so you might want to try it yourself.

Packaging and Bundling

Chris Guillebeau²⁶ and Nathan Barry²⁷ are famous for advocating packaging. I can see their perspective, but there needs to be enough value in higher-priced packages to justify the cost to buyers. My premium packaging for Express.js Guide ²⁸ didn’t do as well as I expected. I had online access, a mini-book, a cheat sheet, and a team license in the Professional package, as shown in Figure 5-4.

The weak sales of the premium Professional packages were partially offset by the psychological factor known as a decoy effect²⁹. In other words, most visitors choose the middle Regular package instead of the cheapest Kindle package.

The print book is usually its own item because there are some people who love print books and others who would do anything to avoid buying/having them (like me!).

Bundling is another approach to increase sales. It worked well for my Goodbye Express.js Guide ³², shown in Figure 5-5, because it brought a lot of value to buyers (∼75% off).

Bundling also worked well when I partnered with other Leanpub authors for Rapid Prototyping with JS ³³ (Figure 5-6), especially if the authors had been featured on the home page, because it brought extra traffic to my book, which I wouldn’t have had otherwise.

Mini-books like Oh My JS ³⁴ and JavaScript and Node FUNdamentals ³⁵ also work great to create value in bundles and as stand-alone marketing products when given away for free (not recommended) or close to free. For example, these mini-books with fewer than 200 pages together have 5,000 readers whom I can e-mail and cross-sell other products. Another benefit—if readers liked the mini-books, they have no fear buying more expensive products. Just make sure that the quality of any mini-books is stellar (even better than the main books’ quality), including the cover, and that they lack abundant errors. It’s easy to fall into thinking that because it’s a free book, you don’t have to make it good. But this is your door to a new audience, and you should start with your best foot forward.

Up-Selling and Cross-Selling

Up-selling is offering an upgrade to the existing product (for example, going from a regular package to a premium one). Cross-selling, on the other hand, is a promotion for a different product or category—for example, purchasers of Rapid Prototyping with JS get 50% off of Express.js Guide.

They both are great things to have and use, because they bring in extra revenue that wouldn’t be there otherwise. Another added benefit is targeting people who just made the purchase, so they have less fear buying other products.

Most of the platforms like Leanpub and Gumroad allow you to create coupons that you can paste into the products’ thank-you or receipt messages.

Launch

Launch typically requires some sort of audience, maybe blog readers or an e-mail list. The idea is that the author prepares and educates buyers before the product is sold. This creates anticipation and momentum once the sale has started.

Then you open the sale and collect money. You can also gather e-mails for preorders, alpha readers, and reviewers. Preorders come from people who make a decision now, but the delivery and payment will happen later. It’s a great way to judge whether the pricing is right. Alpha readers are preorder buyers whom you sent copies to earlier in exchange for a promise of feedback. And reviewers are readers who typically get the book for free in exchange for the promise of a review. Google forms and Mailchimp work best for e-mail lists and announcements.

Gmail allows you to send up to 500 e-mails per day from one account. Just make sure to put the e-mail list addresses in BCC to protect their privacy.

It’s easy to forget on what day or to what Facebook group or e-mail list you sent an update, so having a marketing plan and putting it on Google Calendar are great ideas.

Things to Avoid

Support

GitHub Issues³⁶ are great at documenting existing bugs and typos, because GitHub provides visibility for others, unlike an e-mail. I encourage all my readers to go there first. Figure 5-7 shows fixed and closed typographical and programming errors.

The shorter feedback cycle doesn’t mean anyone should ship half-baked products full of bugs, typos, and the like. It means you can deliver less content, for example, a few first chapters only.

Once in a while, you might receive nasty feedback, hate mail, or a bad review, or experience trolling³⁷. Try to learn, but don’t take them seriously because in most cases these people either didn’t read the book’s description carefully and expected it to solve all their problems, or they are just upset with their lives in general. The best solution if there’s nothing to learn—ignore. Never try to engage in a meaningful conversation because you are not likely to change their minds, but you will waste energy and time.

It’s funny to remember now: I had “a friend” tell me that nobody will buy my books because my English is not good, and just recently I got an e-mail in which a person was upset and tried to insult me because he bought the book at the full price, not at a discount, so I just deleted him from my mailing list. These types of customers only complain and are hard to please. It’s a better ROI to focus your time and attention on the right people.