Month: October 2012

Dalton Caldwell has really stirred the pot about Twitter failing the Tim Berners-Lee vision of an open web by abandoning their platform strategy, failing to be data portable, and accepting ads as a business model. I wish him luck as he embarks on his journey with app.net to right those wrongs, but the truth is that Twitter had the right decision made for them – platforms are really hard.

I’m not saying that platforms are impossible. Can platforms be built? Yes. In fact Caldwell’s new project has a much better chance of succeeding than Twitter would have at the point at which they abandoned their strategy.

Why? Because a platform built on the foundations of a company already valued orders of magnitude more than the revenue it would generate as a platform would have doomed Twitter.

That is where Twitter had the decision made for them.

Why couldn’t Twitter have pulled it off? The life cycle of a platform is a unique one compared to other business types. The platform has to pre-date the applications who will build on top of it. It then has to maintain a leadership position in its space without being replaced by latecomers, copy cats, and vertical integrations. Finally, it has to be able to support a robust set of use cases once the market has matured without becoming irrelevant.

The first phase is incredibly difficult because few companies know that they should build a platform from the get go. By the time they’ve figured it out, the piece working against them, and I’m assuming that they are VC funded for this post, is equity economics. Why? The pivot most likely involves losing any revenue and firing most of the customers you’ve spent your previous equity signing up. Now you’re starting over, but you’ve gotta convince folks to take C-round equity for an A-round company.

Luckily for app.net, Twitter has already done that work for them. They’ve demonstrated a market exists, and created the demand for an open solution. At the time Dick Costello took over at Twitter, they had taken hundreds of millions in funding, and there was no way committing to the no-revenue (or we’ll figure it out) business model was going to be a viable option.

The second phase is a tough one. Product market fit as a general solution is difficult. Folks showing up solving a vertical within the space are going to solve it better than you within the vertical. Copy-cats will show up trying to solve the general solution better given what they’ve seen you do wrong. Google is a great example. They compete simultaneously with Kayak and DuckDuckGo. Without some defensible asset, a platform will be run over by the gold rush to take over the new white space created.

I think app.net is starting in this phase, and needs to prove that there is enough white space in the form of customer demand. I know that the tech ecosystem is excited by data portability, partner incentives, and the like, but does Oprah care enough to get 25 million people to sign up for it?

I’ve never lived the third phase, but I imagine the folks at Adobe are trying to figure out what they did wrong in this regard. With YouTube, they were on top of the world. The Internet needed Flash, and Adobe was going to be the king of the roost. Then, all of a sudden, with the iPhone, Flash became the ugly step-child of the web. And just like that you’re irrelevant.

The app.net stack is a long ways off from that, and I hope they get there, but it will be interesting to see what happens in the meantime.

Good luck Dalton Caldwell, and the app.net team, but at this point in the game your best bet is to thank Twitter for paving the way, and focus on taking over the white space they carved out. Oh, and Twitter definitely made the right choice for themselves.

I want to be able to simplify the interactions I have in a given day to a single purpose. As an example, I’d like to claim that the hammer is there to work with nails. But the hammer isn’t that simple of a product.

Similarly when people ask me what’s the purpose of a given web service, I have a tough time giving one answer. In fact, the easiest way to get to one is to say that a given web service is what the individual needs it to be. Easy examples include Facebook as a photo album, or as a long distance phone call replacement. Or Twitter as a breaking news source or a trash talking platform.

We no longer build products in the traditional sense. A saw is no longer just valuable in cutting wood. We’ve started to see a world where the saw is a musical instrument or it’s a prop in a halloween costume. The consumer can now imagine a role for the product well beyond its intended purpose.

As the creator of products, this poses a few challenges. Our existing paradigms are built around the idea that a single audience will interact with a function in a single way. Our communication strategies narrow down on demographic targets and market-researched tag lines. However, in a world where my mom and I are both the target audience, how does the product manager define the purpose of the product? And as we are no longer building single-purpose products, but instead we’re building general tools, how does the product manager optimize the user experience?

