What Really Matters to a Startup?

At Mobile 2.0 a lot of folks asked me why I hadn’t posted anything about the major shifts in the mobile landscape that have happened over the last few weeks. The big news items being Google buying Motorola, Steve Jobs stepping down as CEO of Apple, and HP deciding to call it quits with webOS. It’s not cause I don’t have opinions about where those changes might be taking the industry. But for the most part I don’t think those major shifts are the kinds of discussions that really impact startups.

Sure, there was plenty of talk about the big issues at the conference. But if I look back at the conversations I had with other startup folks the topics were way more practical. The questions are always the same, tectonic shifts or not: “How do we get more users?”, “Is there a better way to make more money off what we’re doing?”, “Who would make a good partner for what we’re doing?” And in most cases those big shifts in the industry don’t impact how you answer those questions. Frequently folks talk about how startups can be more nimble than larger organizations, and this is one of the places where we should best be able to take advantage of it.

Lets take the Google/Motorola deal as an example to work from. Lots of folks are speculating that with Google now potentially directly competing with hardware manufacturers that we’re going to start to see more non-Android handsets coming to market. For the sake of conversation assume that to be true. As a startup company when should I care about that shift? I would say you should start caring about it at the point where this “third platform” gets to a large enough deployment it’s worth developing for. I’m sure someone out there would debate that. But I’m fairly definite right now is not the time for your average 5 to 10 person startup to try to get ahead of a trend.

It does make sense for large companies to care about these things. If instead of a 5 person startup you had a staff of a few hundred Android developers and a product pipeline that was 12 months long you had to care about, then it does have a strategic impact on how you should do your planning. And if that was the case you would have to figure out a strategy that covered the likely outcomes of allowing Microsoft/Nokia to get back into the game, someone snapping up webOS and making a real run out of it, Amazon pulling a Google on Android and using their technology without using their platform, or just driving interest back into iOS when devs get tired of porting.

As a startup you don’t have to go chasing shadows though. Because you can shift your strategy much faster, you can wait until you know you’re not walking into a minefield before picking a direction. That’s where I see the real value in how nimble a startup can be, and where most of my discussions tend to concentrate. Not in gambling on trends and trying to jump ahead of them, but in being able to wait till a direction is clear and then executing quickly to take advantage of it. That’s just good startuping.

Posted in Business, Churn Labs, Community, ThisIsMobility | 1 Comment

Entrepreneurial Engineer

We did a panel titled The Age of the Entrepreneurial Engineer at Appnation yesterday. We never have enough time to cover all of the topics worth covering on any panel, that’s just how things go. And I think I’ve probably been spending a disproportionately large amount of time thinking about the set of factors here. What I’m working on at Churn Labs is meant to be directly in support of entrepreneurial engineers. So I wanted to summarize some of the bits we didn’t quite get to while we were up on stage.

There’s a whole lot of current thinking and discussion that points in the direction of engineering driven businesses being at least an acceptable idea. Be it the details of the distinction between causal and effectual reasoning laid out in What Makes Entrepreneurs Entrepreneurial?, or the Lean Startup principles that Eric Ries has been putting together, or the insights from Little Bets pulling together both current practice and examples of some great successes from the past. There are lots of folks driving the idea that the greatest risk to any startup isn’t the way you’re doing things, but that you’re doing the wrong things. So by extension, the best thing you can do to increase the chance of your business succeeding in the early stages is to structure for learning instead of optimizing for what you’re currently doing. Shouldn’t be a huge revelation to engineers, we all know that premature optimization is the root of all evil, right? :-)

You don’t need to be an engineer to be able to practice the principles these folks are talking about, but in lots of cases there are advantages to being the person doing the implementation as well as the person learning from the experiments. It also helps out when initial efforts uncover unexpected discoveries. Being the person in the code, poking around in the logs, putting together the metrics – I feel like those discoveries come about more naturally.

