My Book Marketing Process

bazaar photo

Photo by -Marlith-

Last year, I wrote a technical book, focused on a niche tool of a niche technology. I posted about my writing process, but wanted to write about my marketing process as well. As my father, who has published a few books, says: “once you finish the book, the hard work [marketing] begins”.  After all, the world, and even the Internet, is a big place, and no one was going to beat a path to my door (or yours).

I tried several different marketing channels. Here’s a list and some commentary on how each channel worked in terms of traffic and sales.  My main goal was to drive traffic to my leanpub book page, where purchase was only a click away.

  • I published a blog post about the book and put an embedded ‘buy now’ link on my blog sidebar. I also did some follow up posts about Cordova CLI, including one about accessing more info from hooks in later version of Cordova and running multiple version of Cordova. Hard to tell if the additional content helped, but I had quite a few sales referred from my domain.
  • I set up a Google alert for ‘cordova CLI’ to see if there was anyplace I could reply and help people with questions while linking to my book page.
  • Monitored and answered Stackoverflow questions about Cordova and Cordova CLI–these typically also figured prominently in the Google alert. SO was the third highest referrer to my leanpub book page.
  • Google adwords: this didn’t work so well. I had 7K impressions and a 0.52% CTR but no conversions. I ran the campaign for about two months, but most of the keywords were pretty obscure.
  • Guest posts at on topic blogs: this worked great. I posted two different posts–Three hooks your Cordova/Phonegap application needs and Phonegap makes mobile app development more accessible. The more aligned the blog post was with the audience of the blog, the better the conversion. I also engaged in the comments section as well.
  • Emails to tech influencers (often with a coupon for a free or reduced price book). This was both marketing and a ‘thank you’ to all the people who either help out with Cordova, or who I have read for years and just wanted to thank (ahem, Matt Raible). It did result in some tweets. Thanks to Jason Grigsby, Brian Leroux and Holly Schinsky
  • Posting on the phonegap google group about the book, with a coupon. This didn’t drive that many visits, but the ones who did converted very well (>25%).
  • Posting on the phonegap google group answering general questions with a link in my signature. This drove some traffic and lead to one conversion. It didn’t scale very well, as when I stopped answering questions, the traffic fell to zero quickly.
  • Emails to members of the phonegap developer directory. I ended up sending out about 50 of these (both myself and hiring someone from Odesk). Surprisingly, I didn’t see any sales from these emails, which were admittedly “cold calls”.
  • Posted to hackernews. No discussion, but a non trivial number of visits.

