My selfish interest in Glass is how we can use it with Tempo to be even more anticipatory and contextual but my curious interest is actually related to voice. There are significant misunderstandings as to how voice to text works, the technical library is known as the ASR (audio speech recognizer). For a machine to accurately translate voice to text, it needs access to millions of samples of human voice to improve the statistical models it’s built-upon. This is why each time you speak into your phone, TV, computer, those utterances (what they are technically called) are sent to a server, stored and usually manually listened-to and transcribed, to continue to improve the algorithm. On this note, I think Siri/Apple recently said they store your voice samples for 2 years and probably for this purpose.

The big challenge is the input. An utterance over the voice network (eg a 1-800 number) versus your phone application over the data network versus your car Bluetooth are different. They have different microphone qualities and they have different sorts of background noise. This is why Microsoft was rumored for many years to have the better ASR for voice calls because of Tellme but Google to be better for digital (voice via an application on the data network) because of Android (and both by the way behind market leader Nuance). This potentially means that you need millions of utterances from each unique microphone, place setting, network, device etc. It’s a lot of work and it’s taken significant engineering investment to even get to where we are today.

To make voice to text better, applications will often couple it with other fuzzy technologies. For example, Siri is rumored to post-correct the voice-to-text using NLP (natural language processing). This means if the output of your utterance is “What is the park,” Siri might post-correct this to “Where is the park” realizing that the first output was grammatically incorrect. This is in part why Siri was such a technological achievement – it was able to take garbage-in and still return a meaningful result.

With Glass, Google is collecting a new set of utterances that has never previously existed. The microphone is on your face and so this will yield millions of new utterances to build upon. But what gets me really excited is that the Glass rests on your face and so Google could potentially improve the voice-to-text by coupling it with the accelerometer. As you move your mouth, the Glass will move ever so slightly. I don’t know if this movement is significant enough to be measured or more just noise and whether it needs to be measured while sitting, walking, running etc. But if there is enough variance to derive patterns, they can effectively use the accelerometer in Glass to post-correct the voice-to-text. It’s the equivalent of a machine “lip-reading” and could potentially be more accurate than even the voice-to-text itself.

Exciting times!

We are certainly entering the age of the “smart or learning” application. Use of AI, semantic technologies, learning, sensors and other signals to deliver personalized user experiences is happening – why should your experience in Application XYX be the same as me? It shouldn’t; each of our user experiences should be different and personalized to our likes, interests, needs and so forth. Big data and the cloud has enabled affordable data crunching to deliver personalized experiences but there are certainly some things to think about as we had discussed on the panel.

Some takeaways:

1. Context is not a category. I often analog this to 04/05 when LBS was a category but in reality, what app doesn’t benefit from knowing its location? LBS is no longer a category but it’s a layer across all apps. At present, context-aware is being treated as a category (ie you are in the “Assistant” category) but this is a short-sighted view. Context will become a layer across all services and maybe even yielding the definition of Web 3.0 with the semantic web?

2. Personalization and context can happen at the onset (initial experience with an app) but the real magic begins once you have collected enough data to mine and analyze. This is the chicken and egg problem with context-aware. The benefits may often not shine until you’ve collected that critical threshold of data to start making useful suggestions or augmenting the experience in useful ways. As you probably all have experienced, a recommendation system never works well at the beginning but as you tune the machine, the system gets better but unfortunately most users give-up well before that.

One approach is to seed some learning initially by asking setup questions. For example, both Zite or even Sosh ask at the onset, what are your interests and seed some initial suggestions and learning to provide enough of a hook for you to continue to use their applications so they can collect more data and improve. Leveraging and expecting context to be perfect at the onset is very hard and in someways this is what made the Saga virtual personal assistant so hard to digest initially because the suggestions were not relevant or too generic but they have since rectified this by tuning how many explicit questions to ask the user at the onset and in your general usage.