The answer for me is twofold – building a sandbox, not a shovel and making sure the prisoners don’t run the prison.

Building a sandbox, not a shovel
Very simply put, web services succeed because they define a scope, and then allow for creativity within that scope. Facebook has changed the rules over and over again, but people continue to find ways to uniquely express themselves. When profiles were at the center of the service, the graffiti wall app was one of the most popular. When Facebook started to move towards the News Feed, we saw the introduction of the “Like” phenomenon and people expressed themselves through their “Likes”. Now that the News Feed is not only king, but exists in two forms, the News Feed has become the viral loop that games, Spotify and other applications use.

All of this is made possible because Facebook has built a sandbox in which everyone is allowed to play.

I make a very similar metaphor to friends who ask me what Twitter is. My response is 140 characters of whatever is important to you. For some it’s going to be shared links; for others it’s going to be commentary on sports; and for most it’s going to be the mindless babble of friends. Regardless, the genius of Twitter is that it’s a sandbox, and you’re free to play in it as you deem fit.

Build sandboxes, and let your end-users show you what’s possible.

That to me feels like a very powerful mantra for product development.

Don’t let the prisoners run the prison
There is however a catch to letting your end-users show you what’s possible. It doesn’t give your end-users the right to define your road map. I think that we can call this the Digg Paradigm. A web service builds a sandbox, and needs user-generated content to bring people to the sandbox. It then starts to shape the sandbox to fit the needs of those early adopters.

The danger here is that your road map is driven by a set of end-users who have a very specific vision of your sandbox.

The inverse comes from Twitter. The early adopters invented the retweet (RT) and the hashtag (I think). The Twitter folks are on the record saying that they hated those things, but once it became a part of the Twitter culture they reacted accordingly and made sure that those were part of the sandbox. That hasn’t, however, stopped Jack Dorsey or Dick Costolo from driving Twitter towards the vision that they have for the sandbox.

This is true not only of the suite of Twitter products managed by the company, but also in their vision for the platform.

Let your end-users build a culture within your sandbox, not their own sandbox

That’s the final lesson for today’s post.

I wanted to do a post-mortem on aboutmydive.com.

This was my first attempt at building something that I hoped would become more than a project. It didn’t, and I think it failed for a few simple reasons that I wanted to share here.

1) No audience interest
I thought that because I wanted to log my dives that everyone would want to do the same.

There isn’t a strong online community that I could find around diving. I think it’s because diving is still a very analog activity. It happens in real life and is either dominated by vacations (where I’m not going to bother finding Internet to upload my log) or local diving crews who simply weren’t interested in logging their weekend dives.

As a result, I just couldn’t convince anyone who I wasn’t friends with that this was a cool idea.

2) It needed to be mobile
It turns out that folks dive in remote locations. They don’t want to write it all down in a book, and then transfer the information to a website. It needs to work on a mobile device, be stored locally, and then uploaded once cell coverage is reached. I didn’t build that, and therefore I couldn’t get folks to use it

3) I didn’t have a road map
Without a road map, there’s very little chance you’ll succeed. The issue is that you’re constantly jumping from one feature to another. You have to force yourself to sit down and say that A is more important than B, and therefore I’m going to do A. If you don’t, then you’re constantly flipping between the two with no real hope of getting anything done.

Once you understand that A is important, you can start to ask questions about how to best deliver A. That train of thought really allows you to get to the best possible product. The flip side, which is constantly context switching, simply leads to lots of half-finished ideas.

I’m really glad that I tried to build AboutMyDive.com. I knew it wasn’t going to be easy, but I learned a lot. I definitely think that the new project I’m working on is going to be more successful based on these lessons learned. That doesn’t mean it’s going to be the winner, but, at the least, I won’t make these mistakes again.