Charles Hudson's Weblog

I’ve been wearing and using my Pebble a lot more since they announced support for a broader framework of notifications with the release of iOS 7. I was excited to learn that I’d be able to get notifications from a broader set of applications as I thought it would make the watch more useful and interesting. Thus far, I’ve had a mixed experience with the new notifications. The problem is that I get too many notifications – I get every notification that I normally get on my phone on my watch. There is a way to tinker with this via settings, but it requires me to change the way I handle notifications on my phone as well – I don’t really want to change those. I want to change how my Pebble determines what’s worthy of an interruption and what isn’t.

When I first got my Pebble I thought I wanted a phone on my wrist. I thought I wanted something that would largely replicate my phone experience but in a wrist form factor. The more I use it, the more I realize that I don’t want something that replicates my phone on my wrist. I want a very smart subset of my phones features on my wrist and I want that wrapped in some intelligence about how and when to notify me about something new.

I wonder if Pebble (or someone in the app ecosystem) will end up making a smart notification manager that handles this much better. For people who do not have many notifications enabled on their phones, this is not much of a problem. But I have a lot of apps and a lot of notifications that I actually find useful. I think there is an opportunity to build something that handles this more elegantly than a blast firehose.

I also wonder if the major hardware companies who are investing in smart watches, namely Google, Apple, and Samsung, will use their smartphone footprints to make notification management work natively for their vertical stacks. I would like to hope that the iWatch, GWatch, and Galaxy Gear will have smart notifications managers that can differentiate between what I get on my phone and what goes to the watch.

Ironically, the deluge of notifications that I get now has made me acutely aware of the kind of notifications that I don’t get but would like to get. For example, I’d love it if my Pebble + phone combination were smart enough to know that I am in a meeting and either switch to silent mode or only disturb me with a buzz if the incoming item is pertinent to this meeting or the next or is truly an emergency. Also, I have no need to get notifications that are not actionable on my watch.

As always, comments are open. You can also send me a message on Twitter @chudson to share your thoughts.

I’ve written a few posts about how I think about location sharing and location sharing applications, the latest of which is this one. One of the most interesting experiences I’ve had of late is trying to activate my network to start using Twist. For those who are unfamiliar, Twist is a mobile app that allows you to share both your current location and your ETA with someone else. I find myself continuing to use it more and more each day for three primary use cases:

• Given the current awful state of Bay Area traffic, I generally send a Twist whenever I am heading to or from San Francisco to or from the Peninsula. Originally I used Twist to just to tell people when I was running late, but now I send it out in advance because sometimes it turns out I’ll arrive early and we can actually start a meeting sooner.
• For my intra San Francisco meetings, I use it in much the same way – I like to walk to most of my meetings when possible (and Lyft or Uber when necessary). It’s surprisingly easy to make bad guesses when it comes to the time required to get from one meeting to the next and I feel better when the other person has some visibility that I’m on my way and when I’ll arrive.
• The third use case is social (as opposed to professional). If I’m going to pick up a friend or meet someone, I’ll usually send a Twist so that I know that I’m on my way. It takes a lot of the guesswork out of when I’ll actually get there and is super useful when you’re trying to pick someone up and want them to know that you’re on your way.

I tend to have two experiences when I send someone a Twist, which suggests that they install the app so they can have the same experience.

• Whoa, this is really cool – I got to see when you were on your way. Totally downloading this app.
• What is this and why are you sending me this Twist thing? Just text me when you’re on your way.

I honestly don’t get anything other than these two polar responses. There isn’t any really anything that predicts where someone will land on that spectrum, either. I have some techie friends who love apps and don’t particularly like Twist and I have some late adopter friends who have really taken to using the app aggressively. I also have friends across a pretty wide age spectrum and even age doesn’t seem to predict whether someone will like the experience or not.

The one thing I’ve seen that seems to be predictive of adoption and usage is the “ah ha” moment of getting insight into someone’s ETA when their initial guess or suggestion as to when they’ll arrive. At the end of the day, I do think Twist really competes with the alternatives of sending a text to tell someone you’re on your way or simply doing nothing and hoping you arrive on time. If people have that “ah ha” moment on their first or second experience with the app, I bet it sticks. If they don’t perhaps it doesn’t feel like it’s worth the effort beyond using a text.