3. There are two types of learning: implicit and explicit learning. In almost every instance, explicit learning will trump implicit learning and thus why the FourSquare explicit check-in is more powerful signal for restaurant recommendations then the implicit track where everyone goes Alohar Mobile enabled approach. Implicit learning requires significant data but more importantly significant correlated data to make sure that your results are not anomalies or skewed. A great example of this is you telling Apple Maps that a particular address is wrong vs Apple Maps attempting to deduce that by looking at tons of traffic patterns and movement after the destination and so forth. Unfortunately, very few applications if any have really succeeded in collecting explicit feedback especially where the user perception is that they are having to train the system; users want immediate delight! Pandora and Netflix are obvious exception and in someways, the simplicity of their feedback system with thumbs-up and thumbs-down absolutely helps.

That aside, with enough implicit data, you can absolutely make smart suggestions but how much data is required depends on your use case. There is learning on a user but there is learning on the masses and some services very much benefit from the aggregate data. In addition, for implicit systems to work, you need to have some understanding of your personas (cohorts). For example, my user base hypothetically has 5 types of users and these are the patterns or signals for each type. Having too few or too many cohorts can have adverse effects and so determining what your clusters are is an essential part of making implicit learning work.

4. Location is only 1 sensor of many. I find it interesting that in many of my conversations when talking about context-aware, the assumption is immediately always-on location. Yes, location is 1 signal and it may be a stronger or weaker signal depending on use case (eg for Zite with news, location is certainly not as important as time but for Foursquare, it’s all about location). But in addition to signals like location and time, there are many other signals you could leverage. There may be back-end data sources that you use to drive intent for your application. For example, Tweets and Facebook posts could signal likes and dislikes of particular brands and this is how some ad networks like intent-targeting ad networks like LocalResponse leverage this information. Alternatively, there are other device signals that you could leverage like whether the user is driving or in an airplane or maybe whether it’s sunny or rainy outside. There are literally 100s of possible signals that can play into your service depending on the use case.

Notably, even with the 100+ signals and this is up for debate, I have generally found that 2 or 3 signals will be 80% of the “answer.” For example, Netflix may use significant statistical data to figure out your interests based on what you’ve watched previously and so forth but your explicit likes may be 80% of the signal.

5. One of the hardest things with all learning applications is QA and regression. The problem with recommendations and suggestions is that there is often no right or wrong answer. Other signals like product statistics have to be analyzed to see if your tweak in the algorithm yielded a positive result. A great example of this is Google search – how do you design a QA system to determine that the search results are getting better and how do you know that a tweak in your algorithm doesn’t break something in the long-tail that you may have forgotten to QA (caused regression).

There are different approaches to this problem but all require some combination of options. One approach is to use an army of mechanical turkers or others to evaluate the results on a random sampling of long-tail data. This has data privacy issues if not done right and does require ample setup to make work. Other approaches include explicitly asking the user and/or looking at product statistics to see if things have trended in the right way. This of-course requires a thorough understanding of your personas/cohorts and ample tools to glean the statistics you need to drive a conclusion. Another approach involves pre-annotating 100s of cases with their expected results and then building 100s of unit tests to make sure that all of those tests continue to pass with each improvement to the algorithm. The problem here is you never know if you have enough tests across the distribution and it can take serious time to build enough of that corpus to really start seeing the benefit.

I can probably keep going with more thoughts on how to bring context into your application but I thought the above would serve as a quick primer on the topic and a short summary of some of what we discussed on our panel.

Feel free to ping me offline if you want to discuss further!

Last week at the MobileBeat conference, I moderated a discussion with John McGeachie from Evernote, Nancy Ramamurthi from TripIt and Jason Mills from Expensify on some of the strategies they took to achieve bottoms-up success – let me summarize below:

