In anticipation of the Apple Watch launch, many are considering whether to make a bet on the new platform. Will it be another Apple home run product with significant new platform opportunity, or not? This is part one of a two part series with my take on that question.

Over the years I’ve been using a framework to evaluate new platforms based on my observations from working at Facebook and Microsoft, two companies responsible for creating, managing, and at times, mismanaging great platforms. The framework involves three factors and associated questions:

1. Technology enablement – Can something be done that wasn’t possible or easy to do before?
2. Distribution – How does the platform help you gain new users and engage existing users?
3. Business model – Does the platform provider have a clear business model that you can align with to sustainably share in the value created?

 Technology Enablement

Technology enablement has been the historic core focus of companies building software platforms. Microsoft’s DOS and Windows are two examples of platform design driven by technologists on both the build and the buy sides. Historically, APIs, tools, documentation and compatibility were the focus of the platform owner because that is what technologists cared about. As computing became more mainstream, technology enablement shifted to table stakes for creating a valuable platform. This was further accelerated when open source platforms such as Linux, MySQL, and others extracted no value for using their technology. Adding GPS to smartphones, to give you my favorite example of technology enablement, has spawned multiple new killer applications, like Waze and Uber, that weren’t previously possible.

Distribution

For technologists this was often the least obvious factor to evaluate, but as any entrepreneur will tell you, “they will NOT come if you build it”. Over time as distribution (nee Marketing) has primarily moved to digital channels, ownership of customers has shifted to the platform owners instead of traditional intermediaries like retailers, wholesalers, etc. Prior to this disintermediation, platform owners offered co-marketing, referrals, default placement and financial incentives as the key forms of distribution given the complex value chain. After this disintermediation, Facebook and Apple took these concepts to new levels of scale with Newsfeed, Notifications, and the App Store, as central features within their platforms. Generalizing beyond these examples infers that platforms with direct customer relationships can offer structural distribution, such as access to friend lists and address books, or they can offer surrounding distribution such as merchandising in an app store.

Business Model

One of the biggest risks for app developers is that the underlying platform will subsume their app’s functionality into the core platform. Newer platforms, such as LinkedIn and Twitter, introduced another version of this risk with their shifting policies around acceptable platform use cases which can largely be attributed to misalignment of business models (e.g., viral messaging spam causing user churn or building a competitive product that uses the platform’s proprietary data). Apple has shown the wisdom of designing a business model into the architecture of a new platform. By mandating use of the in-app payment solution with a fixed revenue share and clearly defining use cases that were off limits they created a sustainable app economy worth tens of billions of dollars. If a platform owner isn’t thoughtful about aligning its business model with developers, it’s possible for tremendous value to be quickly created and destroyed as developers abandon platforms quickly.

I’m extremely eager to learn more about how Apple has designed the Watch platform for application developers. However, until the March 9th event occurs, betting on the Apple Watch is a speculative investment for most. Given Apple’s overall iOS ecosystem across iPhones, iPads and soon the Watch, it makes sense for current iOS application developers to take the risk of investing in the Apple Watch platform because of the overall iOS distribution incentives Apple controls. Once I have a chance to understand what is announced I’ll likely follow up with an assessment using the framework I outlined above.

I’d like to thank Paul Davison, Roy Bahat & John Battelle for reading an early draft of this post.

Getting to use Facebook for work, while I was part of the company for five years, was hard to top but I found a way – playing mobile games is now part of my DFJ job description.

I’m thrilled to share my third investment for DFJ and my first out of our eleventh fund, into Kiwi’s Series B led by Northgate Capital.  Kiwi is an AAA mobile gaming company co-founded by Omar Siddiqui and Shvetank Jain and initially funded by Omar Hamoui and Sequoia Capital. This team is one of the rare Android-first developers that have gotten five of their titles into the top twenty-five grossing of the Google Play Store. You can read more about Kiwi’s Series B funding here, here and here.

Now, as has become a bit of a personal tradition, I’d like to share the story behind my investment into Kiwi.

Since joining DFJ just over a year ago I’ve been talking about the large opportunities available on Android.  As a result I’ve been lucky enough to see some of the most exciting Android-first focused startups that are pushing the mobile experience further than most folks in the Silicon Valley think is possible. Nevertheless, I had trouble finding right team, concept and investment opportunity to get behind and wasn’t sure if I’d find the right Android-first company.