If you use any of the location sharing applications and have experiences you’d like to share, feel free to leave a comment below or send me a note on Twitter @chudson.

One area where I’ve been spending some time meeting companies and learning is in the broad area of Android UI customization. I’ve started to see a handful of companies providing interesting approaches to customizing the Android home screen UI as well as taking over the lockscreen to provide consumers with information or entertainment.

It’s not surprising to me that people are spending lots of time trying to own this real estate – it’s the first thing you see when you pick up or unlock your phone. According to one report, people swipe their phones 100 or more times per day. That’s a lot of views and time that nobody currently controls. And the opportunity to be the first thing that people see (or control the experience that they see) that many times for day is a really interesting opportunity for both startups and established companies and one that I expect to get more competitive in the near term. There are already a few startups tackling this space, namely Aviate, Cover, and Locket, along with a few other teams and companies that have not yet launched or publicly announced what they’re doing. And then there are some of the newer Android hardware devices that include things like Active Display Notifications that allow you to peek at incoming items without actually unlocking your phone.

The interesting thing to me is that I’ve seen three relatively distinct approaches around how to better use the homescreen and lockscreen real estate. I think they can all be successful but all have really different approaches and value proposition for consumers:

Ad-Driven Monetization Experiences

Many of these seem to be inspired by the Cash Slide experience in Korea, where consumers earn a small amount of money for swiping on ads or otherwise interacting with promoted content with the lockscreen. The primary hook or driver here is obvious – it’s a way for consumers to earn money (real or some form of reward currency) and there is already a pool of advertisers willing to get their marketing messages in front of consumers on that screen. The ultimate test of these models is whether customers will, in the long term, continue to have an interest in looking at ads or other promoted content and whether the companies providing this promoted content can have a good mixture between things that monetize well and things that engage the consumer.

Putting Social Front and Center

Another approach for building launcher and UI customization is Facebook Home. I think Facebook Home is still a very interesting experiment in how much persistent screen real estate and UI consumers are willing to give up in order to stay connected to the core Facebook experience. I think Facebook is out in front in terms of pushing the boundary of what’s possible here and I imagine they’re learning a lot about what consumers like and dislike about having a more pervasive social experience outside of the core application.

Beyond Facebook, I wouldn’t be surprised if some of the more social applications on mobile (the new crop of messaging services, Twitter, the newest crop of photo services, etc) move toward making their product experiences more pervasive over time. And I would also expect some developers to start building social application experiences like Home that pull from multiple services.

Context and Content Driven Intelligence

The last major approach I see people taking is making the lock screen and overall layout smarter by taking into account context (location, upcoming meetings, interest, etc) and matching that with relevant content. That can include anything from using knowledge of my calendar to push me information that’s relevant for my next meeting even if my phone is locked (something richer than a simple push notification) to more complex scenarios like pushing me breaking news complete with video or imagery (as opposed to just a link in a push notification) when topics or interests I follow have meaningful updates. I think this is a really interesting area to explore, but it is also likely to push these companies toward the current arc of Google Now. For me, the big unanswered question is how hard Google will push Google Now to the forefront of the Android UI experience. Google Now already does a pretty good job on context and content but it’s not (yet) front and center in the Google experience. I read a good Ars Technica article on their take about how Google is beginning to push some of its services more to the forefront.

As always, comments are open or you can send me messages on Twitter @chudson.

I wanted to write a quick blog post based on a tweet I shared recently:

I continue to believe that Kickstarter campaigns tell me more about category demand than demand for a given company's actual offering.

— Charles Hudson (@chudson) November 1, 2013

Overall, I continue to believe that Kickstarter (and IndieGoGo and self-starter) campaigns are generally more indicative of consumer interest in a given product category than they are of consumer interest in a given company’s product. As others have noted, this is largely due to the fact that most pre-order campaigns generate interest based on the product promise as opposed to the actual product. This doesn’t mean that popular crowdfunded / self-started products won’t be successful. Rather, I’m just arguing that you shouldn’t substitute crowd enthusiasm for the work of figuring out whether a given team has the right product and concept for a given market. Evidence of demand in the form of pre-orders doesn’t mean that a given company will be the winner.