Here are some things I should have done, or should have done sooner:

  • Set up a custom domain, like this person did.
  • Build a useful email list.  I actually have one, but it’s hard to find out how to subscribe.  Oh, and post to said list.
  • Written and flogged a talk about Cordova. There are probably two or three meetups in the Denver or Boulder area that would have been happy to have me talk, and I expect I would have sold some books through that venue.
  • Added the book to Amazon and Barnes and Noble. I just did that (links to Amazon, Barnes & Noble). Leanpub makes it silly simple to do this, however the royalty hit you take for the distribution is high.
  • Written more articles and pitched them to online magazines. In fact, I should have, when writing the book, queued up 3-5 articles to pitch to publish on launch day.
  • Emailed my readers via leanpub and asked how I could help them (I did this, belatedly).
  • Kept the book up to date. (I still may review, expand and update the book, because it is still a topic that interests me (and there is interesting stuff happening with Cordova, like Ionic and Google Glass support.)

I missed some of these marketing opportunities because my life just got too busy. Others because we stopped using Cordova at my day job, which meant I had less interest in keeping up with Cordova in general. And that, in turn, made it hard to keep up with marketing effort.

The final piece of advice I would share about marketing an ebook is that it is a long game. I realized that even a book on a topic so short lived as a Cordova book–it covers 2.9, 3.0 and 3.1, and the current version is 3.5–there are still ‘long tail’ effects. I make sales now, almost a year after first release.



Priorities and Focus

ben horowitz photo

Photo by TCDisrupt

I enjoyed Ben Horowitz’s ‘The Hard Thing about Hard Things’.  It was an in depth view of the lonely life of a CEO going through hard hard times.  I was only recently out of school when the dotcom bust happened, but I still remember layoffs–the company where I worked was going to be huge! “offices in Singapore and London!” until it wasn’t–which happened the week before Thanksgiving.

I cannot imagine what it was like to be in upper management in those times.

Must have been pretty wretched.

My favorite part of the book, though, is this section:

One very hot day my father came over for a visit. We could not afford air-conditioning, and all three children were crying as my father and I sat there sweating in the 105-degree heat.

 

My father turned to me and said, “Son, do you know what’s cheap?”

 

Since I had absolutely no idea what he was talking about, I replied, “No, what?”

 

“Flowers. Flowers are really cheap. But do you know what’s expensive?” he asked.

 

Again, I replied, “No, what?”

 

He said, “Divorce.”

 

Something about that joke, which was not really a joke, made me realize that I had run out of time. Up until that point, I had not really made any serious choices. I felt like I had unlimited bandwidth and could do everything in life that I wanted to do simultaneously. But his joke made it suddenly clear that by continuing on the course I was on, I might lose my family. By doing everything, I would fail at the most important thing. It was the first time that I forced myself to look at the world through priorities that were not purely my own. I thought that I could pursue my career, all my interests, and build my family. More important, I always thought about myself first. When you are part of a family or part of a group, that kind of thinking can get you into trouble, and I was in deep trouble. In my mind, I was confident that I was a good person and not selfish, but my actions said otherwise. I had to stop being a boy and become a man. I had to put first things first. I had to consider the people who I cared about most before considering myself.

It’s a beautiful vignette.

As a father with a lot of interests, this really resonated with me. Kids (or, I imagine, other major challenges such as a sick relative) take so much time that they force you to re-evaluate everything and think about your priorities and life focus.


My Book Writing Process

writing photo

Photo by mrsdkrebs

I wrote an ebook last fall. It’s about the Cordova command line tool (Cordova CLI). Cordova is a way for web developers to build mobile apps that are distributed via the various app stores and can access app fucntionality (your list of contacts, for instance). The CLI is the main method of interacting with Cordova–managing your files, building apps, etc. It’s a niche, but one that I felt passionately about. I love the command line and I love webapps. I find the whole native app experience distasteful. (“Didn’t we already watch this movie?”)

I thought I’d share some lessons from this experience. This post will be about the writing, the next one about the marketing, and the final one about the results.

I wrote a series of blog posts, gathered here, to determine if I would enjoy writing a book, and to give me a head start on the content. Those blog posts were primarily written in July when my wife was away visiting family. I figured that if I didn’t want to write the book, the blog posts would have value anyway–writing clarifies issues for me. If they were useful and shared, then I would have some market validation.

On August 1, weeks after publishing my first Cordova blog post, I received an email from a reader who said the posts were useful, and asked a question. This was enough validation that I decided to start the book. It was five weeks from creating the project on leanpub to completing it (late August to early October).

During the book writing, I focused on expanding on the blog posts to make sure they were authoritative, adding new content as I came up with questions, and verifying all the claims using the Cordova software. I remember spending an hour trying to confirm one part of one sentence in the book. I also spent time answering and asking questions on the Cordova/Phonegap Google group. I also monitored the Cordova developer list, more for interesting topics than for dialog. And a new version of Cordova (3.1) was released just a week or so before I was done with the book, so I spent some time double checking how the new version of the CLI worked.

As far as time, I averaged an hour a day for that five week period–remember, a good chunk of the content was already written and I was simply revising it. I found time on the weekends and in the early morning.

I ended up finding a flickr image to use for the cover page–thanks Marc!

In the end, the writing was fun and a grind all at the same time. You just have to make the time.


Handling Bookings with Shopify

calendar photo

Photo by Michael McCarty

I am doing some research for a possible client engagement.  The client has invested in their Shopify storefront, and are extremely reluctant to move away from it.  Updated 8/27: the client is MM Local Foods, and the issue is with their Harvest Share.

However, a significant subset of orders placed through this system have ‘pickups’ associated with the order–these are events where the customer picks up the product.  There are multiple locations and multiple dates, and the customer can switch from one pickup to another at no cost.

Shopify, to put it mildly, doesn’t handle this use case well–it is about at easy to modify an order in Shopify as it is to read that Aztec calendar to your left.

Edit Order is the only Shopify app that I could find which will let anyone modify orders, and it has significant limitations:

  • only staff with access to /admin can modify orders.
  • it doesn’t actually modify an order.  Rather, it deletes an order and replaces it with a modified order (order #204 becomes order #204A).  This means you have to re-run the payment process.

I also looked at BookThatApp, which specifically handles ‘bookings’ within the Shopify framework, for services like tours or piano lessons.  Unfortunately, this service doesn’t let the customer reschedule the booking themselves (I asked BookThatApp support to be sure).

So, I spent a fair bit of time wandering the internet, looking for scheduling and booking SaaS apps that:

  1. had an API that could be integrated with Shopify
  2. would handle events at specific dates, times and places rather than letting the customer pick freely from from a weekly availability calendar (such as for piano lessons or massage appointments)
  3. let the customer modify their pickup without calling customer service
  4. looked professional
  5. wasn’t too expensive
  6. wasn’t too cumbersome to manage from the business side

The bad news is I didn’t find any software that fulfilled all requirements, even after hours of searching and signing up for about ten different applications (at least they all had free trials!).

I was astonished–was I not searching the right keywords?  Is this such a niche need?  A lot of scheduling software failed on criteria #2.  Eventbrite failed criteria #6 and #3.  Most booking software failed #5 and #3–which makes sense as they are aimed at tour companies who don’t want customers changing their tour dates without talking to someone.  I looked at some class scheduling software, but couldn’t figure out how to make it work.

The good news?  I found one solution that does almost everything above–it does fail criteria #1, but I think it is the best of the worst.  The other alternative is to write custom code, and that always worries me.

Why does writing custom code worry me?  One word: maintenance.  Especially for a small, non software focused business, maintenance of custom software is costly.  Instead, it is better to conform your business processes to the SaaS application which best fits them, and let someone else shoulder the burden of maintenance.  This is not always the case–sometimes needs are so precise and static that custom software is the right answer.  But my default is always to look for other solutions.

I’ve outlined some of the pros and cons to the customer and am waiting to hear back on how to move forward.

And if you know of any solutions that might be better options for this customer, I’d love to hear of them.


Consolidate external dependency notifications using Zapier

binoculars photo

Photo by M1key.me

As I wrote over at the Geek Estate Blog, if you build your business on vendors, you should monitor them.  In the past, I’ve used a variety of services to monitor vendor services, from pingdom to wget/cron to nagios.  These services are great about telling you when some external service is unavailable, but are not so hot at telling you when a service is going to be down (for planned maintenance) or back up.

For that, you need to be monitoring, and reading, vendor announcements, however the vendor has decided to provide them, whether that is as a blog/RSS feed, twitter feed, email newsletter, a status page or something else.

However, it can be tough to monitor and read announcements in two or more places.  Here, Zapier or a similar service can help.  Pick one place to be notified.  For me, that’s typically an email inbox, because, frankly, other data sources can be ignored (except phone texts), but I’ll always check my email.

Then, use Zapier’s zaps to transform any announcements from the other sources to emails.  For instance, there is an RSS trigger for new items in a feed and a Twitter trigger for tweets from a user.  Status pages often provide RSS feeds (Google’s does).  If the service provider doesn’t provide a structured method like an RSS feed to notify you of changes, but does provide a webpage of announcements, you could look at a service like changedetection.com and have the email sent to your inbox or parsed by Zapier and pushed to your notification location.

And for the output side, you can just use Zapier’s ‘send outbound email’ action.  If you want to have all notifications pushed to your phone, an RSS reader or Twitter acount, you can use Zapier to send texts, create RSS items or tweets as well.


Video of the Week: What’s a “Doertacracy”

VC Brad Feld of the Foundry Group defines this concept in this 90 second video:

The internet has let one thousand, nay one billion, flowers bloom, so many flowers that it can be overwhelming at times. Brad suggests picking one or two or three flowers at most and really understanding them, rather than trying to smell all the flowers.


Building a System with IronMQ and Python

messages photo

Photo by andrewrennie

One of my most recent projects was writing a system to deliver real estate listing data to a content management system. The CMS was not in my control. Since the listing data source was bursty and I wasn’t sure how the CMS would handle the load, I decided to use a message queue, where the messages would have a JSON payload. Message queues are great at decoupling components of a system.

For the queue, I used IronMQ. The company already was using it, it has a free tier (up to 24 messages a second), the service has been stable and reliable, it has great language SDKs, and setting up a durable message queue is something I’d rather outsource. (I do wish Zapier supported it.) In other situations (when posting messages from mobile apps), we ran Varnish in front of IronMQ so that it could be replaced easily. In this case, we didn’t because there were fewer moving pieces (it was server to server communication and it would be easier to swap out IronMQ should that be required).

I wrote the bridge code from the listing database to the message queue in python. The shop was mostly Java and some python, and python seemed a better fit for a small ‘pull from here, push to there’ application. I used pytest for unit testing, jenkins to run the unit tests in a CI environment, and autopep8 for formatting. My colleague was a more experienced python programmer, so I was able to lean on him for questions. I didn’t find python hard to pick back up (I’d scripted in python a little years ago), and it was a fun language to code in. Reminded me of perl w/r/t packages and quick developer feedback. I did miss Java’s dependency management, though (my college recommended virtualenv as a possible solution).

The JSON payload would allow developers writing the message consumer to use almost any language they wanted–any language if they used the IronMQ REST API rather than an SDK.

I can’t share the code, but for this kind of problem, python was a great solution. And I’ll reach for IronMQ any time I need a message queue. This pair of technologies was quick to implement, easy to deploy, and high performance wasn’t really a requirement, since the frequency of the listing delivery was the real bottleneck.


The limits of Google forms

paperwork photo

Photo by Harald Groven

I spent a fair amount of time in the spring working on Google forms. If you have Google apps for your domain and are doing any kind of data entry at all, you should use Google forms. With this, you can create a web and mobile friendly data entry form easily, with validation, for free.

And by you, I mean ‘you, the non technical user’–a big win.  I’m a big big fan of anything that removes developers from the loop because they are too often the bottleneck.  Of course, as you’ll see below, Google forms is not entirely the land of milk and honey.

Any data entered typically goes into a Google spreadsheet for easy batch processing. You can limit use of the form to your Google apps domain, too.

Here are some ways that I’ve seen Google forms used to eliminate manual re-keying of data:

  • Event RSVPs
  • Contact forms
  • Order forms for collateral
  • Transaction reporting
  • Timesheet or vacation tracking

Google forms are extremely flexible, but do have some significant limitations (which is why other form building companies like Wufoo haven’t had all the air sucked out of them).

Some limitations and issues are:

  • If you post to a Google spreadsheet, the typical use case, you are bound by spreadsheet limits: 400k rows, 256 columns.
  • You can’t host the form on your domain. The best solution to this issue I found was to do a URL redirect of a domain name. For example, from someform.example.com to the Google form URL. This lets you replace the form while still sending people to the same URL.
  • You can’t have a form email an arbitrary address on submission without custom code.
  • Multi page forms are possible, but clunky.
  • Validation is limited, though using regular expressions gives you a fair bit of power (but then takes form creation/maintenance out of the realm of the non developer).
  • UI customization is limited. A Google form will always look like a Google form (short of serious server side gymnastics). It will always have the ‘powered by Google forms’ link, the same crappy ‘response received’ page, and the same horrible handling of closed forms (an unmodifiable message from Google, with no way to customize it).
  • Option lists are static (though if you use formRanger, you can alleviate this issue).
  • File upload is not supported. Seriously. Even though Google wants you to use Google Drive.

As alluded to above, you can use Google Apps Script to alleviate some of the issues with Google forms. However, doing so pushes the maintenance of that form into developer land (or at least ‘power user’ land).

Even with all the warts, Google forms is a powerful tool. And did I mention it is free? If you or anyone in your business is currently doing manual data re-entry, and the limits above haven’t scared you away, I’d take a long hard serious look at Google forms.


“Where there’s muck, there’s brass”

hydra photo

Photo by Andrew Jian

I was reading this Ask HN post about a consulting arrangement that seemed a Sisyphean task. Here’s an excerpt:

I have been asked to consult a company in how they should speed up their development process.

 

Today the application which in the end of it all is a web application, consists of a lot of old ASP classic code, a COM+ bridge for being able to function within a mix of a lot of different .NET libraries written in .NET 3.5 (CLR 2). COM+ acts as a bridge between the two technologies.

 

The teams cannot compile code inside the development tools, it can’t debug unless they do it with some obscure hacks and workarounds and it seems that no one is really in control of what is going on in the core code base and no one really want to touch the original code base to clean it up and refactor/re-write it.

Seems pretty hopeless, right?  “Teams can’t compile code”?!  Unfortunately, this type of task is more typical of consulting engagements than not. After all, if there was a simple solution, why would the company have engaged a high priced consultant?  (If you are consulting and not ‘high priced’, well, that’s a problem, but a different one better left for another post.)

The comments on the post are interesting and worth reading. I left one, but wanted to expand on it. Now, I’m not familiar with the tech stack at all, but I am familiar with a large codebase (where large is relative to the size of the team supporting it–100K LOC can be large to two person team) with a lot of technical debt that was crucial to the business.  I have also consulted for years.

Whenever you are consulting, the first task is always to ascertain the real problem.  Hint–it’s often not what you were explicitly hired to do.  In this case, I’m guessing the real issue is that the web application needs to change to meet business needs, and that it can’t do so fast enough because of the accretion of complexity.  But a guess isn’t good enough, you need to find out what you are being hired to do–it could be you are being hired to provide cover to spend money to rewrite the app or to be blamed when a development team misses dates or to actually speed up compilation.

Then, you need to learn who wants the task done, and who is writing the checks.  They are sometimes the same person, but not always.  You also need to learn how these folks want to be communicated with, including method, verbosity and frequency.

Finally, you can start to dig into the (software) problem.  (This process assumes you are doing time and materials billing.)  Do a preliminary investigation and look at some of the following:

  • given the end goal, what are intermediate steps that can get you there?  How long would it take to get one or two of these steps?
  • are there third party solutions that can get you 90% of the way to solving the business problem–this can include framework upgrades?
  • are there subsystems of the current hand coded solution that are isolated and can be reworked with minimal impact on the system?
  • are there one or two huge issues that would be a relatively easy win (version control, big bugs, moving configuration from code to a database, etc)?

Prepare ballpark estimates on the level of effort to accomplish some of these.  After that, you need to sit down with whoever wants the task done and whoever is paying for it.  Present your options, making it clear that any time estimates are truly SWAGs.

Let them decide.

If they ask for a recommendation, be prepared to make one, but the decision must be theirs.  They have the business context to know how much to invest in this system.

After that, either withdraw or start executing against the plan you and the decision makers have decided on.

Simple, right?



© Moore Consulting, 2003-2014 +