It turns out, sometimes as an investor, you have to be found instead of doing the finding.  Lucky for me Omar Siddiqui found some of my blog posts about Android so he asked for an introduction via our mutual friend Matt Wyndowe.  Even though Matt spells his last name so wildly, he is anything but wild when it comes to making introductions. He is one of the most thoughtful super nodes I know!

In our first conversation, Omar captured my imagination with his vision for building an amazing Android-first company focused on AAA games and distribution. As I spent more time with him and the team I started to learn new things about mobile gaming and Android that floored me.  Especially around how Android distribution and monetization were working in the wild.  The scale of Kiwi along with the number of Android product experiments they’d made was astounding.  Just as importantly, Omar and I had a very natural communication rhythm that led to several deeply engaging conversations around the future of Android and mobile in general that profoundly affected my thinking. Needless to say, I quickly knew I wanted to invest.

The only rub with investing was that Kiwi already had an incredibly strong investment syndicate with Northgate committed to leading the Series B with participation of Sequoia and Omar Hamoui (the founder of Admob) who led the Series A and Seed rounds, respectively.  Not such a little rub, in truth. Luckily, Omar and his existing investors were equally excited about having DFJ participate so we came up with a way to make it work for all parties. This was also a particularly good learning experience for me since Kiwi was my first series B investment in addition to being a multiparty negotiation.

Right now, the Kiwi team is hard at work on its next generation of AAA games. And in seeing the internal demos I am confident that mobile gamers are going to be floored with what they deliver.  If you love producing world class AAA games please reach out to me as the Kiwi team is planning to hire another executive producer now that the series B money is “in the bank”.

Benedict Evans has a thoughtful post up on the Amazon Fire phone. I agree it is going to be a fascinating first experiment to see how an Android fork without Google Mobile Services (GMS) fares outside of China and a while back wrote about other ways to compete with GMS. Ben also raises a great question around how any company’s motivation to build an Android fork that does not run GMS can be at odds with consumers needs and desires for a phone. It is worth quoting his point directly before going further:

“All of this takes us to the elemental question – why, exactly, are you forking Android? What important problem do you solve that’s worth reinventing the wheel, while taking on the risk of building on someone else’s platform, open-source or not? Why are you asking people to buy a phone with second-rate maps and a second-rate app store? Are you offering them something you couldn’t otherwise do in return, or just addressing your own strategic concerns? Are you solving a user problem or your own problem?”

This certainly got my attention given my experience leading Android products at Facebook. Let’s list out most likely motivations driving Amazon, and any other company, when they decide to fork Android:

• Lock-in current ecosystem customers;
• Capture a valuable data asset for Maps, App Stores & more;
• Long term market pressures on Google and Apple to innovate.

What follows below is how these three motivations address both Amazon’s and consumers’ problems. The rub, however, is the number of consumers who face problems starts off small but grows dramatically over time. In writing this, I’ll make a very conservative assumption that Fire Phone will attach to 5% Amazon Prime users, who are the most loyal to the company, in the first 3 years in the market.  Amazon has never released the total Prime subscriber count but recent articles suggest it is at least 20 million (holy crap, Amazon has a $2 billion dollar subscription service).  Lets look at why Amazon would invest so many of its resources to build a phone for just 1 million customers and how many customers it could ultimately impact.

In the near term, current Amazon customers are delighted by amazing end-to-end scenarios across Amazon’s web, tablet, TV, Kindle and now, finally, smartphones. Their digital content works seamlessly across all of their experiences.  This is the Apple “vertical playbook” that has created hundreds of billions of value. However, Amazon is attaching a very different business model to this vertical play by approaching the hardware as near zero margin business*.

This means, in the near term, Amazon will view success of Fire Phone not in total units sold, but rather in increase in LTV of current ecosystem customers. This seems like solid business motivation given reports that Amazon Prime members spend almost twice as much as non-prime members.  Doubly so when seeing comps like eBay share they GMV sales of $35 billion on Mobile devices in 2013.