As always, comments are open. You can also share your thoughts on Twitter by sending me a message @chudson.

The world of mobile messaging has really taken off in the last few years, with products like WhatsApp, MesssageMe, Kakao, LINE, WeChat, Facebook Messenger, Kik, Viber, and others building large and growing user networks. I think many of these companies are really interesting and many of them are building really interesting businesses in their own right, whether as platforms that enable other applications and games to ride on top or finding other ways to directly monetize the usage of their own applications.

Network Effects vs Cost of Simultaneous Usage

As with many communication tools, many (if not all) of these products have strong network effects. One nice property of network effects businesses is that they have the ability to become really sticky – switching off the social network or mobile messaging product that your friends use becomes more difficult as you have more friends on a given platform. If you want to read more about the nature of network effects, you can read more here.

The latest crop of mobile messaging companies feel like the next evolution in communication. And, as is the case with previous waves, there is some question as to whether this market will tip toward winner-take-all (as was largely the case with social networks) or will support islands of relative strength (as was the case with instant messaging).

While a lot of the conversation about how mobile messaging will play out is focused on the importance of network effects and the potential to create winner-take-all outcomes, there is another dimension to consider. The other dimension to consider is the cost of using several products simultaneously. While network effects make products sticky, having a low cost of simultaneous usage means that it’s not that hard to use several products at the same time. In the case of social networking, the cost of using several services is high – it’s not financially expensive, it’s expensive in terms of time and attention. Most people don’t want to post status updates, upload photos, and be active on many social networks (but they will use more than one). On the other hand, the cost of simultaneously using several instant messaging products is fairly low – you either run multiple clients or use some sort of aggregator.

I tried to create a simple table of the various services and markets and the nature of their network effects and the cost of simultaneous usage:

In the end, I don’t think mobile messaging is one of those markets that will tip toward winner-take-all outcomes. While the network effects are definitely present, the cost of simultaneously using these products is low. The products are, for the most part, free or very inexpensive to use. They are all delivered as applications and widely available on the most common mobile OS platforms, so access is not an issue. They all use push notifications or other channels to bring you back to the app when you have a message, so the cost of keeping up with message activity is also fairly low – so the attention overhead can be very low.

At the end of the day, I think it’s relatively easy for me to just let my network use whichever messaging platform suits their needs. The cost of simply responding to them in whichever messenger or platform they want to use is fairly low and the cost of trying to get them to all switch to a common platform feels high.

Fortunately for these companies, building interesting businesses in this space doesn’t require a monolithic winner-take-all outcome. There is plenty of diversity across geography, demographic slices, and use cases to allow lots of companies in this space to flourish without one company being the dominant product for all people in all use cases.

As always, comments are open below and you can also send me a message on Twitter @chudson.

A decent chunk of my blog posts are inspired by things that other people tweet that catch my eye. Recently @hunterwalk tweeted out about how Evernote or Twitter should buy my favorite read it later service, Pocket:

As Pinterest adds "read it later/bookmark" features I'm waiting for Twitter or Evernote to buy Pocket

— Hunter Walk (@hunterwalk) September 24, 2013

When I saw that tweet, I immediately thought that Twitter is a much more likely acquirer for Pocket than Evernote. While I love Evernote and use it every day, Pocket is all about links to content I want to read later and that’s how I use the service. That’s valuable information about my intent and interests.

You know who cares about the value of links as a measure of intent and interest? Twitter sure does. Look at their history of taking control of other people providing links to content shared on Twitter. They have a history of moving to take control of 3rd party services that are aggregating information about links and sharing activity:

-Bit.ly was replaced by t.co for link shortening
-Twitpic and yfrog gave way to native image sharing with pic.twitter
-I can only assume that Twitvid and others will eventually give way to Vine and some native video hosting or sharing service

I also think that Twitter cards are going to give Twitter even more insight into how people consume media objects on Twitter – they know the value in understanding how content is shared and consumed on their network.

Twitter doesn’t have its own version of a Read It Later service. As it has done with other services in the past, the Twitter client gives you the option to choose a Read It Later service. Twitter has already moved aggressively to control the content I consume and share in real time. The next frontier in better understanding my interests is in also understanding information that I find interesting but choose to consume later.