1. UX/UI is still the #1 feature. One of the historical advantages of enterprise sales was the focus on functionality over user experience. This works if you have a sales force demonstrating each feature to an enterprise buyer but when an app is being downloaded directly by your target user, you are held to the same bar as a consumer app meaning the user is short-attention-spanned, fickle and will get frustrated easily.
2. Like a consumer app, iterate and A/B test as much as you can with your target audience. Prosumers are ultimately consumers.
3. Freemium is common and free-to-paid works (eg Webex, SurveyMonkey, QuickOffice) but paid-only is challenging. John w/ Evernote specifically mentioned how some of the greatest conversion came after 3 or 6 months of use of the application. Achieving freemium means converting a small percentage of a large number.
4. Mobile results in awesome customer acquisition. Jason from Expensify mentioned that mobile was their largest customer acquisition channels and ironically one of their biggest challenges was actually making mobile users aware of their online experience.
5. Mobile is also accounting for a greater percentage of paid conversion. As opposed to the desktop, the app store is challenged because of the lack of support for subscription billing but this can be remedied by offering longer-term plans (eg 3 months, 6 months, 1 year).
6. On the topic of privacy and enterprise data, transparency and having clear guidelines reigned. Be clear to the enterprise what you do/don’t with the data and be ready to honor some take-down or data-removal requests.
7. When it came to features, focus on the 80%. When the topic of bottoms-up sales and how it may butt-heads with an eventual direct enterprise sales team, the panel universally agreed that the features that made the roadmap were those that benefited their bottoms-up users (the 80% bucket!). And this meant even saying no to some enterprises as painful as that may be.
8. There is a right time to begin enterprise sales along-side bottoms-up. When you have a critical mass of prosumers at common companies using your product, start selling group editions. Nancy with TripIt mentioned how they signed-up ~1300 companies in a relatively short amount of time with TripIt Pro but only brought this product to market 18 months ago or 5+ years since they started!

And now some observations:

1. Most of these startups (Evernote, TripIt etc) didn’t know how successful they were going to be amongst prosumers in the enterprise at the onset. They launched consumer focus and got pulled into the enterprise. In the case of Expensify, they targeted the prosumer and got pulled into consumer with customers using Expensify as an alternative to Mint.
2. The use cases addressed by each of these companies are very horizontal. They are not job persona or industry vertical specific but rather broadly useful and applicable putting them closer to the consumer category.
3. All of them seemed to have taken shots in the dark with their price point but some price elasticity testing was done with Flash sales.

It was an awesome panel and I look forward to seeing more enterprise mobility apps take advantage of bottoms-up sales!

What’s fascinating is I distinctly remember when this wasn’t the case. When I was working with Kodak Mobile in 2004, the situation was quite different. Not in any negative way, but we had almost a surplus of strong UX talent with multiple people interviewing for UX opportunities. In today’s economy, strong UX team members (rightfully so!) earn similar compensation as relative technical talent!

This got me wondering – how did this happen? And then it occurred to me that user experience is the next layer in the stack. In the 70s, 80s, hardware was the juggernaut. As seen in Pirates of Silicon Valley or other, IBM and other hardware vendors did not expect software to ever reign. Hardware was the premium and where the money was made but as I was reminded earlier today when I was considering taking my Apple Monitor in for warranty, a 42 inch TV is now $400 – hardware has absolutely become commoditized and the premium moved to software.

But within software, there are multiple layers to the onion. Initial software development was a pain in the butt. We didn’t have the benefit of EC2 and other frameworks and platforms to leverage. I remember while in college in ’99, it took real Computer Science chops to simply build a web application and it cost $500+ per month to just host a simple server and website. Now software can be readily developed and thus why you are seeing multiple movements like CodeAcademy and the Kahn Academy attempting to teach software development to children – this makes perfect sense, building software is a lot easier (and affordable) now than it was in the past! Let’s be honest, who is a Software Engineer that hasn’t at least dabbled in building an iPhone app? It’s simply gotten too easy to write software.

As a result of this, the differentiation has moved upstream. Instead of maintaining a 2:1 engineering to QA ratio within an organization, the QA ratio has vastly shrunk with real-time “live” user-testing and more importantly software frameworks and approaches that better handle user data and security. Whereas the QA ratio is gone down, the engineering to UX ratio has vastly increased which makes perfect sense. The next layer in the onion is UX; there is certainly a growing repository of guidelines and approaches in dealing with UX and we are of-course limited to what is possible with the hardware and software but we are definitely nowhere near a point where UX is commoditized.

So my question is whether UX can become commoditized? And I know most would argue that would never happen just like the hardware in the 70s/80s (eg IBM) and the software in the 90/00s (eg Microsoft) but the reality is that software, just like hardware has been getting cheaper year over year.

On a seperate note, if you haven’t read Steve Jobs biography, I strongly recommend it – it’s incredible to see that someone was paranoid about design in a time when being paranoid about design wasn’t sexy.