In the mid term, all smartphone customers** benefit by increased competition across Maps and App Stores. I have no doubt that Apple will make Google Maps & Play Store up their game over time because of the data they collect & use to improve their versions of those services via iOS devices in the wild. My statement might be controversial and hard to believe but I’d cite Google’s aggressive protection of its location data collection on Android as support for the argument (to be continued in the comments :).  And now Amazon will be able to do that too without being constrained by the limits placed on third party applications***.

However, what is really fascinating to watch is how Amazon’s business model will allow them to target specific geographies where they can profit via a long-term e-commerce relationship instead of upfront hardware purchase or long-term advertising revenue – this is a major differentiated advantage. Amazon can outspend competitors in specific geographies where their model works to build the best in class Maps & App Store solutions. While hard to quantify numbers it is clear that customers on other smartphone platforms will benefit from this competition and choice.

Finally in the long-term, the dominant platform owner’s interests diverge from customers and application developers. Unfortunately, there is oftentimes little that customers can do directly when things get to this state, so government regulation or market-driven disruption have to solve the problem. Large developers, like Amazon, fund both approaches via lobbying and projects like Fire Phone.

However, at some point, the interests of head and long tail of app developers result in open standards and source to commoditize the dominant platforms (web browsers vs. windows, linux vs. *nix). Then, the disruptive platforms, and frankly the platforms that lost, implement the new open standards first to put pressure on the winning platforms to also adopt them. If you think this is too much of a stretch, I’d suggest looking at many of iOS8’s features and imagine if they’d been built if Android didn’t exist. Cue, “the circle of life”.

Taking it all together, I’d argue Amazon has customer problems firmly in mind with the launch of Fire Phone. It is just over a much longer timeframe than most companies can conceive. Not surprising, given everything I read about the long term thinking of Jeff Bezos.  This Bezo’s quote is striking given all of the above:

“If everything you do needs to work on a three-year time horizon, then you’re competing against a lot of people, But if you’re willing to invest on a seven-year time horizon, you’re now competing against a fraction of those people, because very few companies are willing to do that.”

—

* I suspect the Fire Phone is not deviating from the low-margin hardware business model, but given the US phone distribution dynamics, they chose to offer more features at the same price as their competition (e.g. 32GB of memory for $199 price point instead of 16GB).

** I’m being too subtle here probably, but when I say smartphone customers I actually include not just end users but also mobile operators as they are key customers as well. All smartphones are sold to both at the start of a new mobile platform given the complexity of the mobile value chain. Longer post on this someday.

*** I’m not sure how to value having 1M devices giving me all of their sensor and application usage data 24 hours a day, but given Waze was worth a billion dollars for a small fraction of the data in question, I believe it to be worth quite a bit.

We all know mobile advertising is big today and will only get bigger (read Mary Meeker’s internet trends if you need to be convinced). As consumer time continues to shift to mobile devices, more dollars will shift to mobile advertising. While mobile ad spend lags behind today, it will eventually catch up and surpass desktop and television if you believe, like I do, that Facebook’s 59% of Q1’14 earnings from mobile are the bellwether. Best of all, this rising tide will only get higher as mobile ads evolve in their format and targeting abilities.

Because of all of the above I view the mobile advertising landscape as having three distinct phases:

Phase I (before my time to 2012)

• Traditional IAB units shrunk to fit inside a small screen, resulting in a bad user experience
• Targeting mobile ads was difficult because every app was its own silo with no cookies, re-targeting
• Incentivized advertising dominated because of volume of installs they could drive and the nascent understanding in app purchasing

Phase II (2012 to 2015)

• Native ads took off with a better user experience, but largely the same content and goals as previous ad formats
• Targeting improved to match levels of web-based ad targeting (including cookie equivalents, re-targeting, and real-time bidding).
• Facebook — and soon, others — created world class self service ad tools to attract large amounts of direct marketing / user acquisition marketing spend.

Phase III (2016 to beyond)

• A class of mobile-only advertising units such as sponsored push notifications, try before you buy app previews, and other to-be-determined formats emerge and take off.
• Mobile-only targeting data where the data mined originates from our device sources, such as current location, current apps installed, calendar, and address book data deliver massive value to marketers.
• All the big players (Facebook, Alibaba, Yandex, etc) make piles of money through direct monetization and via mature ad networks that share 90% of revenue with publishers.

