Founder Blues

I didn’t need to be a genius to see t where things were headed. This week my “partners” canned me. The official reason is “termination without cause,” which is important only because it ensures that I will receive a substantial number of shares (and small amount of cash) in the company, thanks to an accelerated vesting clause that I insisted be a part of the shareholder agreement we all signed.

Kevin Wolf is a founder of Yurkle, a community media site for online services (not sure what that means, but the site hasn’t launched yet). He was fired by his partners and shares his thoughts on lessons learned. Tough situation, I empathize with him but there is only so much that can be done structurally to protect yourself in a partnership that isn’t working. If you are going to raise venture money and have a shareholder agreement that has a lot of protections for the founders built in, well it’s likely to get tossed as part of the new funding event anyway.

Having partners in any business is tough because there are all manner of issues that come into play around trust, communication, control, and open-ness.

Ellison Eclipsed By the Red Moon

"But as the losses mounted against Luna Rossa, disgruntled supporters sent e-mails to the BMW Oracle team calling Ellison an egomaniac and questioning the team’s confident, corporate approach, which had propelled it to the top ranks of the favorites to race against Alinghi."

No way! Egomaniac? Puuhhhhllleeeeze, they are just jealous!

Actually, I am disappointed that BMW Oracle lost to Luna Rossa because it is called the America’s Cup and that means we are supposed to WIN! Actually, in all seriousness, the America’s Cup is pretty interesting (to follow, it’s boring to watch) because it some aspects it actually favors the challenger. The Cup defender only races against the challenger during the actual America’s Cup series, while the challenger has the benefit of racing, and winning, against the other challengers during the Louis Vuitton Cup series, the winner of which proceeds to the America’s Cup. On the other hand, the defender gets to establish the rules for the race, which would be like the winner of the World Series taking over Major League Baseball for the next season.

Sadly, America’s Cup yachting has become all about money these days with teams raising hundreds of millions of dollars to fund cutting edge boat design and the best crews who, irrespective of what country they are from, crew for whoever pays them the most. Indeed, Alinghi’s first crew was poached from Team New Zealand’s winning boat… and for the current series the nationality rule was ditched altogether.

The America’s Cup oversight organization is trying to transform it into a waterborne version of Formula One despite the fact that it’s drop dead boring to watch, isn’t amenable to spectators because it takes place off shore, and features weather related scheduling challenges that kill television broadcast schedules. Let’s also not overlook the fact that boating at this level is an endeavor reserved for billionaires that you and I have little in common with… NASCAR it is not except that big sponsors love it because of the association with luxury.

PS- yes, I am particularly proud of the title for this post.

Helio – Should I Call It a Phone?

I keep getting promotional mail from Helio offering discounts on their handsets and the service. Their tag line is "don’t call it a phone"… okay, what should I be calling it and can I make a phone call on it?

First a little background, Helio is a joint venture between SK Telekom and Earthlink to bring a true 3G network to the U.S. while operating as a MVNO. They offer three handsets, two manufactured by Samsung and the third from Pantech I believe. From their website it appears that mobile entertainment is their primary focus, including music, video, myspace, and games, which makes sense given the advanced capabilities their handsets feature.

I’ve been watching this company for quite some time now, from 2005 when it was reported that SK and Earthlink invested $220m in the deal. I’ve seen the devices at Fry’s and have walked by the Helio store on University Ave., although somewhat disappointingly as there never seems to be any shoppers in that store.

Basically, I am in one of the sweet spots for their market because I love gadgets and I am a heavy mobile user, although I am not much of a consumer of mobile entertainment but I would certainly subscribe to mobile games if the quality is "good enough".

I have been looking for a reason to buy a Helio but I have yet to find one and the "don’t call it a phone" message just confuses me because I want my mobile network operator to put coverage and call quality as their primary focus, and all the other stuff becomes something I find greater value in as a consequence of the call capabilities being superior. Having said that, I do think they are smart to not follow AT&T’s "more bars" campaign emphasizing call quality and coverage… but at the same time that does not mean Helio should de-emphasize calling capabilities.

Anyone have a Helio and can comment?


The Business of Mashups – APIs

In the first installment in my ongoing series of mashups posts I looked at the word itself and why edge driven integration and user generated applications are a potentially a disruptive force inside the enterprise as well as else ware. For this post I want to start a discussion on APIs and their impact on business strategy.

I thought it would be helpful to go right to the central topic at the heart of the mashup meme because without them you don’t have anything to mashup. APIs have been around for decades, first as proprietary interfaces that developers used to gain access to a server application, later evolving to what we have today, a broad range of public and secure programming interfaces that are being used to create new applications on top of popular services, build ecosystems around companies, and lastly they have a promise of creating a potential new distribution channel for application providers.