Over the past month, as a mentor at 500 Startups and while attending AppNation Enterprise, I’ve met a number of startups focused on enterprise mobility targeting the “prosumer.” A pretty consistent theme among these mobile apps is the focus on trying to achieve a direct-to-employee sales model. This makes absolute sense; investors are looking for the next Evernote or Dropbox where an app develops organically and is used by prosumers (whom have money) without the need of developing an expensive sales organization.

What I have fond ironic is that many of these startups are having to hire that “one” sales rep because their traction in a direct-to-employee model hasn’t panned out. This is the result of a multitude of reasons:

 
And the real bummer with all of this is the company keeps trying to add horizontal features to target the prosumer instead of doubling-down with vertical-specific features for the segment their app is succeeding within. They are doing this because because investors won’t invest unless they can get rid of that “sales rep,” ultimately putting the startup in a perpetual state of “straddling” where straddle = FAIL.

I’ve concluded that you can’t straddle between prosumer and enterprise. You either double-down on enterprise and choose a specific vertical or you actually target the consumer. I know that sounds completely left-field but the reality is that Dropbox and Evernote, being the representative prosumer success stories started as consumer apps that were widely adopted in the enterprise. Targeting the prosumer may be the ultimate goal but the aha moment for me was that the use cases need to appeal to the consumer.

Last week, on almost an 18-month basis, it was time to send in my HP laptop into warranty. I’m not sure why I continue to buy AMD based laptops considering they are plagued with over-heating issues (and I’m sure my over-use lifestyle doesn’t help). In any case, the laptop was off to warranty and so I only had my Chromebook.

I made sure to copy all relevant docs off my laptop into a personal folder on my Dropbox and my recent move to Office365 with some pain (for another post) meant all of my email was in the cloud (and yes, I use Gmail as well but I am an Outlook fan). I also took out the primary drive since warranty seemingly wants to format the primary disk as if that helps solve the problem (but that’s for another story).

Day 1 with the Chromebook wasn’t too bad, it was a lot lighter than my 17-inch laptop and so that made it easier to work with and the battery life was awesome but then I hit my first snag. Not sure what are the odds, but I received an email with a video product demo attached. I probably have only received a video attachment in my email maybe 10-20 times in my life and it happened to be this week, ha! In any case, you realize pretty quickly that the Chromebook can’t really open or play miscellaneous attachments. So I had two options, open it on another computer or upload the video to YouTube to than watch it (sounds counter-intuitive); I decided to defer until I got my laptop back.

Day 2, 3, 4 etc went pretty smoothly. I was finding that the Chromebook was very sufficient but I was starting to miss something and I realized it was the geek in me. Windows and Linux desktops allow you to constantly just “tweak” around, I’m not sure how you describe it but it’s the moving of icons, adjusting folder properties, renaming files, re-ordering your tray, performing pointless upgrades etc etc. Maybe it’s just me, but I find these little bits of activities to be almost fillers of micro-boredom, maybe best analog’ed to the mobile app ecosystem where much of the fun is in just browsing and randomly downloading/uninstalling. That piece was missing with the Chromebook and it almost felt like I was not being productive since I was always in the browser?

Five days had passed and I somehow managed to not have to edit a PPT or an XLS considering I’m a PPT and XLS monkey. Part of that was because I timed the warranty with a long weekend and so I was mostly offline. In any case, this is where the fun began. As much as I love Google docs and use it extensively, it’s no substitute for Excel or Powerpoint (or even Keynote, I’ve had a Mac laptop as well). Editing a financial plan in Google Docs was a non-starter and so I thought I’d give Office Web Apps a shot and this is where it broke down. Whether it’s Microsoft or Chrome, Excel and Powerpoint online was not really working via the Chromebook. I’ve certainly played with it in the past via Chrome on my PC but it just didn’t work on my Chromebook. Considering that these items were time critical, I ended-up borrowing another laptop to edit these docs and unfortunately had to keep that laptop because I can’t “slideshow” from the Chromebook. I suspect Google is thinking through all of these scenarios and is probably targeting the more casual web user as opposed to the hyper-prosumer but I would add that I did make time for Allies and Empires and Flash is awfully slow on the Chromebook.