So, where are we today, mid-way through 2014? I believe we are firmly into Phase II and starting to see some evidence that Phase III is ~24 months out. As an investor, I am trying to find key opportunities around products that will support large businesses once Phase III is in full swing. Like the web, large communities of users and communication applications are the early winners, but there will be more variety as mobile devices grow and our time spent on them increase.  Can you think of others? If you have ideas in this area, of course, please drop me a line.

Note: Tomorrow I’m on a panel talking about Mobile Native Ads at Grow.co so decided to prep for the discussion by blogging my current thoughts on Mobile advertising. Feedback before I go on stage tomorrow at 2:15pm PST is much appreciated.  🙂

I know what you’re thinking…”Oh, it’s Bubba again, blogging about Android.” There he goes again….But, it’s true. The Silicon Valley ecosystem, as a whole, is wholly underinvested in Android. In fact there even seems to be a rising sentiment that building on top of Android is a poor strategy.  There are a probably many reasons for this but here are a few reasons that seem particularly large.

First, the number of folks in the Bay Area startup and technology scene with Android devices as primary phones seems to be inversely proportional to the worldwide distribution of Android. How will we all be able to build for a platform we don’t natively use? Yes, many of us will adapt quickly if forced, but technology is a speed game — will other regions already steeped in the ins and outs of Android development and distribution beat us at our own game? It’s possible. Just look at the messaging giants spreading across Asia and the Pacific.

Second, the intellectual horsepower and curiosity in the Bay Area toward mobile is incredibly rich and varied. Yet, the majority of this attention is focused on iOS. I understand why, all the hot consumer apps start on Apple’s platform. But, one side effect of this is that we aren’t able to form equally deep opinions on Android as a platform, or its forks, or apps on top of each. We are more than prepared for the next iterations inside iOS and advancements to the iPhone hardware, yet we don’t seem to have a similar level of curiosity and exploration for the Android platform. Every now and then, a mobile startup will survive long enough to go “cross-platform,” and those teams get to experience the wondrous joy of Android (it ain’t easy, folks!), but those are often isolated experiences.

I believe most mobile observers and investors would have a difficult time trying to name 10 Android-first or Android-only startups in Silicon Valley. How is it possible that so few of these exist, and how is the next mobile unicorn going to be created if we don’t have large numbers of experiments running on Android? It’s cliche to say “we are living in a very special time,” but…we are! Look at all the new platforms emerging around us — virtual reality software (like Oculus VR and Morpheus), the Bitcoin protocol, drones, 3-D printing, and more. Android is one of these platforms, and perhaps one of the biggest in terms of size, reach, and potential market value.

Android is literally a freight train, an unstoppable force and a computing platform that will only increase in power. To that end, I want to see and fund the true Android-first startups out there, the teams who will run with the blank canvas, who won’t be constrained by conventions of a sister platform, who will think originally and critically about the next innovations in mobile computing, technology, and consumer experiences. If this describes you, please get in touch.

From a consumer perspective, a mobile operating system has to offer certain experiences to be considered a viable option. Many of the challengers to iOS & Android have painfully learned this. The most important mobile services are maps and app stores, so consumers can use these devices to navigate, search around them based on location, and to leverage all of the sensors and capacities of the phone. Beyond these, there are also a variety of secondary and tertiary mobile services including communication, games, media, cloud backup, and more. All of these have one thing in common, however: they are massive web services at their core.

Controlling the critical mobile operating system services creates outsized value for companies — independent of who owns the underlying platform. Google arguably has the biggest advantage through its Google Mobile Services (GMS) suite which are anchored by Maps & the Play Store. On Android it uses this advantage to require inclusion of secondary and tertiary Google services as well as to dictate product design requirements in its interest in exchange for giving partners a license to the core GMS suite. This is a tremendous leverage except for places like China, where there has been a proliferation of alternatives for key mobile operating system services.

While there have been a handful of investments in new mobile operating systems (startups such as CyanogenMod and Xiaomi which are based on Android while Windows Phone, Firefox OS and Tizen have all been built from scratch by large companies), there hasn’t been as much focus on competing with GMS. It is hard to imagine a startup viably competing with Google’s offering in maps or app store. Larger companies such as Amazon, Yandex & Microsoft (with Nokia), are starting to do this, but it’s very expensive to directly compete in these core mobile operating system services.