APIs obviously rely on two basic parties, a provider of the API and a third party who wishes to use the API. It’s like a pitcher and a catcher, one without the other is of little utility. The challenge for everyone is that the "sell side" and the "buy side" have different motivations and requirements that often put them in conflict with each other. Let’s start by taking a look at the API provider and the challenges and opportunities they face.

So you have a hosted service (although you can certainly do this with on premise as well) and want to encourage third party developers to build out applications on your service. The first question you should ask yourself is why you want to do this, and "because I can" is probably not the best reason for proceeding. Do you want to extend your application with vertical add-ons, or encourage alternative client applications, or distribute your app through third party channels, or just create some buzz. A lot of companies just want to create buzz so APIs are really more a part of a marketing strategy than a business strategy.

Let’s assume you want your API to encourage third party developers to create new apps that extend the reach of your service. You publish a spiffy new REST API and blog about it and then nothing, which does happen a lot because developers don’t always consider the incentives built into such schemes. What is in it for developers who do wish to take advantage of you API if the primary benefit is going to you as the provider of the core service?

If you are the carrot is the customer base you hold, and the promise of lowered cost of sales for third parties who build apps on SFdC and then offer them through Appexchange. For SAP and Oracle the same applies although it’s delivered not through online but direct sales means and Microsoft has their SMB channel. What if you don’t have a big customer base? Well I guess you need another carrot.

Smaller companies can use APIs to deliver functional components to external developers not as a means to tap a customer base but on the hope of growing one. Xignite is a great example of this approach, their web services are used by external developers to augment their products with functionality that would be difficult to build organically. Need realtime currency conversion functions or a data feed with live precious metal pricing, Xignite has service components for you.

Most companies are somewhere in between and Xignite, they have an application service that could benefit from having external developers build out functionality or integrate with other applications and the technical means to that end is an API offering and a developer program built around it.

Challenge #1: If you business is dependent upon driving visitor traffic to your website, as is the case with a lot of web 2.0 sites, how do you support your business with an API strategy when the end result is that users of that API may in fact never visit your site, thereby depriving your business model of necessary oxygen.

Challenge #2: Your customers are paying a subscription to access your service and you want third party developers to build out extensions. Is your expectation that your customers will pay you for the service AND the external developer for his/her application?

Challenge #3: There is no such thing as free in software, everything has a cost. Assuming #1 and #2 are not insurmountable, how do avoid becoming a victim of your own success? Even Google limits the number of API call an application can make in any given period of time.

Let’s assume that you have a well thought out business strategy upon which you will offer your APIs, you have a customer base that will benefit as a result, and a pool of external developers ready to take those APIs and do goodness with them. What do you do now?

First thing you need to tackle is documentation because a great API that no developer can figure out isn’t going to do you or anyone else much good. Google Code offers a great example of an integrated approach to API documentation and community, but even their services are spotty with regard to documentation. Google Maps is fantastic, Google Calendar’s documentation leaves a lot to be desired, which is just one reason why you don’t see a lot of Google Calendar integration. DabbleDB has a great help center and provides a good example of how a small company can invest in documentation for the benefit of external developers.

I’m going to write about security and identity in a future post so I’ll skip over that important topic here, but one area that does deserve a mention here is performance. APIs that are unresponsive or slow do not instill confidence in your external developers that you are committed to helping them and they won’t build out on them as a consequence. If you are going to invest the effort in developing an API strategy then invest in managing that investment by ensuring performance is acceptable.

How will you determine what functions to provide under the API? Google Calendar offers read, write, update, and delete functions for public and private calendars, while Google Notebook’s API is limited to read operations on public notebooks. What is the process by which Google determines what to provide in their API? The reality for most companies is that it’s up to the individuals behind the products and is often driven by their internal requirements as opposed to what developers are asking them for. How about thinking through and implementing a community process for evaluating API requests and communicating what will be coming?

At some point you will also need to consider how you will handle the delicate scenario that arises when you wish to build out functionality yourself that steps on an external effort undertaken on top of your APIs. Publish your product roadmap so that external developers have confidence that when they invest the time and effort into building out on your app they will enjoy some breathing space for the forseeable future. If you acquire a partner then acknowledge the obvious, you are now competing with your other partners in that space, as is the case with Salesforce’s acquisition of Koral recently.

I hope this was helpful, and keep in mind that while I have used just a few companies as examples the fact is that there are thousands of APIs and hundreds of companies taking advantage of these strategies. There are many source for reliable information on API offerings, the one I would point to is ProgrammableWeb.

Tags: ,