To be clear, Twitter has integrated Pocket into its core application, so it does get signal data on how often a given piece of content is saved on Twitter. They also get all of the data about other content I share via email or other services as well. But I think of Pocket as my personal newspaper and adding Pocket to Twitter’s arsenal of services would give them an even wider perspective on what Twitter users care about and read when they are not on Twitter. As someone who believes that Twitter will continue to focus on monetizing through interested-targeted advertising, knowing what I read and care about on and off Twitter is valuable interest targeting data and I can see why Twitter would value that.

As always, comments are open. Or you can message me on Twitter @chudson.

About three years ago there were a handful of companies that set out to build Android-first or Android-only startups. All of those, including the one that I co-founded, had a thesis on why focusing on Android first or exclusively was a wise strategy. With a few exceptions, most of those companies, including mine, have not yet been successful. The reasons all vary, but I wanted to lay out what I thought were the perspectives on why Android-first or Android-only strategies would work and why they haven’t worked for most companies as of yet.

This is not to say that there aren’t companies, particularly in games, where usage and monetization are sufficient to support an Android-first or Android-only strategy. You can look to those companies as examples of why it can work when certain conditions are present.

Most people working on Android strategies from the start adopted one of three core strategies, each of which I will summarize below. All three strategies generally supposed that Android would get better – the devices would improve, monetization would improve, and developing for Android would get easier.

“We will be like [insert iPhone app] but for Android.”

The basic logic of this strategy was that many of the iOS-focused companies who were building great applications would not prioritize building for Android and this would leave a gap in the market for Android-focused developers. One of the early targets was Instagram – Instagram did not rush out an Android version of their application and that left a hole to build the “Instagram for Android.” The theory was that while those iOS-focused companies stayed focus on iOS, the Android-focused companies would find good traction on Android. Doing so would create Android-focused competitors with whom their iOS counterparts would have to reckon. The end game for this strategy was to either a) build a real beachhead that would yield an interesting company based on audience or traction or b) be well-positioned to get acquired by another iOS-focused competitor when they wanted an Android play.

“We will focus on Android first and then launch on iPhone when we work out the bugs and user experience.”

This was another common strategy I heard articulated by smart people. The goal for these folks was not to be Android-only and ignore iOS but rather to use the nature of Android and Google Play (no gatekeeper on pushing updates, more freedom around app promotion and customer acquisition and the large, rapidly-growing audience) to test out concepts and ideas which would later either migrate to iOS or become multi-platform mobile products or services. The core thrust of this strategy was that the ability to push updates and tinker with an app on Android was a faster path to learning than dealing with the iOS ecosystem. And, as a corollary, there was a belief that lessons learned on Android could be applied to iOS development.

“We will become good at developing Android and learn its ins and outs until monetization catches up with iOS.”

This is what I call the patience strategy. It was basically a recognition that Android was not, at the time, a compelling monetization platform for developers when compared to iOS. Rather than trying to force the issue, a set of developers decided to hunker down, focus on Android, learn the platform from a technical and distribution standpoint, and grow as quickly as the platform would allow. This strategy assumed two things. One key assumption was that the lessons learned in the early days of Android would have lasting value going forward and would be hard to replicate. A second assumption embedded in this strategy was that being in market and learning would confer an advantage relative to waiting until the platform was more stable and attractive and jumping in them.

Broadly speaking, I think all of these strategies have proven difficult and I have some thoughts as to why that has been the case.

The cost for waiting to address Android as an iOS-focused company has proven to be low.

Probably the most difficult market development for the Android-first crop of startups has been that the cost of ignoring Android for iOS-focused companies has proven to be pretty low. For companies that build really great applications on iOS, waiting to release on Android has been okay. I look at a lot of the larger companies, including both Instagram (when independent) and Facebook, where their decision to wait did not create a window for a viable competitor to emerge.

The technology and design principles that can propel you to success on Android don’t necessarily map to success in iOS.