My laptop arrived a day early and I was back to my PC. Fortunately, I managed to not sign-into Skype that week since it was a meeting-full week but I do remember one day where I was looking for the calculator app and realized that there is no calculator on the Chromebook; I tried simple arithmetic through the Google search engine and that did pretty well :) Anyways, summarizing, I was pleased with the Chromebook but it wasn’t sufficient for my needs. For vacation, it’d probably be perfect and for most folks I know who primarily only browse, it’s more than sufficient. I presume Google will build more stuff locally into the Chromebook to substitute for some of these problems (looking more and more like an OS) but regardless of how rich they make the device, if it feels like it’s all in a browser, I will certainly miss the pleasure from tweaking arrays of options and menus!

2010 was certainly the break-out year for Android. Apps for Android grew from an impressive 30K to an even more impressive 250K. Android devices have even surpassed iOS and are on the verge of surpassing RIM representing 40%+ of smartphone market share. The growth has been phenomenal but much of the focus has been consumer.
On par with Android’s rise, is the growth of tablets into the enterprise representing a new opportunity for developers. Although this initial growth began with the iPad, the Samsung Tab and other devices are beginning to take reign within enterprises at a rapid pace and I fully expect that in the next couple years, Android may become the dominant tablet platform. Let’s talk about some of the enterprise Android trends and opportunities for developers!

Individual Liable Devices
Tablets are rapidly being purchased by employees of the enterprise. Traditionally, enterprises would issue their devices to their employees known as corporate liable devices but with new mobile device management tools, employees can now use their own devices for accessing corporate data. Employees like this since it provides them choice (eg Samsung Tab 7 inch or 10 inch?); they can purchase what they want and use it for work much akin to using your own laptop in the office!
As a result, we have gone from maybe 20-30% of the employees in a typical enterprise being mobile enabled to 70%+. For the developer, this means demand! Employees want more apps from simple tools such as requesting a tax when I leave the office to more complex apps such as locating colleagues in the office via an in-door map – the opportunity is enormous!

Enterprise App Stores
Android’s “openness” allows enterprises to create their own app stores and thus why the Samsung Tab has been successful within the enterprise. If an enterprise for example, wanted to distribute an app to their employees, this would be difficult. Do I put it in the consumer App market? Or do I send a link to all my users and then re-send a link for each update? That would be quite painful!
Android’s openness has allowed for enterprise specific app stores where the enterprise can control which apps they want to distribute without having to submit them into the general app market.

As a developer, this means increased adoption and visibility for your enterprise apps. If you are listed in the company specific enterprise app store, you will certainly receive near 90%+ employee penetration! But with this, you must also keep in mind, that larger enterprises do request simple customization such as branding which is something you would need to accommodate.

Cloud Adoption
Enterprises are fragmented; their data resides in multiple tools (eg Exchange, Basecamp, Yammer, Salesforce Chatter). More and more of these tools reside in the cloud and many of these tools have mobile specific apps.
With enterprise adoption of cloud services, app developers can more easily integrate corporate data into their application much akin to connecting your app to Facebook or LinkedIn with OAuth. This is huge for developers since much time in traditional enterprise apps were spent building the custom integration into each “on-premise” system.

But equally important is Android’s multi-tasking architecture making it very easy to launch other applications amongst different mobile enterprise applications. For example, I could build a reader for enterprise news that feels seamlessly integrated with the Salesforce Chatter mobile application.
Conclusion

The Samsung Tab has been a great demonstration of the power of Android tablets. Although I fully expect that you will see these tablets in your living room and the backseat of your car, the enterprise has been taking the lead in tablet adoption and offers a great opportunity for developers to build applications!

- We did a quick and dirty test to see if users were willing to upgrade for the removal of ads. Our test wasn’t perfect – the user could pay whatever they wanted (1 cent or 1 dollar etc) and the billing workflow was processed through mobile Paypal as opposed to Android’s in-app billing (this test was done before that was available). The result was abysmal, some 10 users converted amongst 300-400K (at the time). Certainly, the result may have be better today with in-app billing but my conclusion is that the expected conversion is going to be low unless the ads become annoying assuming your users don’t abandon you (eg has anyone else noticed the increase in ads on Pandora!). Cathy Edwards with Chomp had suggested that our user base was self-selected and if we instead had made a separate paid app , we would have seen better conversion (since those would have been users willing to pay as opposed to those who only download free apps). Note, there was consensus that the iPhone seemed to have more users willing to pay versus Android and I’m curious if anyone has done any analysis as to why (besides number of cached CCs)?

