Don’t Be Embarrassed

“If you’re not at least a little embarrassed by something you just launched, you probably waited too long to start it.” So says Alexis Ohanian, founder of Reddit and a number of other high profile web media products. This statement, provocative as it is, actually is little more than a smart synthesis of the current state of play in the world of online product development. You no doubt hear variants of this theme regularly, sometimes expressed as “minimum viable product,” “rapid iteration,” and even “fast fail.” They all embody the philosophy that it’s more important to launch a new product quickly than launch a really good new product. I credit Google for raising this practice to high art by teaching users that the word “beta” appended to any product name excused the product from delivering much value, or even working properly, for an often extended period of time.

I certainly agree that there is an imperative for speed in the world of online content. We’re surrounded by hordes of competitive start-ups, many of them explicitly attempting to disrupt market incumbents. But before we decide to emulate these companies, it’s important to note their typically distinctive business models.

First, most of these not-ready-for-primetime products are thrown onto the market for free. The companies behind them are betting that if they can build an audience and usage, everything will work out fine in the end, even if they don’t generate any revenue in the short-run. Further, most of these products come from start-ups, so there’s not much in the way of reputation risk. Thirdly, these companies are staffed and funded to iterate rapidly – some actually push out updates and fixes on an almost daily basis. If you’re going to play in this world, you can’t just talk a good line about evolving the product – you have to deliver, and often at a blistering pace.

That’s why I would argue that for most established data publishers with subscription businesses, applying this approach of pushing out half-baked new releases can be very dangerous. When working with an existing customer base, be clear that your subscribers don’t value speed for its own sake – they want clear product improvement. And frankly, this shouldn’t be that hard. You’ve got the advantage of a successful existing product you want to evolve, so you’re not starting from scratch. You’ve got loyal customers who will test with you and offer input. You have a deep understanding of the market you serve, so there’s no need to guess about what might be useful or compelling. Perhaps most importantly, your subscribers often need your data and your tools to conduct business. That’s a world away from a nifty new pizza delivery app. You have an implicit obligation to move prudently and get it “as right as possible” right out of the gate.

So yes, constant evolution of your product is essential. Speed is important. It’s also important to understand that nothing will be perfect the first time around, and that’s okay if you fix problems as quickly as they are identified.

What about new products from established publishers? First off, if you plan to charge for the product from the start, this comes with a much higher level of subscriber expectations. If it’s free (at least initially), expectations are lower, but be aware that those who go away unimpressed probably won’t come back. Finally, being embarrassed may well be an issue for an established publisher known for quality data and solid applications.

So before speeding up, slow down and think it through. The people advocating speed often are in a very different place from you.

TripAdvisor and the Ignorance of Crowds?

We all know the many benefits of user-generated data, including ratings and recommendations. Underlying all of it is a general belief in “truth in numbers” - if enough people say it is so, then it must be so. But what happens when the crowd returns a result that is obviously and intuitively wrong? A small but perfect example of this occurred recently when TripAdvisor published its list of “Americas Top Cities for Pizza.”

I’ll spare you the suspense: the top-rated city for pizza in the United States is (drumroll, please) ... San Diego, California. Are you already checking flights to San Diego or are you shaking your head in disbelief? I am guessing the latter, and that’s exactly my point.

Something went wrong in this tally by TripAdvisor. Most likely the underlying methodology wasn’t sound. TripAdvisor merely rolled up ratings for individual pizzerias and restaurants around the country and ranked them by city. There’s a little problem with that: context. What TripAdvisor converted to a national ranking were individual ratings made in the context of specific geographies. That’s why you see comments for top-rated San Diego along the lines of “it’s just as good as New York.” These people clearly didn’t see themselves voting in a national poll.

Also odd is that TripAdvisor decided to go ahead and publicize the results of this analysis. Clearly, TripAdvisor saw the potential for buzz with its surprising findings. Yet the flip side of this is the creation of a credibility issue: if TripAdvisor thinks the nation’s best pizza is in San Diego, how can I trust the rest of its information?

A few lessons for the rest of us can be found here. First Big Data is only valuable if properly analyzed. Second, evaluating data supplied by a large and disparate crowd can be tricky. Third, always balance the potential for buzz in the marketplace against reputation risk. Say enough dumb things online and you will hurt your credibility.

TripAdvisor will no doubt say in its defense that it is simply reporting what its users are saying. But if your user base is saying something dumb, it’s probably not in your interest to amplify it. And in fact, the TripAdvisor user base isn’t dumb; their individually smart comments were aggregated in such a way that they yielded a dumb result. But most people aren’t going to dig that deep. They’ll simply say that’s one less reason to rely on TripAdvisor.

A New Push to End Passwords

I hate passwords. But I don’t hate passwords as a concept. Certainly I understand the need, but password protection implemented poorly creates friction and often frustration, and that’s not good for business or for my own personal protection.

Now there’s a new initiative out of Silicon Valley called the “Petition Against Passwords.” It’s not proposing a specific alternative, but the basic premise is that we can do better. And the initiative seems to be getting some early traction. But I think that before we try to improve, we also need to address our failings.

In my view, because online security has become such a high profile concern, many companies have given their programmers carte blanche to “beef up security.” And beef they have, adding all sorts of onerous restrictions, cool new programming and faddish techniques that satisfy their intellectual curiosity, but put a big dent in the overall user experience.