Another challenge, particularly for the folks who chose to start on Android and migrate to iOS, was that the design principles and technical skills that can lead to success on Android don’t all translate to iOS. I think this is particularly true when it comes to UI and UX. I use an Android and an iOS phone every day and I can say that Android gives you a lot more option to use menus and submenus to hide stuff and I, as a user, have more buttons to use to navigate when I’m inside an app. And it has to work on a variety of screen sizes and form factors. In many ways, the iOS experience is more constrained and the general way I use iOS apps is different.

The benefits to getting in early and learning are still unclear.

Three or four years ago, Android was really a mess. It’s not perfect now, but it has come a long way. The platform itself does more for developers than it used to. Fragmentation is still an issue, but the core OS has gotten better, as have the devices. So there’s a legitimate question as to whether lessons learned in 2011 and perhaps even 2012 still apply if you are starting Android development today. In some cases, getting in early allowed a company to build a really strong market position and defend it – see Dragonplay in the world of poker apps in Google Play. In many other cases, those early entrants simply confirmed that building on Android was hard and maybe was a good deal of pain for an uncertain amount of gain.

The lack of consistent per-user monetization limits the ability to invest in paid user acquisition.

I think people have written pages and pages about how Android per-user monetization is not on par with what you see on iOS. That is true for many (but not all) categories. The challenge in low per-user monetization for startups is that for many, paid user acquisition is part of how they plan to grow. That per-user revenue provides the funds required to support advertising and paid user acquisition. The challenge, at least in my opinion, seems to be that while Android users are less expensive to acquire (when compared to iOS users on average), the return on that spend is not always high enough to support paid user acquisition. So that basically takes paid user acquisition off the table as a growth strategy for many companies not in games or other high monetizing questions.

Ironically, I think the net result of the lack of success for Android-first or Android-only strategies has been that iOS companies now think about tackling Android earlier in their lives, even if they don’t do it right away. In my conversations with mobile startups, they all know they’ll have to answer the Android question even if the answer is that they’ll address it later.

As always, feel free to leave a comment here or send me your thoughts on Twitter @chudson. I’m particularly interested in your thoughts if you have started an Android-focused company or led Android development at an iOS-focused company.

I wrote an old blog post about the challenges for startups competing with core apps on the major mobile platforms. As is the case with many things, competing to replace core app functionality (email, calendar, photo, messaging) is a high stakes game with big rewards and lots of risk. And I’m not an investor in any calendar company (I use Tempo and Sunrise both on my iPhone and Google Calendar on my S3) so lets just get that out of the way.

I’d argue that if you gave me your email logs and your calendar, I could make an educated guess about your interests and how you spend your time. A few thoughts on why I think calendars are interesting:

Email is messy and hard when it comes to divining context and insight, but I think calendars are actually way easier. Calendar data has more implicit structured signal than email and hence is (potentially) easier to understand and evaluate.
Calendars have dates, times, duration, and context about who else is involved in a given appointment. While there is value in being smart on top of that data (did I actually show up to that meeting, who created it, etc.) the base layer of structures info is useful and interesting in and of itself. It’s a good structured data store for divining intent, interest, and other nuggets if value about how a person spends his or her time and what matters most. Hours of the day are fixed and how people spend them (according to their calendar) is a valuable nugget of information.

Most stock calendars are feature-light and power users want more
Whereas email has advanced a lot, most stock calendars are still really basic. They tell you where you need to be and where. But they don’t give you much context on who you’re meeting. Many don’t make it super easy to share your location or ETA of you’re running late. And they don’t encourage or prompt you to stay in touch or follow up on what happened in the meeting. As such, I end up using tools like Twist to give people updates on my ETA when I wish it was really just baked into my calendar. The same is true of tools like Refresh, which I use to keep notes and info on people who I’ve met. A lot of the 3rd party tools I use have value because many calendars I use have a fairly rudimentary feature set.

Unlike email, calendars are basically double opt-in.
The biggest difference between email and calendar is that email is an open channel. Anyone who knows my email address can email me. Systems that want to know context about email have to start by separating signal from noise. A well-managed calendar doesn’t have this problem as most events (other than Facebook events) that show up on my calendar are on there because both parties agreed to meet. That’s a powerful bi-directional signal.