These practices aren’t really new. They’re just starting to get documented, given terms, and ultimately legitimized. Now we think of someone “pivoting” as a good thing. They learned that some assumption was wrong and have found a new direction that builds on their previous learning. Before there wasn’t a word for it, and we had to describe a change of direction in a way that everyone viewed as negative. So people would actually prevent doing what was good for their business because they were afraid to have to admit to peers and investors that they had made a mistake. Witness the Sapir–Whorf hypothesis at work, now that we have better words we have a better world. How awesome is that?

It also means that we’re seeing some new forms come around. The Gentleman Hacker lays out the model at the larger end of the spectrum. “Getting together smart folks to just hack on stuff” is nothing new. The subtle but extremely important difference is that we’re not just hacking to solve technical problems. We’re hacking to try to explore and validate hypothesis. We are hacking with a direction. We just expect that if we’re hacking correctly that direction is going to change.

But the process scales down as well. Entrepreneurs I talk too are increasingly spending time actually getting working versions out into market, iterating a few times and learning, and then looking for funding for what they’re doing. I think this model of figuring out a new business is infinitely more effective than drawing up a business plan and doing some market research. I think the popularity of the process is the main driver for the rising average valuation of companies getting funding, and an indication that the market agrees that this new model is the way to go. And of course if you’re an engineer who can get something out to market as well as one of the founders you’ve solved that major issue of how to get from idea to first prototype.

All this stuff is fantastic news for us. It doesn’t mean that you can completely ignore everything like learning about market sizing, or term sheets, or how to put together a corporation. But it shifts the emphasis back to a set of things that we’re more well prepared to deal with coming out of the gate.

Posted in Business, Community, ThisIsMobility | 3 Comments

Browser Beats App Store

Some great conversations going on at the APPNATION conference today. I just wanted to share one bit in particular. Trip Hawkins had a slide titled Browser Beats App Store that pulled together a number of points I’ve realized from various projects into a great list. If you view the image full size you can make it out. But here’s the list:

  • Convenience
  • Social
  • Already #1 overall (PC)
  • Tablets
  • Mobile, TV next
  • Wifi proliferation
  • FB, Google, Amazon, Netflix, et al.
  • Open, free, democratic
  • Targeted traffic
  • Cross-promotion is easy
  • Direct cloud updates

The app stores have gained us a lot with respect to previous models in mobile. But they’re also a step backwards in many regards related to what we’ve become accustomed to when delivering to a browser.

Lots of people say things like “Why would you want to deliver something like Angry Birds through a browser anyway? That would always be a native app.” But I’m not convinced there. What if they didn’t have to stage updates in big releases and just put out a level at a time? What if you could challenge a friend to get 3 stars in a level, and they could play that level right in the browser without installing an app? Stuff on the web is a lot more malleable. Even if the technology side didn’t make sense, many of the secondary benefits stack up into a pretty strong driver.

Posted in Browser, Business, ThisIsMobility | 1 Comment

Why I’m Crossing NFC Off My List

I’ve got a list of stuff I would like to read up on and play with, and NFC has been on that list for a while. I’ve been really excited about the secondary stuff that should go along with NFC. For a long time folks inside the industry have been vocal about NFC not being “just about replacing your credit cards with your phone”. Theoretically NFC should also open up all kinds of interaction with the real world. We had a Mobile Monday Silicon Valley panel on NFC last night to talk about some of the overall issues. I have to admit however that I feel like the whole thing is headed straight for a brick wall at high speed. Even though I would love for it to work, it’s not going to work.

NFC as it stands is setup to suffer from exactly the same set of issues that has effectively killed Bluetooth as everything except a wire replacement protocol. The problem is that when NFC pushers say that NFC is “about more than just replacing your credit card with your phone” what they really mean is that NFC could be about more than just replacing a credit card. The decision about how capable or restricted an NFC stack is lies with the equipment manufacturer. And generally speaking folks don’t just toss random features into phones because they’re available. They do so when it’s really necessary, normally because of consumer demand.