- We saw significant variance in eCPM amongst different ad networks. You can never do enough A/B testing and it is absolutely one of the biggest ad monetization mistakes I’ve made with previous projects in my early days (eg ToneThis, TinyTube etc). Moving from 1 ad network to multiple ad networks instantly resulted in a 30-50% improvement. The reality is that eCPMs are not the same and either building your own or using third party mediators such as Nexage may be your best bet. In addition, make sure to test as many placements as you can. With TinyTube, for a very longtime, we didn’t put ads on the homepage because we thought it would upset the user. One day we decided to do so an instantly doubled our revenue with no increase in user attrition!

- We saw interesting eCPM variance depending on the time of the day and/or the week. I understand variance based on season (eg end of the month quotas or end of year spend etc) but to see variance through the day was interesting and I wonder if that was based on the algorithms ad networks used (eg serve high value inventory first with a ad spend cap for the day). Curious if anyone else has seen similar?

- Passing location certainly improved the eCPM but resulted in a different problem. Our users were getting upset to the point of not installing the app wondering why we were asking for location. Unless your app needs location (eg specific feature) which a Recipe Search app does not, than asking for location may result in user backlash.

- There was some discussion/debate about whether to have ads in the product from day 1. I’m of the opinion that it’s best to introduce it initially because no matter what you do, you are going to upset users. If you do it initially, it’s expected – if you introduce it later, you will definitely see some negative commentary! Jean Hsu with Pulse News mentioned that they had a paid app and than an ad-supported version of Pulse and users started commenting that if they (Pulse) introduce ads, they want their $1 back :)

- There is significant distinction between mobile web and in-app advertising. With mobile web, I’ve absolutely seen a significantly better eCPM for the top ad placement (eg top of the page) usually because the CTR is almost 2X of text/banners that are displayed in the body or footer of the page. With in-app advertising, I’ve seen fairly consistent CTRs regardless of placement (floating header or floating footer). This is important because you can design your app accordingly and then place the ad where it is most convenient.

- We touched on this briefly yesterday but there are various tricks we used to SEO/SEM. Everything from titling your application with keywords to titling the name of the company with the keyword as well (probably all good practices generally). Rob Coneybeer with Shasta Ventures had also mentioned the importance of the icon and real use cases with Smule’s applications as to how usage varied based on having a cool or crappy icon.

- Keyword versus categorical targeting – keyword targeting with mobile ad networks is mostly unavailable but categorical targeting is definitely there. Curious what others have experienced but we found that choosing all categories as opposed to the category you are most relevant to results in a higher eCPM since the ad network presumably than delivers the highest value ad across all the categories as opposed to just the one category. I imagine this is only temporary until we reach a point where the ads available become so large that the eCPM has effectively normalized (as opposed to the high variance we see today). Really the big question is how do you index the information inside of an app so we can do keyword targeting (especially if apps are the new web!)

Would love your feedback!

(BTW, link to an Intel blog post summarizing another panel I was on at AppNation)

Many point to Apple’s 2000M+ cached credit cards as being their most valuable asset. Why is it valuable, you may ask? Well, cached credit cards means one-click purchasing which is fantastic for all sorts of commerce (eg purchasing apps, physical goods and so forth). One less obvious benefit for cached CCs is how it enables CPA (Cost per action) advertising – let me explain. CPA ads typically require the user to complete some sort of form (eg completing a web form to trial some new product).The typical workflow requires providing billing and other details meaning numerous steps and clicks. However, if your billing details are cached, than the CPA workflow could be reduced to a few clicks!

Let’s walk thru an example of subscribing to Netflix. First, the user would click a text or banner ad for a Netflix trial subscription and is then taken to a landing page with specific product information about the service. The landing page is basically the sell page where you are going to make or break (convert) the CPA. Assuming you do a good job convincing your potential customer to sign-up for the trial, the user will complete a web form with his personal details (eg name, address etc) and billing information. The CPA has converted and the publisher serving the Netflix CPA ad just made his $25 bounty!