The one big elephant in the room when it comes to calendars is what Google is doing with Google Now. If you use Gmail, Google Calendar, and search with Google, Google Now is the early window into what a smart digital assistant that augments and improves a calendar will look like. But I don’t expect the entire world to tip toward using all Google services for personal and work purposes, so I think there will be a continued opportunity for 3rd party tools to augment basic calendars. For more on my thoughts on Google Now, you can read this post.

As always, feel free to leave comments below or chat with me on Twitter @chudson.

I’ve been playing with a bunch of wearable tech lately. I find it all fascinating and really fun as a window into the future. The picture in this post shows the four wearable devices that I play with the most – Google Glass, FitBit (I am an investor), Jawbone Up, and the Pebble smartwatch. Wearable technology is one area where I feel like you really need to literally wear and use the products to get an informed picture on where things stand. Having played with a bunch of wearable tech lately, I wanted to write down some of my thoughts on the current state of affairs in wearables.

Can Be Worn vs. Want to Wear

I think we are very much in the first inning of designing wearable technology that is literally wearable (as in you can wear it) as opposed to wearable technology that you want to wear. It still feels to me like we are very much in the phase of the market where proving that things can be done is outpacing the fashion and design sensibility around building and shipping wearables that look and feel like fashion pieces.

Wearable Need Not Mean Visible

A lot of the early wearable technology that I’ve played with is very visible. You wear it on your face or on your wrist and others are aware that you’re wearing it. But I don’t think that every interesting application of wearable technology requires that the technology be visible. One other way to solve the first generation design challenges is to focus on making wearables less visible as opposed to more visible and obvious.

Too Many Things to Charge Too Often

As is the case with almost all of the electronic devices I own, one of the thing that plagues a lot of wearable devices is power consumption. Between my smartphone, tablet, and laptop, I already have plenty of things to charge. Adding in a few additional wearable technology items means that I have yet another set of devices to charge. What would really be a leap forward would be a generation of wearables where I could go weeks (as opposed to days) in between charges.

Smartphones Continue to Do the Heavy Lifting for Wearables

As much as I like the fact that I can wear a lot of wearable technology, many of the devices are limited in terms of what they can do. They don’t have native network connections. They rely on Bluetooth or something else to communicate with another device that has more processing power, memory, or storage. The current generation of devices is designed to work in concert with smartphones – many of them are not nearly as useful without a smartphone in the mix for data connection or processing as they would be without one. So it’s hard to think of most of today’s wearables as standalone devices as many function more as complements or extensions of the mobile phone.

There is Tremendous Work to Be done in Developing UI and UX Conventions for Wearables

We are in the very early days of exploring what it’s like to have a computer on your face or on your wrist. It has taken us awhile to learn what it’s like to have a computer with a data connection, GPS, and sensors in your pocket and I’d argue we still have a pretty primitive understanding of what that combination of features will unlock. We are way earlier in the game in terms of learning the same about life with wearables.

If you own, like, develop, or use wearable technology, I’m curious to hear about your perspectives. Feel free to leave a comment below or send me a message on Twitter @chudson.

This is a really short post expressing a personal frustration of mine. I regularly carry two phones, an iPhone 5 and a Samsung Galaxy S3. One of the things I really like about my Galaxy S3 is that it gives me some insight into which applications I’m running are having the most impact on my battery life. I appreciate that the Android OS gives me that level of insight. I find the experience on my iPhone 5 to be maddening. I have no real insight into which applications on my phone are taxing my battery the most. The simple answer is that I know that things that are GPS or network heavy (Google Maps, Waze, Spotify, Pandora) can be heavy consumers of my battery, I have no idea how much my usage of a given application is contributing to my mediocre battery experience on my iPhone 5.

As a counterpoint, one of the things I really like about Onavo is that it gives me some sense for which apps on my phone are consuming the most data. Why can’t I get the same level of insight on my iPhone 5 when it comes to battery life?

And yes, I have spent countless amounts of dollars on Mophie, Maxboost, and other supplementary batteries for my phone. Rather than deal with the symptoms, I’d like to know more about the root cause of the apps that are draining my battery so I can do something about it.

As always, comments are open – feel free to leave one below or send me a message on Twitter @chudson