Right now the NFC field is going through something very similar to what the GPS world went through. I’m sure some of you will remember that back in the deep dark recesses of pre-history not every smartphone had a GPS chipset in it. Those of us geeky enough to care went out of our way to find the models that did have GPS support so that we could play around with our own little hacks. But back in those days the consumer public didn’t really care about GPS support in phones. Back in those days the only folks who were clamoring for GPS support in every handset were the folks who were selling navigation or mapping apps for phones, and they were charging way too much, and not sharing revenues back with the manufacturers. So the environment was pretty well jammed up.

Eventually Google Maps came around though. And a meaningful free mapping application with fantastic search changed the potential value of having a GPS chipset in a handset, made the handset more attractive to customers across the board, resulted in more sales for handsets with GPS even if the manufacturer couldn’t sell additional GPS related apps, and we ended up where we are today. Generally that pattern is true, to get a new technology out into peoples hands there has to be a killer application to drive it. And the version of the technology that gets deployed will be the minimum version required in order to make that kill application work, and that ends up being the new standard.

Contrast the GPS uptake with the way Bluetooth has worked out. The Bluetooth technology folks early on used examples ranging from the headset connection version everyone knows through syncing all your data between devices automatically. There’s a whole ton of potential functionality in the Bluetooth specs, and at this point it probably is possible to sync data wirelessly and automatically in some subset of devices. However, the killer app there was connecting a wireless headset, so that’s all that anyone really uses Bluetooth for these days. And on lots of devices that’s all you can do. I’m sure that statement is going to piss of a whole industry. But tough, it’s true, deal with it.

With NFC the killer application appears to be payments. So my pressing fear is that the version of NFC that gets deployed to the devices out there is going to support the subset of features required to be able to participate in payments, and that’s it. Now, I know, the subset of stuff required to support payments potentially covers a few other areas like being able to scan other styles of tags. While I understand some of the convenience points there from a consumer perspective, there are some massive downsides from the point of view of an independent app developer. MASSIVE! Having a fully functional system requires a new bit of hardware even if I have an NFC enabled phone. That’s a huge barrier to experimentation and uptake for anyone except the folks with deep pockets and long timelines.

I was hoping that after the discussion last night I would find out a few things I was unaware of. I would be able to grab my Nexus S and with some quick bits of hackery potentially do something interesting. While I admit that NFC could potentially deliver some wins for a subset of cases out there, it’s not something that an independent app developer needs to take into consideration when building applications. I’m hoping that things shift somewhat as this evolves, but as it stands I’m taking NFC off my list of stuff to find some time to play around with. I just don’t see any areas in which it’s close enough to being a practical component of mobile development for someone trying to build a new business in mobile. Those of us looking for additional ways to make applications more context aware are going to have to stick with other techniques for now.

Posted in Android, Technology, ThisIsMobility | 8 Comments

Churn Labs

The news about Churn Labs went out yesterday, so I can start talking publicly about what we’ve been cooking up. I figured I would start with a bit about what we’re trying to do. Frequently when I tell folks about the lab they say “Oh, you guys are an incubator.” That’s not quite true. I haven’t been trying to correct people about it however, cause with all the incubators out there it was an easy way for us to stay hidden in the noise. Time to stop that though.

The overall explanation is on the Churn Labs about page. The typical incubator takes folks who are already working on something, and provides them with resources in exchange for equity. Churn Labs is structured as an actual lab however, where we hire folks to work on ideas we already have bouncing around internally – with the hope that some of those ideas have legs and can be spun off into independent companies. That means our projects take a completely different form, and the folks who we’re able to pull into the lab can come from vastly different areas.

There are lots of folks out there who aren’t able to hop in full time to work on their ideas. They have kids, or a mortgage, or need their health benefits to be constant. Some of those folks are always hacking away nights and weekends on interesting projects, but they just can’t unblock enough time to make a real run at some of their ideas. When Omar and I started talking about the lab we figured that would be the real sweet spot for a new project.

