When Mendeley was founded, the apparent aim was to build a fully operational business. The Mendeley team worked from the tech industry playbook: develop an innovative service; wherever possible leverage the investments of others (e.g., published research material); move aggressively to build a large user base; finance the company through equity, in this case venture capital; and focus on revenue generation later. Cynics, who don’t understand equity financing, criticized the company for losing money, even though the same could have been said about such giants as Google and Facebook in their early days (but never about Microsoft), and look at them now. As time passed Mendeley attempted to create a revenue model. This was fatuous, as all of the ideas for monetization put Mendeley into commodity businesses (e.g., hosting content) where scale is everything, but it was an honest attempt. Meanwhile, IP lawyers were lurking in the background, trying to determine the best time to drop a lawsuit on the backs of the earnest management.
What we discovered in time was that Mendeley was not a business but a feature. Its acquisition by Elsevier proved the point: of little or no economic value on its own, when bolted onto Elsevier’s existing operations, Mendeley added new value to its users but especially to Elsevier itself, which was now in a position to get a wide view of the usage of a huge amount of research material, its own and the publications of others. Not incidentally, this was in part a library bypass strategy, as Mendeley provided Elsevier with a great deal of end-user information, an area where librarians are stubbornly unhelpful. As a feature, Mendeley may ultimately prove to be a great success, perhaps on the order of one-click purchasing from Amazon (a feature, not a product or a business) or the “retweet” function in Twitter. As a business it was “meh.”
The differences between a feature, a product, and a business are critical for any businessperson, but in the world of digital media the lines between them are often obscure. (There is a fourth element to this typology, the ecosystem, but that may be the subject of another post.) This is because bits are free and invite experimentation. Get three publishers into a conference room together or, more productively, at a bar and wait for the conversation to turn to something like this: “Wouldn’t it be cool if we could [insert your feature here]?” And it would be cool. Conversations like these mostly focus on new things that would be appreciated by end-users–because we are all, at certain moments, end-users ourselves. This creative process is valuable, but it ultimately has to be married to how the new capability will be expressed in an economic context. Hence the defining question of the age: What is the business model?
I don’t mean to pick on Mendeley; I think the management did a great job and found a good home for the service. Rather my point is that not every new thing has the potential for becoming a business in and of itself, nor should we make such a demand.
So what’s the difference between a business, a product, and a feature?
- A business is a self-contained economic enterprise. It has revenue, expenses, and a profit or surplus. Some businesses are not consistently profitable; some are not profitable early in their history, but could become hugely profitable later. When we use the word “sustainable” in the world of scholarly communications, this is one form (the best one, in my view) that sustainability takes: a full-fledged business that has found its way to profitability.
- A product, on the other hand, may generate revenue and have costs associated with it, but it may not be sufficient to float an entire enterprise. Almost all publishers have multiple products. Is there any book publisher that publishes a single book? Although there are some one-product journal publishers that are profitable, for the most part profitability in journal publishing is a function of scale. If Elsevier had only ten journals instead of more than 2,000, its famous 39% margins would be much, much smaller. (This, by the way, is why Elsevier is so profitable: scale, not pricing.) Almost always a successful company has a portfolio of products.
- A feature is something that is an addition to an existing product or suite of products. This is not always apparent to the feature’s creators, but over time it becomes clear what is truly a product or a complete business and what is really an add-on (even a highly desired one) to something else. Sometimes a feature can have a revenue stream associated with it, but the feature cannot exist without an underlying product. A good example of this is New York Times Premier, which includes (for a fee) access to special information that is not available in the base subscription.
It takes but a moment’s reflection to see why publishers everywhere are so product-focused. A feature may not add any revenue, but a new product always does. Indeed, a new feature may simply increase costs, which makes publishers resistant to adding them unless the competition in the marketplace requires it. Want responsive design and the ability to display content on mobile devices? A feature without additional revenue. COUNTER compliance? A new feature, a new cost. Open access? A feature with no incremental revenue associated with it (hence the reason publishers might try for “double-dipping” with hybrid journals). Librarians always ask for more features (users rarely do), which drives up costs, and the only recourse a publisher has is to raise prices because no new market is being addressed. A genuinely new product, on the other hand, adds to revenue and helps to offset a publisher’s fixed overhead.
This doesn’t mean new features are bad things. We all want them, though we rarely want to pay anything when they are offered to us. The challenge for creative people working in this industry is to identify features that can be provided at no incremental cost (rare); features that change the competitive landscape (generating additional revenue by driving out the competition), though this typically becomes an arms race; or features that can stand on their own two feet–which, by definition, makes them a product.
Sometimes the clever way to bring a new feature into the market eludes people for years and then suddenly someone finds the solution. I think we are going to see this with annotation in the next couple years. At this time the annotation of texts is being investigated by many people, but no one has yet figured out the secret sauce that will get anyone to pay for it. Partly this is because annotation is a big topic. Is it simply an online form of footnoting or more like the comments sections we see on blogs such as The Scholarly Kitchen? Can a robust annotation scheme enable meaningful post-publication peer review? How do we design the interface so that we see the annotations we want and are not distracted by those we don’t? And while we spend hours trying to figure out the design and capabilities, how are we going to pay for this? Is annotation an add-on to an existing service (a feature)? A B2B opportunity wherein the annotation capability is marketed to all the platform companies? Or perhaps it’s a wedge in which users are attracted to the annotations and are then “upsold” (i.e., enticed to purchase another product) to something that is in itself revenue-bearing? Annotation will be “solved” at some point when an entrepreneur takes up the case. Entrepreneurs always emerge when you least expect them and then solve the problems you did not know you had.
Meanwhile, we should disabuse the inventors of great features that they have a business in hand. They may be disappointed to hear this, but it will save them time and expense. They could be out trying to raise money to launch a company, but it may be that all they really need to do is to craft something useful and elegant and allow other entities to figure out the business model. Not everything is a business, nor should it be.