Publishing: Time to Solve for Product, Not Finances

Over the next few weeks, we’ll be doing a weekly four-part series called “The State of the Publishing Industry.” Every week, our CEO and Founder Matt MacInnis will share where publishing is today, what it will look like in the future, and how the smart companies will survive and thrive. (Hint: it won’t involve paper or even “eBooks”.) This week , we’ll focus on the roots of the publishing industry’s existential crisis.

As I’ve worked with large publishers over the last five years, I’ve witnessed the existential crisis the industry faces. Many think it’s about their finances, or perhaps their distribution channels, but it’s not. It’s about their product. As sales of traditional print media like magazines and books have declined, publishers have been left with a difficult question: if we’re not selling books, what are we selling?

We don’t think about cars as “gasoline versions” of horses, so it’s odd that we talk about “digital versions” of books. Winning software products don’t have digital versions; they’re just digital. They’re designed from the start to address a specific customer need. This notion of a digital “version” of a product is a mindset that has bedeviled the publishing industry, causing companies to focus on how they sell rather than what they sell. To win, publishers of all sizes must find winning software product models before considering the financial model behind them.

Of course, many smart people in the industry know this. Nonetheless, time and again I’ve seen the best efforts forward-thinking product leaders thwarted. One reason is that the financial models that underpin these mature businesses can’t be reconciled with a software-driven product model. Software products are developed on the scale of weeks, not years. Modern software is subscription-driven, not a one-time purchase. Nothing is shipped. Customers can “quit” your product. Financially speaking, the software business and the traditional publishing business look nothing alike.

One of the most amusing examples comes from the magazine industry. The Alliance for Audited Media, or AAM, mandates that circulation numbers, for the purposes of calculating ad rates and revenues, can only count “digital replica” versions of print magazines, essentially paper under glass. With these rules, if print and digital versions of magazines substantially differ, it’s more difficult to sell ads. This print-centric thinking is outlandishly short-sighted, and creates a powerful incentive to stick with gasoline horses. These kinds of structural and financial barriers to innovation are everywhere in the publishing industry.

When software development nonetheless occurs within a publisher, I’ve often observed an inefficient approach. Funds are often allocated to a finite set of projects, especially those deemed by executives to promise the best result. Despite claims to the contrary, those projects are usually tied in some way to the original paper product model. The critical failure is that the product hypothesis is generally tested only by shipping the final product, rather than through iterative testing of prototypes. When the product ships, it’s declared a modest success and further investment often dries up. People expect a “hit.” That’s familiar from the book world, but it’s not how winning software products are built.

Modern software development methods turn this model on its head, putting iterative customer testing at the center of the process. Software companies devote their resources to solving a known customer problem, taking dozens of ideas, some crazy, and exploring them rapidly with customers. They try things that seem impossible to “insiders.” The product is tested on paper, then in prototypes, then in tiny increments of finished product over time. When something ships, it’s already market-tested.

Of course, this model isn’t exclusive to startups, or even to software. Starbucks is a great example. They designate a handful of stores as “Rapid Test” environments, where they can quickly test new products, processes, and merchandising on real customers before broader rollouts. Academic and technical publishers, too, have a strong culture of testing their print products; they simply have to parlay this experience into agile software development methods.

Publishers do understand great content and how it’s built, so the ones that create winning product models around that content will thrive. The most successful partners we’ve worked with at Inkling have embraced the biggest lessons from software development. Here are three.

1. If you can’t describe the customer problem, you’re not solving it.

What problem, exactly, did a paper magazine solve in the 1980s? How about an encyclopedia? A textbook? Take a second to think about each one. You’ll note that the customer needs weren’t especially similar. Today, customers often meet these needs with different products. While the content is often similar, the product model isn’t.

If you’re developing new products, you must understand the customer need. For an academic publisher, is the customer the professor or the student? Is it about getting the best grade, or is more about getting a B+ with a minimum of effort and money spent? The nuances can be the difference between a winning product and a dud.

2. The most expensive way to test a product is to build it.

Designing, building and shipping software is the single worst way to find out whether customers like it. There is, quite literally, no more expensive way to do it. Yet large companies do this all the time. Sometimes the behavior is justified by secrecy (“we can’t show prototypes; our competition will find out”). Sometimes it’s the blindness of enthusiasm (“this is going to be so awesome, how could people not love it?”). But usually, it’s simply a combination of impatience and organizational momentum (“we have to ship it by summer, so we don’t have time or money to test it first.”)

The gold standard in software development is, by contrast, a process of indeterminate testing. Lightweight wireframes and mock-ups are tested face-to-face with prospective users and customers to identify the underlying customer need. Weeks or months later, prototypes built of explicitly throwaway code are shown. The insights (as well as recognition of your false assumptions) come fast and furious. All before you have written a line of production code. Eventually, you decide to build something real and ship it. And that thing is much more likely to succeed than your original idea, whatever it was.

3. Focus on speed, not quality.

It has been shown that optimizing software teams for speed, rather than for quality, actually yields the best quality. It’s counterintuitive but logical: by trying more approaches and allowing for more failure, the team that’s goaled on speed invariably finds better solutions than the team that’s looking for the perfect result.

Publishers should set up independent software development groups with a “full stack”: the right kinds of engineers, the content people, the designers, and the product owner should be capable of designing and prototyping products independent of anyone else in the company. Then, they can more quickly fail their way to success.

Over time, publishers will discover a pantheon of product models that fit their respective customers and customer needs. Every publisher that survives will become a software company. (Software eats the world.) The variety of software companies will be broad, and the publishing industry itself may cease to exist as a category. Instead, we’ll see publishers as a group of content-centric software companies melded into the technology spectrum.

For the rest of my life, there will be books, as there are horses. The book is a wildly successful product model. But what replaces the book will not be ebooks. It will be a spectrum of software products as varied as the vehicles that take us around the corner or around the world. It’s an exciting opportunity for those bold enough to embrace the challenge.

Guiding us will be some “rails”–some common constraints–on which all content-centric software companies must run. In my second article in this series, I’ll discuss the most important constraints. For example: the world will publish in HTML, and the cloud will eat apps for breakfast. There are more. Thankfully, the costs of shipping, ink and paper are not on the list.

Curious to learn more about how we’re helping publishers tackle these problems? Check out our solutions for publishers on our website. Otherwise, stay tuned for next week, when Matt will outline the constraints under which the new world of publishing will function.