I’ve been calling them “entrepreneurial engineers”, but I hardly coined the phrase. I first started hearing it from Adam and Joyce around the 106 Miles Meetups. It’s hard for an engineer to make the leap to entrepreneur. I know I certainly found it really frustrating and difficult, but also very much worth the effort. There are lots of programs aimed at folks who are willing to toss it all and start off on something new and untested. But there are few systems aimed at those passionate folks who aren’t able to just chuck it all and strike our fresh. As engineers we’re accustomed to trying to be methodical and principled about what we do, and that just doesn’t jive with quitting your job and striking out into the completely unknown.

The most common argument that people throw back at me is “You can’t make people entrepreneurs! If they didn’t have the passion to just strike out on their own they won’t have the will necessary to make it on their own.” I completely disagree. Fortunately I’m no stranger to hearing constant criticism of an idea. I heard just about hourly about how AdMob was doomed to failure for the first 6 months I was there. So, criticism noted, but I don’t agree.

I disagree because I know lots of these people are extremely passionate and driven. I know because they IM me at 3 in the morning with questions about how to setup software based load balancers or how to install a Cyanogen rom on an Android phone. They don’t lack the drive to work on their own things, they just lack the tools necessary to figure out how to make their passion their livelihood. There’s certainly risk still even if they do have the tools, but there’s risk in any model. And I think this one is worth exploring. At worst, I got to hack on a bunch of interesting stuff with a group of awesome people. Total win/win situation.

Posted in Business, Churn Labs, Community | 1 Comment

Nokia and Microsoft

This is going to be that grandstanding “I told you so” post I promised a few days ago. When did I tell you so? In April of 2009, when I felt like the incumbent players in mobile had turned to FUD and misleading numbers to try to combat the hemorrhaging of marketshare and developer mindshare they were seeing. In particular, before we move on, I would like to share a few words with the folks who said I was too “US biased” in my thinking. And all those mobile pundits out there who claimed I didn’t really know how the market worked, and that Apple wasn’t having as big of an impact on the marketplace as they would like us to believe. The words I would like to share: screw you. Screw you. Screw you!!! There, I feel a lot better.

Now, onto the slightly more serious points of conversation. There’s a lot of analysis floating around out there about this deal. Tons and tons of it by folks who are mobile veterans, and include theories about optimizing hardware production processes and giving Microsoft a tightly tethered OEM so that they can control the whole stack the way that Apple does. All that stuff is really missing the forest for the trees.

I think the very top level reasons are pretty obvious if you detach from the details and think about it. What is the number one criticism leveled at Microsoft over and over again about its efforts in mobile? Lack of consumer adoption and scale. And that’s exactly what Nokia has. And what is the number one problem for Nokia despite having scale and consumer adoption? They can’t create and support a third party developer system. And wow, look at that, it’s one of the things everyone accepts that Microsoft does well. Everything else really hangs off those principles. It actually gets skipped over a lot in the trade coverage cause it’s so fundamental people just take it for granted.

However, it’s important to keep in mind if you’re doing something like figure out if this was a good deal or not. This isn’t a two party deal however. In every possible future I’ve seen discussed so far, third party developers need to figure pretty heavily into this. So I’m really curious to see how the combined forces of Nokia and Microsoft attempt to address bootstrapping this new effort.

One thing to remember, for those who weren’t as into it back in the day, is that the iPhone didn’t have native apps to start out with. For the first year it managed to draw in huge numbers of users and attract a ton of mindshare based on the apps it shipped with and a spectacular web browser. Once Apple saw they had a hit platform on their hands it made sense to open it up to third party developers. Because there was pent up demand in the market from a large existing install base of users, those early developers had great stories to tell about the platform and resulted in additional developers. The additional apps from the additional developers led to more draw from users. Feedback loop completed. Nice job Apple, well played.

The funny thing about that playbook is that it only works once. Apple was able to do what it did cause all the mobile platforms that came before it sucked at supporting third party developers. Thus Apple was able to launch a mobile device all by themselves and get some real traction. An attempt to execute the same strategy in today’s environment would never work. Now the immediate response is “What? No huge catalog of apps? Your platform sucks.” There was a window of time when that wasn’t a complete given, and the Google folks managed to release Android to market under the bar. But now that window is firmly shut. Microsoft attempted to address the issue by paying to have the popular titles on other platforms ported over to Windows Phone 7. I think all would agree that the attempt was underwhelming and something not likely to be repeated.