Several years ago, I bought one of the most popular password management programs called Roboform. It actually will provide long, randomly generated passwords for every site where I have an account. Once set-up, I could access any site with a single click. Nirvana! I was fully protected, and friction was eliminated. This was a win for everyone. And it worked. For a while.

But I’ve watched as RoboForm has become less effective, as more sites institute cool new login processes that force you to do more, remember more, and defeat the popular password managers.

I have one site that insists I manually input my password into a virtual keypad on the screen. Way cool, but essentially pointless. I have another site with no fewer than ten challenge questions that it presents randomly, with responses that have to be entered perfectly, or you are locked out and forced to spend 20 minutes with their call center to get back in. Still another site wants a ten character password that includes both a capital letter and two non-alphanumeric characters. And the latest cool approach is “two-factor authentication,” which sends a separate code to your cellphone every single time you want to login. Honestly, can you picture yourself doing this several times (or more) a day? We want more user engagement, not less.

Where I come out is with this simple, three-point proposition:

1. Login security should be proportionate to what you are protecting, a point of particular relevance to online content providers. Let’s be honest with ourselves: we’re not protecting nuclear launch codes.
2. Don’t leave login protocols completely in the hands of your programmers. Logins are a critical component of the overall user experience and need to be assessed accordingly. If users aren’t logging in, they’re also not renewing.
3. For most of us, time would be better spent improving our back-end system security, to reduce the chance of wholesale theft of user logins, credit card data and personal information. That’s where the big business risk resides, although the necessary programming is admittedly less glamorous than virtual keypads.

So sure, let’s start talking about eliminating passwords. But first, let’s acknowledge that a lot of the problem is self-inflicted by the way in which we have implemented passwords.

Hands-Free Database Access from Vivino

There is a cool new app out of Denmark called Vivino, that besides being just plain useful, also offers a great working example of both mobile visual interaction with database content. Vivino lets you use your smartphone camera to take a picture of the label on any wine bottle, and have returned to you complete information about the wine. Yes, it’s a true hands-free database query.

The data can be used strictly for educational purposes, as a way to learn more about a particular wine. At the same time, its point-of-sale implications are huge.

The heart of the technology is image recognition software that can match the photograph of a wine label to Vivino’s standing database of over 450,000 wine label images.  And the database is not just for look-ups: if you like a wine, just flag it in the database with the push of a button, and the system remembers it for you.

Another feature, apparently still under development, is the use of your geo-location to identify nearby wine stores. And of course Vivino has the requisite social sharing features.

What’s also of interest to data publishers is that if Vivino can’t match a wine label, it manually researches it using its own research staff, and sends the information to the user once it makes a match. That has the triple benefit of engagement, enhancing user satisfaction and expanding the database.

Vivino is still in beta, but monetization options are plentiful. It’s worth noting that the wine database space is very crowded, but there doesn’t yet seem to be a dominant player. And if you picture yourself in a wine shop, you can see the innate appeal of being able to snap a picture and get a full profile on any bottle of wine. This is a truly powerful and productive use of mobile technology.

Vivino provides an eye-opening insight to all data publishers: sometimes you can make your existing dataset more valuable just by enhancing the ways users can access it.  This is doubly important in mobile applications, where large fingers and small keys rarely make for a satisfying user experience.

IDG-Linkedin Partnership: Re-Defining Publishing?

Just yesterday, the major business publisher IDG, through its Custom Solutions group and its ComputerWorld, InfoWorld, CIO and CSO media properties, announced a partnership with LinkedIn to create “targeted marketing opportunities for b-to-b brand marketers.” So what does this partnership means? It appears that IDG will sell to its advertisers the right to sponsor an IDG owned and operated LinkedIn group on either a specific IT-related topic, or a custom LinkedIn group likely tied to things such as new product launches. In the latter case, the advertiser controls the direction of the group.

On its face, this seems like a clever sponsorship idea. But then you might ask why does IDG need to partner with LinkedIn to create a LinkedIn group? Anyone can do that. For that matter, why does the advertiser need IDG to create a LinkedIn group? The answer is partly content, and mostly audience. And here’s where it gets interesting.

LinkedIn’s role in this partnership, according to Folio, is to “be responsible for promotion, content distribution and member recruitment.” Yes, LinkedIn is going to be supplying both audience and content distribution. What IDG is bringing to the table is the advertiser, the content and management of the group.

Traditionally, the role (and much of the value) of the publisher was building an engaged, target audience and charging to deliver messages to it. Here, both the audience and the distribution platform no longer belong to the publisher.

I’m not disparaging this deal; indeed it has hints of brilliance showing through. But what intrigues me is that LinkedIn, a professional network and data content company, can now so effectively perform most traditional publishing functions.

While I admire LinkedIn for building the most important biographical database in the world (still the primary source of its revenue), it is also both a powerful network and content distribution platform. LinkedIn groups thrive for tens of thousands of specialized audiences, and LinkedIn has shown real talent in selective news distribution to users. LinkedIn has all the elements necessary to be a major publisher in its own right. To date, however, it has chosen to be a platform rather than a publisher.

It’s likely we will see a greater shifting and blurring of roles over time. Already, we have examples of companies that leverage LinkedIn groups to build publishing and events companies. And IDG shows us here an example of a successful publisher leveraging the power of the LinkedIn platform.

I don’t see LinkedIn trying to muscle itself into B2B publishing, but I think this is the first indication of a profound re-definition of the publishing business. This is not necessarily bad news, but if you thought things were settling down, you better fasten your seat belt.