For a while I’ve been curious if there were other ways to compete with GMS but never found anything convincing. That is, until Facebook bought Whatsapp. I’ll get the disclaimer out of the way: I own Facebook stock, I’m a former Facebook employee, and I’m a current happy user of Facebook.

Back to Whatsapp and Facebook…it turns out that a great way to compete with GMS is not to compete head on with Google, but to control other critical points of the mobile operating system experience. With the shift to over the top communication apps a new critical mobile operating system service is emerging. Specifically, Facebook is now in a position to offer a preload of “Facebook Mobile Services” (FMS) that includes Whatsapp, Instagram, Paper, Messenger, and other Facebook apps and services. Combined, these apps represent an emerging mobile communication suite that is so core to the mobile experience, it puts Facebook on par with Google in terms of leverage on the Android ecosystem.

Further, it appears that Google is not in a position to limit Facebook’s influence on the Android ecosystem via its key control point of GMS. Facebook might be the only non-Chinese company in this position right now. Over time Facebook could require  inclusion of their own social app store, zero rating for their applications or perhaps even require a revenue share per subscriber in exchange for a license to “FMS”. So while Google bear hugs Android via GMS, Facebook can bear hug Android+GMS through its own mobile services suite.

This is a big deal.

A few weeks ago, at InContext (organized by DFJ portfolio company Everything.me) in San Francisco, I participated on a VC funding panel discussing trends in mobile apps, contextual experiences, and the market for investing in mobile apps. Toward the end of the panel I blurted out the phrase “The SDK Crunch”, which made it to Twitter and started to spread. Yay, another mobile catch phrase!  Just kidding.  However, I’ve been thinking about this a lot since then because of the number of mobile startups I’m seeing that require an SDK and partly because of my time at Facebook, a company which has one of the most widely used mobile SDKs. 

Let’s briefly unpack the term SDK: By definition, an SDK is how applications can integrate functionality from another app or service.  There can be several ways apps can integrate with third parties but the most prevalent, on mobile, involves including code libraries from third parties into your app. The other common way is through APIs that don’t require third party code to be included in your app, but does require the you to understand the third party’s offerings intimately & keep in sync with their development roadmap.

Mobile platforms — iOS specifically — introduced new challenges with respect to application integrations because there’s no way for an app to provide an API to another app on Apple’s platform. This is the case because Apple optimized for protecting user’s security, battery life, and a host of other reasons, but from an interoperability standpoint, the architecture is constraining. Additionally, because of the velocity of app development and iteration, more and more supporting infrastructure, such as a/b testing & push notifications, is powered by third parties. This has resulted in two things: (1) application integration through web services, which require the device to use more data while also being beholden to a 3rd party’s uptime; and (2) the explosion of SDKs that rely on inclusion of a code library being used on mobile platforms.

Houston, we have a problem.

The best analogy I can think of here is a mixed drink. It’s pretty hard to make a bad drink if you only mix one or two ingredients: Gin and Tonic, Rum and Coke, Vodka Martinis, and so forth. As one adds more ingredients to a drink, the more likely it is to end badly for the drink itself (in the case of a Bourbon Treat) or for the drinker in the case of a Long Island Iced Tea.

Wagering a guess, I’d say the average mobile app on iOS contains at least seven (7) third party code libraries: analytics (often multiple), ad serving (networks, meditation, offerwalls, video, etc.) A/B testing, leaderboards, performance measurement, push notifications, Facebook, Twitter, PhoneGap/Titanium/Sencha etc. The problem is — how do all of these  potentially interact with each other and with the app’s primary functionality? Third party libraries can slow apps down, cause crashes, or worst, maliciously steal user data.

There isn’t a clear solution for this problem in mobile though. However it is is clear to me that is becoming a point of friction for new mobile services that require their customers to add yet another SDK’s client library. This means that SDKs currently deployed have additional value if they’re widely adopted. On the web this also happened but I think the effect will be amplified on mobile because apps are installed on individual phones not on a company’s servers so installations are “stickier”.  Also, for a variety of technical reasons, including a third party’s SDK on the web was never totally necessary (If there is interest in diving into this I can via the comments.)