I think the only way to address the widening gap between Apple/Google and the rest of the world is to look to the next model down the line. Competing head to head based on a native development platform with a fat and fluid monetization channel would really be the wrong way to go. What we need here is some innovation and model transformation, and generally speaking that’s not how Microsoft and Nokia operate.

So to all the other developers out there who are going to be hearing a ton of marketing down the line about the Microsoft/Nokia partnership and trying to make some sense of it, remember that this isn’t a two party deal. This is really about Microsoft, Nokia, and us. And in business deals like in poker: if you look around the table and can’t figure out who the sucker is, it’s you.

Posted in Business, Community, ThisIsMobility | 2 Comments

JSON Bookmark Sync for Android

I’ve been playing around with a few different ideas lately, many of which include some statement such as “it would be interesting, but it really needs to interact with the default browser otherwise it would be really clunky.” So last night I hacked up a simple shim to take a feed of bookmarks in a minimal JSON format and merge them into the bookmark content provider on Android. I’ve been calling it, oddly enough, “Android Bookmark Sync”. Even though the title is technically incorrect. It’s a bookmark merge and not a sync. But I’m hoping that will change and I can add in a real sync. Source code available at github, cause that’s how I roll. So nice that Android has a content provider for this kind of stuff.

The README has info about how to output bookmarks in a form that the shim will understand. This is just initial hackery, not a real project yet. I just figured I would share it cause, well, taking some JSON and syncing it to the default browser bookmarks just seemed like the kind of thing other people might want to play with. If you turn on install from unknown sources you can download my prebuilt binary if you’re not into the whole Android development thing. Who knows, once I clean it up some I might even upload it to the market. There’s more hackery to be done first. Firefox Sync, I’m looking at you.

It’s too bad bookmarklets don’t work too well in the default Android browser otherwise there would be some much more obvious fun to be had.

Posted in Android, Browser, Open Source, Software, Technology, ThisIsMobility | 1 Comment

Development of the Mobile Web

What is it going to take for us to see some real significant progress being made in developing mobile apps on the web? Since the Day of JS event a few days ago I’ve been poking at the idea. I ran across a great article that mentions the theory of the adjacent possible that helped solidify things for me. The theory of the adjacent possible come out of biology, but I ran across it in the context of discussions about innovation. That article is definitely worth a read if you’re a startup person.

So what does that theory have to do with the mobile web? I think it helps summarize one of the primary failure modes for doing mobile web work. There’s a natural tendency to look at the desktop web when thinking about how to address mobile. However, many things that we’re doing on the desktop web just aren’t adjacent to the existing practice on the mobile side. We might make it there eventually, but we can’t make it there now. We assume we know where the mobile web is eventually going TO because we know all the awesome things that grew out of the desktop web, but it’s more important to think about what the mobile web is going THROUGH in order to up the chance of being successful.

For instance it’s pretty natural to assume that because more capable devices are ending up in the hands of a wider audience now would be the time to start working on mobile media properties. However I don’t think the advertising environment is really at the right stage of evolution on the mobile web to make that style of property the same slam dunk as it would be on the desktop web. I think what we really need are a few direct monetization services to kick things off. We need the Amazon and eBay of the mobile web. Those two shifted perceptions on the desktop side, one with direct sales and the other as a sales platform. The media models formed around the commerce that started flowing. I’m starting to think that until the mobile web has something to sell it’s premature to start trying to run media models.

Not that media properties won’t work, I just don’t think they’re what we need to significantly shift development toward the web. And of course, I’m planning to test some of this out cause I might be completely insane. Hat tip to Jay Jamison and Eric Ries for the recent discussions at Founders Labs and Bluerun that have kicked off some interesting ideas.

Posted in AdMob, Browser, Business, Community, iPhone, Software, Technology, ThisIsMobility | 2 Comments

Day of JS Event