The challenge with the traditional CPA workflow on a mobile device is that your teaser page needs to be very concise given the limited real estate of a mobile screen. In addition the web application form needs to be easy to complete; we all know how difficult it is to type via a mobile keyboard.

One potential solution is the mobile wallet. If your billing details are cached, the web form could be auto-completed along with personal details resulting in almost a one-click CPA process and thus demonstrating the value of cached credit cards.

In the interim, clever stop-gap solutions have emerged. Instead of making the user complete a complex web form resulting in a poor CPA conversion, the user clicks-to-call a phone number from the teaser page. The call leads to a rep employed by the ad network who completes the web form for you (presumably at their PC). Companies like Moolah Media have demonstrated this workflow at great success and thus one solution enabling CPA advertising on mobile!

Update: I talked about a number of things we may see in the coming year at SXSW. Mike Merrill detailed some of my talk at his blog – thx Mike!

In any case, I’m hoping to push the enthusiasm forward by summarizing some themes which I think will make this a very exciting space!

Individual Liable Devices
The growing mobile enterprise ecosystem is partially being driven by enterprises now allowing employees to use their own smartphones for work. Whereas previously, employees would be issues a corporate device (known as corporate liable), employees can now use their own devices (known as individual liable) for accessing corporate data etc.

This has resulted in a second wave of new mobile device management companies such as MobileIron and AirWatch but has also created new demand for enterprise apps. Enterprises can now more “safely” make their internal data/systems with MDM (mobile device management) solutions enabling features such as remote wipe, now the demand has shifted to apps that can leverage it!

Enterprise App Stores
Riding the individual liable theme and MDM deployments, enterprise app stores are beginning to emerge. Companies like Ondeego are focused on making it easy to deploy, provision (and maintain upgrades) for enterprise apps. Enterprises want distinct app stores for their employees where apps can be certified as trusted and not made public in the general app store. Apple, for a licensing fee, now makes available an enterprise app store for the largest enterprises; unfortunately, SMBs are still stuck having to pay the 30% Apple tax.

Cloud Adoption
I hate using the word cloud because it almost sounds cliché but enterprises in mass are adopting cloud systems. Whereas standard services such as email were hosted on-site, enterprises are now using SAAS/cloud variants such as Microsoft BPOS (aka Office 360) or Gmail. Similarly other core services such as storage (eg Box, Dropbox), Wikis (eg Confluence, Basecamp), Collaboration (eg Yammer, SocialText) and so forth are offered as cloud/hosted services – what the role of the CIO is in 10 years is yet to be determined?!

In any case, as a developer, open enterprise data means you can now integrate with this data whereas previously tedious on-premise integration would have been required – a painful and IT dependent task.

Business to Individual
Most are familiar with B2B (Business to Business) and B2C (Business to Consumer) but a term I’ve begun to evangelize is B2I (Business to Individual). Traditionally, selling to the enterprise required an enterprise sale. You would pitch the CIO or IT department and sell your product top-down. With enterprise data becoming more available and with mobile app store distribution and billing, new enterprise startups can now sell directly to the employee/individual. Evernote and LinkedIn are great examples where employees adopt and pay for these services and than expense the cost to the company. As a startup, B2I is disruptive in that it does not require the traditional investment required for enterprise sales.

Dual Profile Phones
VMWare and others have been pushing the concept of dual-profile phones. In a dual-profile mode, your phone is like your Windows desktop in that you can have two distinct logins. One is meant for personal use and the other is meant for enterprise use. Not yet clear is to what extent the profiles are truly separated and most important what the actual UX feels like to the user. For example, there are several apps that I use for personal and work; there are also several contacts I SMS for both personal and work. Switching between profiles may feel tedious and quickly ignored. Where it gets more tricky is if apps are allowed to share memory space or not. If I save a bookmark in my work profile, does it show up in my personal profile? Do my photos sync? And so forth…

Outside of VMWare, operators are also incentivized for this to succeed. With two profiles attached to the device, you can have two accounts/subscriptions attached to the device. One subscription would be paid for by the employee and the other presumably by the enterprise. For the operator, this is a clever way to continue subscriber growth in a market (US) where we are 90%+ mobile market saturation.

Above is just a quick summary of some of the many exciting things happening in the enterprise – much more to come!