Going to market with a new SDK is competitive, and in a competitive situation, differentiation is critical. Here, an SDK provider may elect to position themselves to replace one more or more existing solution (including wrapping other SDK’s functionalities into one) versus trying to earn a new slot in the app’s code base. Another tactic would be to open-source the SDK to all customers so they could examine the code during crash debugging. There could even be a standalone startup that just does an integration of SDKs into a single open-source solution.

Stepping back and looking at the macro situation, this all likely evolves into one of these end states:

1. Mobile platforms create a better answer for integration between apps. Apple has started to do this with its integration of Facebook and Twitter into the iOS platform APIs while Android has a wild west approach that actually allows too much freedom from a security perspective.

2. SDK consolidation happens through widely-adopted incumbents like Flurry acquiring SDK players and expanding their SDK functionality in a “one SDK to rule them all” type strategy. This process becomes a pendulum that is constantly swinging between exploration and consolidation.

3. A new application-integration model emerges for mobile. This is the hardest to envision but one crazy idea would be to convert integrations to pure web service calls that don’t leave the device (this is actually an old idea). This limits integrations in several ways but I suspect they can all be worked out.

As a next step, I’d love to get a data driven discussion going. Please leave a comment with the number of SDKs in your app, if this has caused any major issues (technical, product or business) for your company and how your company is thinking of addressing this.

I’ve settled on a new, bold, contrarian investment thesis for 2014: Invest in founders named Paul!

Jokes aside, today, I am proud to announce that I’ve led an investment, on behalf of DFJ, into CircleCI. The “CI” in the company name refers to “continuous integration,” which is a modern software development technique that results in better software products that are delivered to customers faster. Everyone in the chain wins with a tool like CircleCI. If you’re a software developer and/or curious about the space, learn more about the company and its market-leading products here.

I’m lucky to be involved with CircleCI. Here’s how the story unfolded…

When I first met the CEO, Paul Biggar, I did not expect to invest. I’m Bubba, the “mobile guy,” right? Luckily, Jesse Robbins, a close friend and (conveniently) an EIR at DFJ at the time, had the instinct that CircleCI was a special company that I might get excited about. For those of you who don’t know Jesse yet or haven’t heard of him, you should — I believe he’s one of the brightest devops thinkers in the world based on his experience founding Chef, starting Velocity conference, and mastering disaster at Amazon.

What Jesse gleaned from my background is that my experience at Facebook could translate over to deep appreciation for CircleCI’s product. He was right. While I was at Facebook, I witnessed the power of a totally different way to develop software versus how I’d been taught to write code and worked in industry for 10 years. I got to learn how it worked from the legendary Chuck Rossi (chuckr to his friends) first hand in bootcamp. I thought Facebook had invented these new development techniques as part of the value of “move fast and break things.” In fact, some ex-Facebook engineers even mentioned to me that they wish they had “Chuckr as a service” for their new startups.

It turns out that many of the the techniques Facebook used emerged from a variety of sources and were really put front and center by Eric Reis while he evangelized “the lean startup.”  All of sudden, build-and-release engineering was being valued as a strategic advantage by companies. A variety of open-source tools and cloud services emerged to enable startups of all sizes to use continuous integration and deployment development processes. However, curiously, no cloud-based company emerged to become a dominate player like GitHub did for source control or New Relic did for performance monitoring.

As I thought about the challenges facing mobile developers today, it became clear that velocity and quality of development in a complex heterogeneous environment of server and client components was going to become an ever increasing problem. As my conviction grew regarding the size of this opportunity, I also concluded that CircleCI had the best product & team in the market.  CircleCI also built a fast-growing business having grown revenue over 25x since they raised their seed round with over 1000 paying customers.

Great team. Outstanding product. Huge market. Great trends. Killer traction. No brainer, I’m in, and delighted to get the chance to be along for the ride. I’m excited to join the Paul and Allen on the board of CircleCI, and to help them build a large developer-focused company with the help of Steve Anderson & Michael Dearing – co-investors I deeply admire.

 And yes, CircleCI is using the funding to hire so if you are looking for you next challenge check out their open jobs!