Web dev at the end of the world, from Hveragerði, Iceland

Changing your readership mix

(This is the seventh post in a series on the publishing industry’s new product categories.)

The mix of reader types in your readership isn’t an unchangeable fact, a curse bound in iron by the gods of old, a universal constant for all eternity. It can be changed.

Actually, that isn’t really true. The readership mix for most titles and genres is probably set in stone, one of those big blocks of ‘fixed, can’t change’ that you just have to work around.

What you can do is create a new readership with a new product in a new product category, but one that uses the text, images, and other materials from the old product. A new product that appeals to a market that is different from your print edition.

Most of those new product categories are just rebadged interactive media, and to create those you need people who know how to create interactive media (interactivity designers, app developers, or whatever you want to call them).


Most publishers give the digital edition of a title thought only after the fact—after the book has been written, edited, proofread, line-edited, typeset, and on its way to the printers—preferring to see what they can accomplish by tweaking whatever piece of digital rubbish their print workflow automatically craps out, wipe the InDesign shit-stains off it, and call it an ebook.

If you want to do something interesting with the digital edition of the title, you need to plan this right at the start, before any work is done on the title. And please do involve a professional developer right at the beginning. Think of them as co-authors of the digital edition and not as carpenters putting up a shelf you’ve specced out.

Once you start, once you’ve planned the print version of the title, your options for the digital edition go down dramatically. At that point, the easiest thing to do is to gloss up the title with idiotic ‘enhancements’ or other interactive doohickeys. Anything else is too expensive because you are, in effect, reinventing your production workflow on the fly.

Don’t do that. That’s crazy.

If all else fails and you’ve been given the task of adapting a pre-existing title into digital, you have a simple set of options:

  • If the title is likely to have an ebook-friendly readership and the title is structurally an easy match for ebooks, just do a basic ebook.

  • If the title doesn’t have an ebook-friendly readership but is easy to adapt into an ebook, do one and hope you get lucky.

  • If the title won’t sell as an ebook and won’t be easy to turn into an ebook, don’t do an ebook. Do something radically different.


Avoiding wild dogs/ebook fanatics

One reason to do a totally unviable ebook that’ll just lose you money and only sell three copies is to avoid PR backlash. You see, people who want ebooks really want ebooks. They get very angry when there isn’t an ebook version and will complain loudly. It’s better to do what they—.

Hah! Had you going there for a moment. Don’t do that. That’s crazy. Here’s a simple rule for you:

Ignore crazy people who haven’t already given you money.

Which problem would you rather have?

  1. A few nutters complain on Twitter and on Amazon that there isn’t an ebook version available. Most people ignore them.

  2. A few dissatisfied nutters keep sending you support emails because the ebook edition you released is much worse than the print edition because it was a money-losing low-budget production.

I’d choose the first problem every time. The last thing you want to do is piss people off who’ve already given you money.


What does ‘radically different’ mean?

So, you’ve backed yourself into a corner. You have a title that probably has to be something other than an ebook.

At this point your only real options are:

Either do nothing (a perfectly valid choice, since nobody runs a business specifically to lose money, doing nothing is always an option)…

Or, you take the title and everything related to it, give it to an accomplished app developer, and tell them to make something out of it. Don’t tell them what to make because, if you work in publishing, you are almost inevitably clueless and incompetent when it comes to the web and apps. Give them a target audience they should serve. Any involvement by you beyond instigating the project will decrease its chances of success. Or, judging by some of you, it would massively decrease its chances.

Tell them to figure out a new product with a new title (the old title’s readership isn’t interested in digital, remember) using your materials. Set up whatever rules, goals, and benchmarks you need to feel comfortable. Set up whatever licensing agreement you both think will make you both some money. Then get out of the way because, honestly, if you’re in publishing, you probably don’t know what you’re doing.

(In digital media, I mean. Oh, you thought I meant in general? So, sorry.)

Best part? You can do this again with another developer. You can give another developer a brief to create another product from the title, for another target audience, with another name. Once you are playing at this level you are creating completely new products with new titles that just happen to be based on your stuff. Why limit yourself to one go at the roulette table? Especially if you can convince the developer to do the project without paying them up front payment while sharing the profits.

Even better, there’s a way for you to get almost unlimited tries at the table at little cost to yourself—all upside: just create a standardised licensing kit for a selection of your non-fiction titles. You don’t even have to do an API, just what you might call a ‘content developer kit’ or CDK: a zip package of the title’s content in a structured format that developers can license on whatever payment basis you want. Bonus points if you set up a self-serve ecommerce site where developers can buy CDKs at whatever price you set (preferably royalty-free; there’s room here for flexibility). Just lay down a few branding, contract, and promotional guidelines and you’re good to go.

You probably have to require your licensees to use something like “this app is based on X, published by Y” in their app or web descriptions, for the consumer’s sake, though.


Building up in-house digital product development is risky and expensive, especially at the start when you have to build up the necessary expertise and tools to do the job and change your organisations implicit value network.

The problem is that changing an organisation’s value network is next to impossible without firing everybody (yourself included) and replacing them with different people. Adding individuals who have different values from those prevalent in your organisation won’t change the value network. It’ll just make your new hires miserable before they quit or get fired. Which means that building a top notch, in-house digital product development team is going to be difficult for most publishers.

So, either partner up or build the team that is isolated and sandboxed from the rest of the company’s incompatible values. For most publishers, anything else is unlikely to work.

You can also find me on Mastodon and Twitter