The Day of JS event yesterday was fantastic! Thanks to Google and the MJG crew for putting it together and hosting. Great set of presentations and discussion, and I was blown away by the set of folks in the audience.

The state of the mobile web presentation that Dion Almaer and Ben Galbraith from Ajaxian did at the start was a fantastic summary for someone like me. I frequently say “I’m not a web developer” so that no one would confuse me with the folks who live and breathe JS and CSS3. However I’m also not a “native guy” either. I try to use the right tool for the job, so I’m not really in any technology camp at all.

I have a long history of working on the mobile web actually. Sitting in the sessions yesterday I was blown away by how different of an environment we have over quite a short time. In particular during the talk from Alex Russell about browser support and during the state of the mobile web talk it reminded me of a set of discussions we had in June of 2007 about applying the AJAX model to mobile. The points that Dion and Ben made summarized the set of issues way better than I ever have. There are three important components to making a development platform work:

  • Platform Distribution
  • Platform Capabilities
  • Merchandising

The first two points echo the discussion we were having in 2007, with the difference being that now mobile browsers don’t crash if you throw standard desktop JS libs at them. Because we have a nice meaty set of high capability devices in a relatively large number of hands, its finally possible to tune the platform capability vs platform distribution tradeoffs in a way that makes business sense. I think we’re just now edging over a tipping point actually, but that discussion is for another time.

I would actually call their third point “monetization” instead of merchandising, but that’s a nit really. The way they were discussing it, advertising and promotional programs are lumped into merchandising. But this is the area that I think is most in need of help currently. Most folks working on the mobile web are rolling their own when it comes to merchandising. And I don’t really know of many services to point to who are monetizing effectively outside of the app store systems. So if anyone else out there knows of good examples please pass them along. Ben and Dion did make the point that for anyone who has tried to sell software on their own either independently or through other channels, the 30% cut that Apple takes for selling your app on the app store doesn’t seem overbearing. Good point.

Another fantastic point for the day came from Yehuda Katz. He came and presented at the last Mobile 2.0 developer day, but was just settling into the new role. This time around he said something along the lines of (and I’m paraphrasing, so forgive me if I misquote) “people used to have 0 or 1 main computing device they used, now we have 2 or 3″, and addressing that shift is that “mobile strategy” should be about. It should be about delivering the right experience at the right time across different devices. Echoes of the service avatars presentation Mike K did at Mobilize. I think Yehuda really hit the nail on the head in calling out that point as the base of the discussion.

I had already been poking around with JQuery Mobile, Sencha Touch, and SproutCore. Now I’m thinking it’s time to pull together some of the hackery into a project and see if I can make one of them work at scale. Seems like all the ducks are finally starting to line up.

Posted in Browser, Community, Software, Technology, ThisIsMobility | 3 Comments

Android Marketplace – Missing Affiliate Program

There’s been a lot of coverage recently for some of the comments about improvements to the Android Marketplace that Eric Chu made at the Inside Social Apps conference. One of the big holes I see right now is the affiliate program. In the list of intended improvements I haven’t seen mention of an affiliate system yet. Apple has been running an affiliate program for iTunes since before there was an app store. The affiliate program pays a small percentage of the purchase cost to a third party who acts as the recommendation/referral agent.

I have no idea what the overall numbers look like in terms of bottom line for Apple, but I do know the effect than an affiliate program has on developers and media properties. Unwrap the download URLs from sites like 148apps and there’s an affiliate program link sitting in the middle. We made use of the affiliate links at Chomp and another startup effort I worked on before that. What an affiliate program says to developers and site owners is “we care about you helping us promote the good stuff in our store.” I think it’s really greased the wheels for Apple and encouraged quality third party services.

If Google would like to increase the download of paid applications (and when the time comes also start to ramp up in-app purchases) without having to spend all the time and effort directly on revamping the marketplace they should take a look at spinning up an affiliate program. The advertising model works, sure. But the incentives are better aligned to drive the overall health of the system when a publisher is paid on app download and not on ad impression or click.

Posted in Android, Business, Community, ThisIsMobility | 5 Comments