Search Results

I ‘m part of a hardware research group at Telefónica Digital called “Physical Internet Lab”. Three years ago we started a small group under the Emerging Technologies area of the company focusing on the Internet of Things. The commitment of the group was (and is), in ambitious terms, “to democratize the Internet of Things” opening it to as many makers, developers and users as possible. Our goal has been not entirely altruistic: Telefónica as a network operator has a lot of value to add in the Internet of Things economy. On day to day basis we build prototypes and products, usually connected objects or components like the Thinking Things building blocks. Setting up the lab three years ago was no easy task. We wanted to work at the crossroads of the Internet, the Things and the People. But our development skills were almost 100% software related. In the process we built a team skilled on all three sides. And we figured out how to do agile hardware. Of Agility and Hardware We ‘ve come full circle. Telefónica I+D (the Telefonica Digital development branch) was created 25 years ago to produce hardware innovations such as X.25 and ATM switches. We did that in the classical engineering fashion: writing long and rigid lists of requirements, splitting the work across solution providers, integrating and then testing following a waterfall schema. Over time Telefónica I+D adapted quickly to the technology changes and by the mid-nineties we were developing mostly software. First we followed the same engineering process; then we moved towards more iterative methods. In the last 10 years we have adapted fully to agile methodologies. As we were building the laboratory we found ourselves getting back to hardware. But the company now could not understand a slow-moving unit. The lab had to be agile. So we had to bring agile methodologies to hardware development. The first difficulties came with the corporate facilities. Hardware work demands physical proximity and we could not afford to have a distributed team depending on collaboration tools on the Internet. At the same time, soldering fumes or drilling noises were not welcome in our modern, bright, open spaces. So the team had to move to a closed office in an old building in Madrid city center. Moving to the city center was a boon: in minutes we could reach many shops and services, buying anything from hammers to plastic boxes. Visitors now found it easier to visit us in a centric garage-like office. This was great for our open approach as we wanted to help and interact with other companies and organizations. Purchasing tools was another problem. The corporate procedures were tuned for large-scale purchases such as server farms or external services. Buying a handful of resistors for 10 euros could take several weeks, creating bottlenecks to our work. Fortunately the purchasing department showed a great deal of sensibility. We worked together to redesign the process. Now we buy any component or tool in a single day while still working by the book. Putting together the Agile team Hardware work implies multiple teams across several companies with extremely specialized profiles. When setting up the lab we opted for a small and autonomous team, able to build a hardware prototype with no external dependencies. A small team allows us to work closely integrated, in the same location, continuously coordinating our work. A small team also means that budgets are smaller and is well suited to experimenting, failing, learning and adapting. Basic agile methodologies such as Scrum expect some degree of overlap between the specializations of team members, so that different people can execute the same tasks naturally balancing the work load. But hardware work is different. It demands a lot of specialization. In our case most of the tasks can be executed only by one team member. As a result, the Scrum methods and tools have to be modified to reflect this reality. Our internal workflow follows many steps. The first step is the Industrial Designer, a role which is somewhat of a novelty in the Telefonica Digital payroll. Carlos (that’s his name) starts his work in the CAD station designing the physical product: plastic pieces, metal straps, cloth, magnets. Then he builds the design using the currently available 3D prototyping tools such as the laser cutter, the CNC tool (i.e. a computer controlled drill) and a variety of 3D printers. These tools give much flavor to the lab. In some cases we start from an existing object that we hack so that we can explain a new concept. Carlos at the same time designs and builds, which is a bit out of his job profile. Software developers are multi-taskers, too – they design and type, while software architects can also code. In the hardware industry this is somewhat unusual and typical engineers expect someone else to physically build what they have created. In the lab we follow the software philosophy. It is leaner, and gives the designer a real feel of the piece or circuit construction. This approach demands some tolerance and patience from engineers who have to get their hands dirty. The same philosophy applies to the next step in the workflow: the electronics engineering part. The electronics engineer first designs new circuits, then prototypes them. We even design and build the PCBs to check that everything fits in place. The agile doctrine underlines the importance of early user testing. Early use provides rapid feedback focusing the most important characteristics of the product and showing what isn’t relevant for customers. To shorten the time-to-test we use 3D printing and prototyping technologies. In electronics engineering we massively use Open Hardware. Open Hardware gives us access to lots of ready-to-use designs that we can employ in product testing. In a sense, Open Hardware behaves now like Linux and Open Software in the mid-nineties. It allows us to focus on the real technical or design challenge rather than reinventing the wheel for every test. Electronics and physical design teams work side by side, so they can verify in real time how components fit in the same object. Our objects become more than simple plastic boxes, as they are tightly coupled with the internal electronics. Electronics engineers work also with the firmware developers. The firmware developers write the code for the embedded microprocessors. They also have to deal with connectivity issues and power management. In our Physical Internet Lab, electronics and firmware engineers work side by side. In most situations knowing what will firmware do simplifies hardware design. Similarly, software developers can ask for fine changes in the hardware designs nearly in real time. On the other side of firmware sits backend development. In our typical systems architecture, distributed devices communicate with a backend service in the cloud. We push as much intelligence as possible to the backend service, so our designs can evolve without touching the deployed hardware or executing firmware updates. We like to think that the back-end gives every object nearly infinite computing power and knowledge, as it can interact with any other Internet service. Again back-end and firmware developers work side by side. This tight collaboration resolves any integration problems before they appear, and encourages electronics and firmware developers to take issues to the more powerful (and more agile) back-end platforms. The final technical step is the front-end development, usually based on web and native apps. Again we do a lot of work locally in the lab, well integrated across the team. The frontend is also tested in complete end-to-end scenarios. Automatic testing tools execute scripts that run against the firmware and the frontend. And of course, there is a Quality Assurance side. We are extending continuous integration, test driven development and automatic testing to the embedded firmware. At the same time we have to handle more hardware specific tasks such as sensor calibration, assuring robustness and strength. Physical Interaction Design The web/application interface and physical design are the two endpoints of the “development chain” of our group. They form the two interfaces exposed to the final user. At the final part of our workflow, the physical interaction designer, works with both web / app and physical design. The physical interaction designer is responsible for the design of the connected object as a whole. He takes care of building a single object with a coherent interaction model in the physical world and in the Internet. Without the physical interaction designer we would have to separately design the physical object and the application or web interface. The result would be a split-personality product, usually an amalgamation of data stuck on top of a square box. The physical interaction designer combines the capabilities of the physical object and the Internet interface in a coherent manner. Physical interaction design, bringing together the Internet and physical objects is a completely new field. There are a handful of specialized schools in the world, and we are working too with UX designers with strong industrial design background. Everyday physical objects have usually long stories and designs optimized through centuries of use. We still have a lot to learn on how to take the Internet beyond of the smartphone/tablet/PC onto this physical object world. Customers will not adopt Internet of Things devices if they are a step behind of the design standards they have become accustomed in software interfaces. Agility plays a role here, once again. Developing and prototyping quickly we can try interaction designs with users, test our assumptions and build a sizeable bunch of knowledge around user interaction with connected objects. External providers Of course we have to work with external providers, especially when dealing with complex technologies or industrialization. For development we often use online services for as PCB manufacturing or 3D printing. They are extremely easy to use, robust, fast, and offer a direct web interface instead of long negotiations with a salesperson. For the final manufacturing we interact with real, serious manufacturers. Agile, as a software development doctrine has no solutions to this task. But Agile can be seen as a spin-off of Lean philosophy, which was created to deal specifically with manufacturing issues. One of the main lessons from the Lean methods is that service providers have to be tightly integrated in the business process. We have found this is very important also for us. The lab has spent considerable efforts building trust relationships with service providers and manufacturers, integrating their teams with the lab. Schedules and plans are shared under an openness philosophy. We have established even real time communication so their teams get continuous feedback from the engineers in the lab. The future of agile hardware We have yet a long way to create a truly Agile Hardware lab. Physical work is sometimes slower than software development. Some other times (especially when prototyping on Open Hardware designs) they are blindingly fast and have to pause and wait for software components. Speed differences keep the group working on different “user stories” at the same time. External dependences are many, and the lab will never be, in that sense, completely autonomous. But we can find yet faster service providers and build leaner and more integrated workflows with them. Regarding Quality Assurance we have to handle correctly the physical device characterization and fit the expensive and slow certifications in the product workflow. The bright side is that Agile methodologies provide and require continuous improvement. Every sprint or work cycle forces us to learn and adapt our methodology and organization, looking for a better process. Perhaps in a couple of years we’ll have a completely different process in a completely different lab, and it will be all right. #agile #hardware #iot #software

[tweetable]Facebook will live or die by user engagement, especially on mobile[/tweetable]. Whatsapp sends 18 billion and receives 36 billion messages a day. Let’s say it takes about 7 seconds to send a message and 3 seconds to read a message. This is based on watching how my teenage kids use Whatsapp texting and sending pictures. The math is simple: ((18B messages * 7sec + 36B messages * 3sec) / 60) * 30 = 117B minutes per month People have limited time and attention. So most of these 110+ Billion minutes were taken from the potential Facebook mobile engagement minutes. Wow! That is the cost of doing nothing for Facebook. There is more Whatsapp is growing at about 1M users a day. That means Facebook looses at least an additional 12.4 Million engagement minutes each and every day. For simplicity I take into account only Whatsapp users that are active daily, which are 70% of 450M monthly active users: 3.9B minutes per day / 315M daily active users = 12.4 minutes per day per user Now what? The Whatsapp blog says: “Here’s what will change for you, our users: nothing. The company remains independent and loyal to its promise of “No ads!”. There will be no immediate monetisation opportunities for Facebook. What can be there for Facebook beyond averting future disaster of Whatsapp killing Facebook mobile engagement? Or even worth, falling into Google’s hostile hands? Mark Zuckerberg writes about the acquisition: Our mission is to make the world more open and connected. We do this by building services that help people share any type of content with any group of people they want. WhatsApp will help us do this by continuing to develop a service that people around the world love to use every day. Will we see 450M mobile numbers brought in by Whatsapp coming into play helping Facebook connect people? Time will tell, but the potential is there for Facebook to become huge integrated communication provider on par with China Mobile, the world’s largest mobile operator. (China Mobile has 700M subscribers but, given that many people have two phones, the number of users is much lower and close to 450M of Whatsapp monthly active users.) – Michael (This article was originally published on Michael’s personal blog – here) #acquisition #facebook #whatsapp

Here are the stories of two successful birds on the app store. See if you can spot the difference. Flappy Bird was a mobile game developed by Dong Nguyen, a Vietnamese indie game developer, in a few evenings after work. He launched the game in May 2013, but only 7 months later (in January) did it unexpectedly gain immense traction. It reached the top of the US charts, and Nguyen was reportedly earning about $50,000 per day from ads. He couldn’t cope with the pressure and abusive comments however, saying it “ruined his simple life”, and removed the game from the app store on February 10th. Angry Birds was developed by Finnish game maker Rovio Entertainment. It was a runaway success… on the 52nd try! (That’s how many games the good people at Rovio had developed before Angry Birds). Rovio has expanded to be a successful franchise and merchandising business, counting its revenues in the hundreds of millions of Euros. Today, Rovio employs over 700 people according to its website. Why did Flappy Bird become a flappy Icarus, crashing after flying too close to the sun, and not a new Rovio? In truth, Nguyen and Rovio represent very different groups of developers. Their motivations are not at all alike, and so neither is their behavior. Developer motivations wildly differ Dong Nguyen and his indie game studio .Gears sits on the border of a Hobbyist and an Explorer profile in VisionMobile’s developer segmentation model. Hobbyists are motivated by the fun of making an app, and like Nguyen often do it in their spare time after work. They don’t care about success – killing off a successful project that interferes with their sense of fun and peaceful life wouldn’t seem strange to them. Arcade games like Flappy Bird and the other .Gears projects are a typical project for Hobbyists (professional game developers rarely touch the arcade category). Our Flappy Bird protagonist also shows traits of an Explorer, however. He presents a formal face with the .Gears studio, complete with email address and copyright notice. Put simply, Explorers are “practicing” to become successful app developers (either as contractors or with own apps): their main motivation is learning how to become professionals and they define success by knowledge gained as well as having a lot of fun developing. Some speculate that Nguyen might have tried to artificially boost the app using review bots, which would be more Explorer than Hobbyist behavior. (Nguyen himself denies having done any kind of promotion.) Whether Hobbyist or Explorer, Nguyen clearly wasn’t in it for the big money. Contrast that with Rovio, a clear Hunter company. Hunters are revenue driven: their goal is to build a successful business and make money from apps. The 50+ games that Rovio built before Angry Birds are a testament to their persistence in achieving that objective. Success is measured strictly in business terms: app revenues (in the case of Rovio enhanced with merchandising) and user reach. Hunters are professionals, out to build real, lasting companies, exactly what Rovio has achieved. The difference couldn’t be clearer. Understanding the motivations of developers is key to understanding the choices they make. This includes fundamental choices, like the one between lifestyle and business success that Dong Nguyen faced when his project became a huge success overnight. It also includes all the minor and major decisions that app development involves: business models, tools, platform selection, and much more. [tweetable]If you’re working with developers, gaining insights in their motivations is crucial[/tweetable]. — Christina & Stijn #angrybirds #dongnguyen #flappybird #rovio

We’re pleased to announce the publication of our new Developer Economics report: State of the Developer Nation Q1 2014. This, 6th edition of our ongoing Developer Economics series presents the latest trends in app development, based on our survey of over 7,000 developers. The report features in-depth analysis and insights into the key issues in the app economy, including platform prioritisation, going beyond tablets, trending revenue models, and making the right choices in developer tools. The report is available for free download here.

Welcome to the brand new Developer Economics report! Now in its fourth year and 6th edition, the latest Developer Economics survey reached over 7,000+ developers across 127 countries, setting new standards in developer research. Get your free copy here and read about the movers and shakers in the app economy. Dive deep into our rich dataset and discover how developers select and prioritise platforms, which developer tools they use and how their choices translate to revenues. As always, we have a lot more data available so get in touch (moredata@visionmobile.com) to get the data you need if you can’t find it in the report. The mobile Developer Mindshare The latest Developer Economics research shows that 84% of mobile developers are now developing for Android or iOS (or both), the two clear winners in the developer mindshare race. While Android amasses hundreds of millions of new users every year, sales of iDevices are still rising, attracting developers that are more interested in revenues rather than reach. HTML5 continues to play an important role in mobile development, providing diverse development paths for those developers that want to extend their web skills or web assets onto mobile. [tweetable]37% of developers rely on HTML5 for developing mobile websites and web apps[/tweetable], but more developers use HTML5 to target native platforms via hybrid apps or converted or translated HTML5 code. Microsoft remains the outsider in the ecosystem battle but has gained some ground in the past few months owing to rising sales of Lumia handsets. Windows Phone still faces a long and thorny road in its quest for mobile mindshare. Meanwhile [tweetable]Windows 8 remained stable at 21% Mobile Developer Mindshare[/tweetable] – the Q4 uplift in Surface sales is likely, however, to generate some developer interest that could push Windows 8 ahead. Getting your priorities right Developer Mindshare tells just one side of the story. In a multi-platform race, mindshare is nice to have but what matters most is getting developers to prioritise your platform against the others. This means more, better-quality apps and faster updates, keeping users happy. [tweetable]Android is now the priority platform for 37% of developers, with iOS at 32%[/tweetable]. But there are large variations in developers’ priorities: iOS is still the priority platform in North America and Western Europe, with Android claiming pole position in most of the other regions. There are also significant differences across developer segments: [tweetable]Android is very popular among hobbyist developers who may find the start-up costs somewhat lower[/tweetable], but iOS is preferred by Hunters, who target app-store revenue and Guns-for-Hire, who target development contracts. HTML5 is prioritised by 14% of developers, although a large number of these developers target Android or iOS via hybrid apps, rather than building true cross-platform apps. With 83% of developers prioritising Android, iOS or HTML5, the other platforms face a mighty challenge: if they are to become key players in mobile, they need to convince iOS or Android developers to switch their priorities. But looking at the revenue distribution for developers across platforms, it becomes clear that that is not a compelling proposition for the majority of developers. Revenues We’ve often argued that revenues are not the most important factor for all developers. But at the end of the day, you need to make money, whether that is via app stores, advertising, e-Commerce or any other way you can think of (selling t-shirts to your users or accepting bitcoin donations). We calculated median revenues to demonstrate the revenue disparity across platforms. The revenues shown in the graph below are the revenues that developers can realistically expect to earn per app per month. This graph is a picture saying a thousand words and reveals why more than half of the developer population are still investing in a platform that has less than a third of the user reach of Android. There’s a lot more information on revenues and revenue distribution across platforms in the report, and a lot more graphs and data points that you need to know about if you’re in the app business. We don’t want to spoil the fun so go ahead and download your copy of the report and tell us what you think. If you don’t find the information you need, then do get in touch at moredata@visionmobile.com to see if we can help. Follow me on twitter @PappasAndreas #ios #html5 #mobiledeveloper #windows8 #Android #apprevenues

In our June 2013 paper “The M2M Ecosystem Recipe” we argued that the Internet of Things is ready for a broad developer ecosystem. We may have finally found a promising candidate in an unexpected corner of the world (or perhaps not): China. Stijn Schuermans investigates how the open hardware platform alliance of Baidu and JingDong stacks up against our 3 control point model. Is there reason to be bullish on this initiative? The Internet of Things is ready for a broad developer ecosystem. That was the key message of our June 2013 paper “The M2M Ecosystem Recipe”. Since then, we’ve been on the lookout for an IoT platform that covers all three crucial ingredients that are necessary for the ecosystem to take off: service creation, service distribution and service consumption. We may have finally found one, and in an unexpected corner of the world (or perhaps not): China. Two Chinese internet giants are reported to cooperate on an open hardware platform. The first partner is Baidu, China’s answer to Google. The other player is JingDong (JD.com, formerly known as 360Buy.com), a major e-commerce player in China. Baidu and Jingdong will work together to create a technology platform for IoT. They will also leverage their expertise to provide distribution channels, marketing resources, and data to hardware developers through the open platform. Furthermore, the platform will serve as an incubator for smart hardware products with “Baidu Inside” and “JD+” branding. Let’s see how the announcement stacks up against our three control point model. Is there reason to be bullish on this initiative? Service Creation The announcement mentions the open hardware platform, cloud storage, a substantial set of functional libraries like video, image processing, security and location based services, as well as technical and product assistance and data. The alliance can draw on two sources of expertise: the partner’s substantial in-house knowledge of internet technologies, and the manufacturing know-how present in China above all other countries. There is little doubt that our protagonists can cover the technical side of an IoT platform. The other key aspect of service creation is building an active developer community that can provide support to its members and share expertise. Also here the alliance can draw from successful local examples like eoeandroid.com, an Android developer community that counts its members in hundreds of thousands. It has been done in China before. As we know, getting the technology right is the easy part. What about the business side of the equation? Service Distribution Service Distribution is about connecting developers to users, enabling choice for users and an accessible market for developers. JingDong’s e-commerce platform puts the initiative in pole position in this respect. To developers, it provides a significant existing user base to promote hardware products to, as well as monetization tools. Users already come to JingDong for the large variety of products that can be found there. JingDong also has the expertise to handle physical distribution and shipping – a notoriously difficult part of IoT to get right. Service Consumption What remains is the nasty discoverability problem. Once again, a search engine and a retailer seem a match made in heaven to provide the necessary assistance to developers and users alike. Baidu promises to launch a “Baidu Inside” website to showcase products released by open platform partners. Jingdong will leverage its marketing resources and distribution channels to assist platform partners, as well as establish new product categories on its e-commerce website, such as “Trial Product” and “New and Exciting Product”. The “Baidu Inside” and “JD+” labels are an excellent opportunity to do quality gatekeeping. Both companies’ background in the internet business should give them ample expertise in personalizing the discovery process. Meanwhile, in the West… We are currently tracking 40+ Internet of Things and M2M platforms. While about half of them have a hardware component, the focus is overwhelmingly on cloud services. While this tendency to focus on the Western strength – software – is natural, shipping hardware products is a lot tougher than getting the data streams flowing. Western initiatives have arisen to help bridge the gap between software developers and hardware experts (we’ve listed some examples in the figure above). None of them, however, have the advantage of being so close to the hearth of manufacturing (China) and of being backed by two major internet ecosystem companies. Are you still comfortable, Western IoT platforms? – Stijn (@stijnschuermans) #connecteddevices #iot

Another excellent move by Google: Offload Motorola Mobile Devices to Lenovo, while keeping the patents to themselves. Skimming through the news this morning, I found there is apparently a lot of confusion about the planned sale of Motorola by Google. From decrying a huge loss by Google by such infotainment sites like Wired and Slate, to seeing Google giving up on copying vertical integration of Apple (hardware + software + services), like Stratechery by Ben Thomson. Let’s look at things from a broader perspective. The acquisition of Motorola was necessary to protect Android, after Apple, Microsoft and BlackBerry outbid Google for Nortel patents. The Apple-Microsoft-BlackBerry trio made it very clear that they intend to put a drag on then-fledging Android ecosystem and extort royalties from Android OEMs. The cost of doing nothing was huge for Google – just think how much more nasty the patent wars may have turned out for Android if the acquisition hadn’t taken place. Any “profit and loss” analysis of the Motorola deal must account for the opportunity cost associated with Motorola patents. Android is, was and will be critically important for Google’s core online ad business, as I will explain in a bit. The argument of Google giving up on the idea of vertical integration and going horizontal doesn’t hold water either. [tweetable]Google always was and will remain a vertically integrated company[/tweetable]. It’s just that Google is integrated where it matters for its core business of online advertising. Real-time processing of huge data sets is the key for deciding in milliseconds which ad to show to which user, while maximizing the revenue opportunity from multiple bidding advertisers. To excel and outperform competition Google builds and runs a proprietary big data infrastructure, which comprises of proprietary server hardware, custom-built system software (distributed databases, networking, data processing and more) and even uniquely designed data centers. There is nothing open or horizontal about Google’s core business. On the contrary, Google is very closed and vertically integrated, where it matters for the core business. But there is more. As any online advertising business, to excel Google needs: Remove any barriers between eyeballs and Google ads, Expand the footprint of ad inventory by offering new services beyond search, and, last but not least, Collect and mine maximum amounts of user data to improve targeting of their ads on both mobile and PC (where most ad revenues are still being made). Android is critically important for boosting Google’s core business in all of these 3 pillars of online advertising, as we wrote in our earlier note “The Naked Android”. Smartphones, tablets and PC are mere complements to Google’s core business. Cheaper and more capable smartphones, tablets and PC mean better business for Google. It’s no different from car makers that will have their business boosted by cheaper fuel available at gas stations on every corner. The Android ecosystem was purposefully designed to drive commoditisation of smartphones and tablets by reducing barriers to entry for low-cost OEM and ensuring “race to the bottom” in a horizontal value-chain configuration. (Chrome OS does the same for the PC.) To sum up, Google is vertically integrated around its core business and at the same time drives shifts to horizontal configuration of the value chain around the complements. “What about Nexus?” some will ask. I hope that by now we all understand that Nexus devices are not about making profits from hardware. Google Nexus is about driving the ecosystem forward (push capabilities up and price down) and, not less important, collect usage data. Being an extremely data-driven company (remember the famous story about testing 41 shades of blue?), how would Google know how people use Android devices and where Android needs to go next, without getting usage data from heavily instrumented Nexus devices? “But, what about the recent acquisition of Nest?” others will insist. It’s a fascinating discussion on the future of Internet of Things, but in short, both Nest and Google are companies creating value by making sense of data. Thermostats, smoke detectors, or connected cars for that matter, are just means to an end for solving the riddle. Both the acquisition and the pending sale of Motorola Mobile Devices to Lenovo makes perfect sense to me. Motorola patents were meant to protect the Android ecosystem from patent extortion (how effective they are is another discussion). The sale divests Google from unwanted device business that came as a cost of acquiring Motorola. And finally, Motorola in the hands of a very aggressive Lenovo strengthens competition to Samsung, which has disproportionately high power in an Android ecosystem designed to commoditize handset business. #acquisition #nest #nexus #sale #google #motorola

Operators have been trying for ages to launch mobile banking schemes hoping to create new revenue opportunities for themselves. T-Mobile’s latest attempt, dubbed Mobile Money, offers a refreshing new perspective on the space. Drawing on the playbook of innovators like Google and Amazon, T-Mobile uses two strategies that are indeed quite un-carrier-like. Analyst Stijn Schuermans explains. Many people that follow what’s going on in mobile might have shrugged their shoulders at T-Mobile’s announcement of the new Mobile Money service. “Un-carrier brings its revolution to personal finance; frees consumers from Outrageous fees!”, titled the press release. An enjoyable bit of drama, but nothing new, right? After all, operators have been trying for ages to launch mobile payment and banking schemes. Remember all the NFC buzz of the last few years? Direct competitor Sprint launched its Mobile Wallet (a very similar service) back in May 2013, leading Forbes to label T-Mobile as “The Late Adopter That Picks Up The Innovation Kudos”. But there may be more to T-Mobile’s initiative than meets the eye. [tweetable]T-Mobile is using two strategies with Mobile Money that are very un-carrier-like[/tweetable], indeed. Quite refreshing, actually. Playing in two markets: kill the one, win the other The press release headline sets the tone: this is a direct attack on banks and other payment service providers, as T-Mobile will not charge fees for the (basic) use of its checking account-like[1] service. (The service enables customers to deposit money, receive wages and make payments either with a mobile phone or a debit card. Here’s a brief description of how it works.) That T-Mobile targets the so-called unbanked has been widely reported in the media. The unbanked are a large group: in some states like Mississippi they number as high as 15% of the adult population. Presumably the value proposition is also attractive to a whole bunch of people who resent paying for what in an internet world seems a trivial service. If any service has a good chance of becoming widely popular with these audiences, it would be a free one from a major trusted brand like T-Mobile. The free aspect is important, as it will put pressure on the existing banking players that charge fees, including fellow operator Sprint. It will be difficult for them to forgo those revenues and compete, tipping the scale even more in favor of T-Mobile’s offering. Because T-Mobile is not interested in directly extracting money, it could kill the checkings account market. If the service doesn’t provide a revenue stream, then how does it benefit T-Mobile? The mobile industry has seen a textbook example of how this might work: Android. Google provides the Android operating system for free. In fact, Google doesn’t get much revenue at all directly through Android. It captures a mere $3B of the ecosystem’s total value with ads, representing just a small percentage of both the ecosystem and Google’s income statement. However, Android allowed Google to win the online advertising market and defend its core business. No handset maker or operator can push Google’s services off the mobile device now. In Android’s case, the hypothesis that a free product will upturn the market became a reality. Incumbents like Symbian were forced out of existence, handset making was commoditized to the extent that there are now 255 CES exhibitors whose name starts with “Shenzhen” (thanks ITG’s Gary Cohen for pointing that out) and the total amount of users of smartphone platforms exploded. The big losers were incumbent handset makers like Nokia, Motorola and Blackberry, who saw literally all of their profits disappear. Similarly, [tweetable]T-Mobile will subsidize banking services business (forgo profits) to boost the core telco business[/tweetable]. By not seeing the bank service as a revenue source, it can use it as a powerful tool to attract and retain customers. You do not have to be a T-Mobile customer to use the service, “but we save the best benefits for our customers,” the company said according to PCMag. “There are other ways you can get your monthly fees waived, but the easiest way is to be a T-Mobile customer.” If you want to learn more about how Google, Amazon and others have used the same strategy to win in mobile, check out our post on asymmetric business models. Leveraging the customer relationship Which brings us to the second smart strategy from T-Mobile. [tweetable]Finally a carrier that leverages its customer relationship and its retail assets to the fullest[/tweetable]! In our experience, telcos tend to be very pessimistic about the customer assets they have. On the one side, there is a belief that the customer relationship (including paying money i.e. billing, ironically) is irreversibly being eroded by over-the-top players: Apple, Google, social apps, etc. On the other side, the ubiquitous operator retail stores are seen as costs and as an unwieldy jumble of franchises that are near impossible to consistently manage. T-Mobile will have none of that depressed talk! [tweetable]T-Mobile’s retail outlets will become your banking branches, its employees your tellers[/tweetable]. Instead of considering retail as an unfortunate but necessary expense, the company leverages its market presence to provide more services to its existing customers, deepening the relationship with them in the process. It does so in a way that pure internet players like Google or Facebook will have a hard time matching. If nothing else, people will now have more reasons to walk into a T-Mobile store, be exposed to its offers and talk to a T-Mobile salesperson. At VisionMobile, we have long said that the distribution business including physical and digital retail presence holds a huge untapped potential. Read more in our post about the Modular Telco. Mobile Money is also fully consistent with T-Mobile’s branding as a challenger that fights to reduce costs for consumers and with the price-sensitive customer’s it targets. T-Mobile launched a whole range of initiatives in 2013 that put pressure on the pricing of its direct competitors. It focuses on no-contract offerings. As the good folks at PCMag explain (video): “If you look at T-Mobile’s customer base, especially MetroPCS’s customer base, these are a lot of younger people, a lot people who may not have access to mainstream financial services, these are a lot of the unbanked people. T-Mobile is serving this existing customer base with a new, relevant service.” As Forbes mentioned, T-Mobile is a latecomer in the payments market, and it will face many competitors. By leveraging its customer base, retail presence and brand, it is one step ahead of other large contenders, and miles ahead of startups like Simple that aim at disrupting the space with similar free banking services. Lessons for telcos The lessons for telcos are clear. You can use asymmetric business models to boost your own core business by creating huge value in another market. The other market doesn’t have to be a revenue generator: foregoing profits will gain you an insurmountable competitive advantage in that business. The resulting traction can be used to boost the core telco business through customer acquisition and retention. Kudos for T-Mobile for demonstrating that operators can replicate the strategies that internet companies like Google or Amazon have been using to win in mobile. You do have valuable assets and a customer base that can be leveraged to create new services. Think of the distribution layer in the telco business as a profit center, not just a necessary expense. I think T-Mobile’s Mobile Money is one of the most refreshing mobile banking initiatives to come out of telcos since the wildly successful M-PESA. What do you think? – Stijn (@stijnschuermans) [1]: Mobile Money isn’t technically a checking account, and it certainly doesn’t provide interest-earning services as banks would. From the perspective of what you do with the service, however, it’s close enough not to matter. #Android #mobilebanking #mobilemoney #tmobile

With 2013 drawing to a close, we’d like to present you with the top articles from our blog for this past year – and wish you a happy and productive 2014! So, without further ado, here are the top 5 VisionMobile articles for 2013 – enjoy! 5. Developer Economics: App market forecasts 2013-2016 by Andreas Pappas 4. The Naked Android by Stijn Schuermans 3. Which apps make more money? by Andreas Pappas 2. The Art of One-line Pitching: A Study of AngelList by Chris Eleftheriadis 1. Web Sites vs. Web Apps: What the experts think by Ciprian Borodescu [vm_form_download link_text=” EXTRA: How can HTML5 compete with Native? – Research report ” product_id=’4381′] Last, but not least, we’d like to present you with one of the most interesting reports we’ve published this year, taking an in-depth look at HTML5 development, uncovering the gaps in developer tools, showcasing the four different implementation paths for the platform, and taking a data-driven approach to the HTML5 vs Native debate. There is a lot of discussion around HTML5 vs. Native, and it’s usually polarized. But most people express opinion, rather than facts. In this report,  we answer some of the key questions with hard data. Anything we missed? Which was your favourite VisionMobile article? – Matos #Android #html5 #ios #mobiletrends

The survival of large enterprises calls for innovation. It requires continually creating a new set of businesses to sustain growth and profit. Guest author Avner Mor identifies five crucial ingredients that senior management should use to succeed in their innovation program recipe. Innovation exists in the form of ideas, innovation leaders and teams. Everyone talks innovation. Yet we see more and more opportunities missed by large enterprises to leverage their enormous assets – technologies, brands, relationships and routes-to-market – within their internal innovation programs. Innovation programs are constantly being established and funded, but months pass and success is often not materialized. I have seen quite a few testaments to this through my years at several global corporates and startups. I believe it possible for these large enterprises to transform innovations into sustainable future businesses. But only if senior management enables the right conditions for the innovation leaders, the expert starters, to get off the ground and to prosper with their program. Large enterprises are good in producing more of the same, or at best, continually improving current products and processes. Leapfrog innovation calls for a fundamentally different structure because the existing corporate culture and practices are destructive for internal innovation programs. Throughout my working experience in the past 12 years, I have singled out five crucial ingredients that senior management should use to succeed in their innovation program recipe. 1- Free the corporate clock [tweetable]Enterprises have their own corporate clock for tracking and measuring progress[/tweetable]. The corporate clock conducts periodical reviews of operations and financial KPIs (key performance Indicators) to evaluate success. We are all familiar with the concepts of strategic planning, market research processes, quarterly forecasts, roadmap and the infamous 3-year business plan. The innovation program leader is buried under the corporate clock: meetings, worksheets and slides upon slides. She is constantly facing operational managers who are excellent at KPIs measurement but do not necessarily have the know-how on the relevant market; neither do they have the ‘innovation spark’. Furthermore, the innovation program doesn’t know yet how its product will look or who it’s the target customer is. So how can such a program provide a breakdown of its future products sales, margins and profits for the next 3 years? Strategic planning, an 18-month roadmap and market research analysis will not – and cannot support – an internal innovation program. If the market research already exists, the opportunity is already lost. Following the corporate clock, common practice analytical methods, and KPIs to manage innovation will destroy the business, not revive it. It is true that process and management are musts for the internal innovation program. For that, the senior management should design new methodologies, to release the innovation program leader from the corporate clock and allow her to iteratively experiment, seek customer input and adjust the product and go-to-market route at every step. As Mason Cooley said, “to be fulfilled, a prophecy needs lots of flexibility” Eric Reis in the “The Lean Startup” captures it concisely – “I believe a company’s only sustainable path to long term economic growth is to build an ‘innovation factory’ that uses Lean startup techniques to create disruptive innovations on a continuous basis…breaking down a business plan into its components parts and testing each part empirically.” 2- Reward making mistakes and risk taking Paving the way for the internal innovation to become a commercial product and a sustainable business is all about small steps and experiments. Each experiment provides a new insight on what is the right way to go to market or what are the most valuable product features. Each experiment faces uncertainty and reflects risk. The correlation between taking risks, making mistakes and achieving success is obvious. At the same time, another correlation exists: when you take risks, you expose yourself to unforeseen opportunities to get to non-incremental results. The only people not making mistakes are ones playing their game without taking any risks – and without making progress. Large enterprises are intolerant of mistakes. A manager is subject to be burned out if she presents an idea, a strategy, or a direction and then changes it. The change, even if can be is clearly justified, stands out as a failure. The innovation program leader is stained with a failure to plan or a failure to deliver. If the enterprise cannot accommodate, and or even reward failure, then in the long run, it cannot succeed in building sustainable a business out of innovation programs. 3- Unlock access to the enterprise assets On the surface, having an innovation program within the enterprise can outcompete most start-ups. The innovation program can tap into years of know-how and enterprise assets, including technologies, brands, relationships and routes-to-market. This aggregate Intellectual Property is a gold mine for the corporate innovation program. These already existing elements are invaluable. They can provide a competitive edge in product value, product cost and in time to market. At the same time, established enterprise assets are owned by other divisional units – units and managers that have goals, budgets, target revenues and profits. Units and managers that are struggling to achieve their quarterly KPIs. Will they allow an unknown, zero revenue intuitive to mess with their goals? Well, good luck with that. How do you get access to assets controlled by divisional units? The answer your ‘re likely to get is: “sorry, it’s not within our strategy”; “are you trying to compete with us?”; “give us 5 headcounts and $500K to adapt the interfaces”; “we will consider it on our roadmap planning for the next 18 months” or “you can get it, but this is the ‘transfer price’ for using our product”. Summing it all up: good luck. The result will probably be, either that the enterprise innovation program waives off using the already proven company asset or that it goes to buy it from external companies (sometimes it is easier to engage out of the family). Either way, the innovation program losses the potential edge of either valuable, low-cost product or time to market. [tweetable]Enterprise is not a ‘free market’. There is no place for Adam Smith’s “invisible hand”[/tweetable]. A self-regulating behavior is wrong here. The senior management plays an important role: finding the balance between the ongoing mainstream businesses and the innovation programs. At a minimum, the senior management should: Guide the divisions to produce their functionality together with a simple service that any other group in the company could reach. In Jeff Bezos, Amazon, CEO famous memo (https://plus.google.com/+RipRowan/posts/eVeouesvaVX): “All teams will henceforth expose their data and functionality through service interfaces; Teams must communicate with each other through these interfaces; Anyone who doesn’t do this will be fired.” Guide the divisions to hide all internal transfer prices and remove internal margins on their assets’ internal usage. Thus allowing the innovation program to introduce a market-competitive price for its product. Define certain innovation programs as corporate priorities and embed them within the KPIs of the annual unit managers. Closely manage an innovation “speed boat” process that circumvents the company roadmap process 4- Clear the road to customers [tweetable]Any innovation program must strive to get its first customers[/tweetable]. The value of the first customers is unparalleled: product feedback, business model validation and your first revenue. Yet, most often the enterprise innovation program cannot reach the enterprise’s existing customers. You see, customers are owned by the enterprise sales force. The sales force is struggling to achieve its own goals for numbers of new customers, deals and actual revenue. Their focus is on short-term results. Why should they allow access to their customers to an a tiny new division with zero revenues? Again, as an innovation manager you‘re on your own. Here too, when the innovation programs approach the sales force to get access to their customers, the answer typically is: “My quota is $100 million this year, the most you would accomplish for me will be a few thousand”; “I am not going to risk the relationship with my customer for an unknown, low-quality product”; “you are competing with me on the same deal” or “wait for 12 months until I get that big deal”. Again, the senior management plays a crucial role here. Regulation is required to make innovation programs a success. If the sales force is acting upon its quota, then that quota should include the innovation program’s KPIs for revenue and new customers. The sales and the business development people should be aware that their annual commission is dependent, also, on the low numbers of the innovation programs. 5- Support and protect from the inside In the 1970s, Henry Kissinger, the US Secretary of State, made this observation on Israeli political culture “Israel has no foreign policy, only domestic policy”. Isn’t this just like corporate life? How many times do we make decisions and take actions due to internal sensitivities? Managers in an enterprise are busy making alliances; striving for consensus and trying hard to please their managers, their peers and the functional units – whether it’s HR, financial, legal or procurement. Haven’t we all seen misuse of power within an organization for the pursuit of agendas and self-interest without regard to their effect on the organization’s efforts to achieve its goals? Managers learn to ease into situations with caution, picking battles wisely, and adjusting their approach if things are not working. Working this way is inevitable, and at times, exhausting. Extreme effort must be made in order to simply interact. Asking this from the innovation program leader means that her success depends on to her ability to navigate the company corporate policies, personnel and processes to get things done. This means pushing the program to uncompetitive compromises or even jeopardizing its success to begin with. The senior management cannot help here with any guidelines or regulations. I would recommend matching the innovation program leader with a sponsor in the company, an executive who can navigate the corporate culture and create the conditions necessary to protect the innovation program leaders. A sponsor that can provide the innovation program with a seal of ‘corporate importance’,.establish an ‘island of freedom’ and alert before conflicts arise. You also need to take special care in nominating the leader of the innovation program. She needs to show personal resilience and perseverance when standing in front of internal power struggles – gossip, manipulation, or informal information sharing. She should be proactive in expressing her views and leading to a solution; show conviction and have clear influence on her internal/external peers. She should be assertive and stand for her opinion in the face of disagreement and confrontation. Clearly, not every manager has these qualities. – Avner #businessmodels #innovation

We know many of you have been eagerly expecting the announcement of the winners to the October-November 2013 Developer Economics survey. So – here they are: AR Drone – Christopher W. (@cwilkinson1998) GoPro Camera – Xu J., China Lego Mindstorm Robot – Magnus Söderberg, Sweden (@MagnusTriolith) iPhone 5c – Edy Braun, Canada (@doctorbraun) Samsung Galaxy S4 – Bryan C, USA Lumia 925 – Alex G., USA Lumia 925 – Alfonso M. $500 in-app coupon by Mob4Hire – Varun N, India (@varunnarula) A big thank you to all participants and congrats to the winners! And don’t forget – the results of the survey will be published as a free report in Jan 2014! Subscribe to our updates to receive word!

How do developers perceive different platforms and how is their platform choice affected by the type of apps they developed or the way they define success? Andreas Pappas looks into the data from VisionMobile’s Developer Economics survey in Q3 2013 to shed some light on these questions. Not long ago, the choice of a mobile platform, i.e. which mobile platform to support was a key question for developers. That question has more or less been addressed now: iOS and Android accounted for 94% of smartphone sales in Q3 2013 and there is little doubt that they will continue to dominate the market in the years to come. For organisations that require massive scale, combined with all the perks of a mobile ecosystem (monetisation, distribution, platform services), iOS and Android are the platforms of choice with a combined Mobile Developer Mindshare of over 85% based on the last Developer Economics survey in Q3 2013. Despite the dominance of these two platforms, our latest Developer Economics report showed that the majority of organisations utilise more than one platform at the same time, while [tweetable]50% of organisations utilise three or more platforms at the same time[/tweetable]. This strategy that makes perfect sense for pro developers and organisations where scale matters. So how should your organisation prioritise across all platforms you publish on? For the majority of organisations involved in app development this is a key question, as resources are scarce and, quite often, a choice must be made. For example, which platform to support first with a new game release or which platform to invest more time on when supporting an existing app? Ideally all supported platforms should be allocated the level of resources required in order to deliver the best possible product on each platform, but in practice this is rarely the case, even for the largest of organisations. There are of course, many factors to consider, such as costs, capabilities, resources, target market, revenue potential etc. The common perception regarding Android, iOS and HTML5 would probably look like this: Android is better for reaching more users iOS is better if you want to make more money HTML5 is better if you want to go cross-platform or have existing web assets We’ll now examine how developers in our survey prioritise the three big platforms (Android, iOS, HTML5) based on other selections they make or the type of business they run. We’ll see how these choices correlate with their platform priorities and whether we can shed some light on common perceptions held for each platform, as stated above. iOS is prioritised by high-grossing organisations and developers Looking at how priorities vary by respondents’ revenues we see that respondents in the lowest ranges, i.e. those that make no money or earn less than $1,000 per month tend to prioritise Android. From $1,000 and above iOS becomes the priority platform, with the share of respondents prioritising it increasing with revenue. However, the picture becomes more balanced once revenues exceed $5M, with iOS, Android and HTML5 being almost equally prioritised. While we cannot conclude that iOS brings more revenue, there is, undoubtedly a strong correlation between the amount of revenue generated and use of iOS as a priority platform. The sharp increase in HTML5 is likely associated with the use of HTML5 among large enterprises that mobilise existing HTML assets. Developers in the lower revenue brackets tend to prioritise Android more than high-earners do. This is likely associated with lower barriers to entry for Android developers and the use of Android among Hobbyists. What does Success mean for developers? We asked respondents to indicate how they measure success in app development, i.e. whether they measure success by money generated, users reached, cost savings etc. Looking at how priorities vary across different success metrics, we find that [tweetable]Android is the main platform of choice for developers that do not care about success[/tweetable] or value the level of knowledge acquired through app development, i.e. two metrics that have little to do with the business side of app development. This indicates that Android is much more popular as (but not limited to) an entry-level platform on which developers experiment or learn. Prioritisation of HTML5 increases considerably among respondents valuing cost reduction or efficiency gains. This segment most likely consists of large organisations that view HTML5 as a cost effective way to mobile existing business processes and assets, such as enterprises. [tweetable]iOS priority rises among developers that value direct revenues or brand recognition[/tweetable]. The latter factor (brand recognition) is particularly important as it indicates that iOS is the platform of choice for brands, an important value-adding element for mobile ecosystems since brands contribute to user retention and engagement. How platform selection criteria relate to developers’ priority platform Looking at selection criteria vs platform priority we find that iOS is the main platform of choice for respondents that want discovery, targeted reach and monetisation, all of which are key challenges among mobile developers. Android, on the other hand, is preferred among developers that value open standards, porting and choice of development environment, i.e. factors that are associated with the technical, rather than the business side of app development. HTML5 peaks in terms of priority among developers that value open standards, ease of porting and speed & cost of development but drops when it comes to platform APIs, graphics capabilities and revenue potential, reflecting the gap between HTML5 and native application platforms. How do different types of developers select their primary platform? Android gets much more attention than iOS and HTML5 among developers that are involved in app development as part of a side project, i.e. those whose main occupation is not app development. The reverse is true among independent app developers, i.e. developers whose main occupation is app development and are primarily self-employed: [tweetable]indy app developers show a clear preference towards iOS[/tweetable]. It is clear that Android attracts more hobbyists as it is more accessible in terms of startup costs and effort. However, developers whose livelihood depends on app development tend to prefer iOS, a platform that is known to monetise better overall. For organisations outside the app development business that develop their own apps (i.e. verticals), HTML5 becomes a key contender, surpassing Android in terms of priority and being almost equal to iOS. For such organisations (e.g. banks, retailers) cross-screen and cross-platform is very important, making HTML5 a cost-effective option. Platform priority varies by app category There are small differences between iOS and Android when it comes to app categories. Developers that develop Music/Video, Utilities and Location services tend to show a preference towards Android. Across all other categories the differences are quite subtle, with the exception of Enterprise apps, where iOS has the upper hand. But what is really interesting in this category is the rise in HTML5 prioritisation, among verticals, a clear indicator of the importance of HTML5 when it comes to enterprises. So what does all this mean? Apart from the relative differences in priorities between platforms shown above, perhaps a more interesting indicator is how priority varies for each single platform, across these choices. There are clear messages that can be taken from such analysis. For example, HTML5 is clearly considered more valuable as a platform among large organisations and enterprises, as these organisations prioritise HTML5 a lot more than organisations that don’t fall in this category. Similarly, iOS is prioritised more by brands and developers who are mainly interested in generating revenues. So coming back to our original assumptions, let’s see whether these hold, i.e. whether developers share the same views. Android: does it help you reach more users? While the statement holds some truth, developers do not necessarily associate reach with platform market share. While Android has the largest market share in terms of device ownership, there are numerous factors that can limit the addressable market for developers: API & device fragmentation, demographics and user maturity, data connectivity etc. As a result, Android does not seem to be a clear preference by developers that are interested in reach. On the other hand it is preferred by hobbyist developers and those valuing open standards, reflecting relatively lower barriers to entry and openness compared to iOS. iOS: is it better when it comes to monetisation? While Android has been monopolising the consumer market, iOS still remains the platform of choice for developers that are interested in revenues, preferred by developers who generate over $1,000 in monthly app revenues. It also has an edge among game developers, offering a less fragmented API and device ecosystem and better monetisation opportunities via direct downloads. HTML5: is it better for cross-platform and enterprise applications? The priority of HTML5 invariably increases when enterprise development comes in play. HTML has long been used for web services in enterprises and is the platform of choice for extending such services across screens and devices. We’ve summarised the key points from this analysis in the table below. Note that these are indicative of market trends, i.e. they reflect developers’ choices and should not be seen as advantages or disadvantages of each platform. For example, there is no reason why enterprise apps cannot be deployed on Android (and they are) if a business case for doing so exists. Similarly, while iOS is usually associated with higher revenues, there are many high-grossing Android apps that far exceed average iOS revenues.Prioritised more by developers whoPrioritised less by developers whoAndroidgenerate no revenue don’t care about success value open standards support develop apps as a side project develop music / video appsgenerate revenues > $5M define success by cost reduction / efficiency gains value application discovery develop apps for verticals develop enterprise appsiOSgenerate revenue btwn $1M – $5M define success by brand recognition value revenue potential independent app developers develop gamesgenerate no revenue don’t care about success value open standards support develop apps as a side project develop maps / navigationHTML5generate revenue > $5M define success by cost reduction / efficiency gains value open standards support develop apps for verticals develop enterprise appsgenerate revenue btwn $1M – $5M don’t care about success value revenue potential are independent app developers develop games Tell us what you think. We’d love to hear from you, particularly if your experience contradicts our observations! – Andreas (@pappasandreas) #Android #html5 #ios #mobiledevelopment

HTML5 is perceived as a lower quality platform, mainly because of performance. This comes both as a result of survey data, as well as developer interviews. Yet, industry experts claim the problem is lack of tools. So what is the HTML5 really missing, performance or tools? VisionMobile’s Web Technology Lead, and author of our acclaimed “Can HTML5 compete with native?” research report, debates the performance vs. tools issue. In April 2013 VisionMobile asked mobile app developers what stops them from using HTML5. 46% answered “Performance issues”, followed by 37% who said “Lack of APIs” (sample size: 1,518 developers). We spoke to developers about their views on HTML5 performance. Apostolos Papadopoulos, author of 4sqwifi, a highly acclaimed public WiFi password app, noted “Quality and user experience is top priority for us. Therefore, we prefer going with a Native API”. It’s a common practice for developers to go native for better performance and user experience. But user experience, meaning following the behavioural conventions of the native platform, is a different story and HTML5 can’t help much. Developers can try to imitate but for a truly native UX they have to use Native SDKs; unless we are talking of Firefox OS or the long-awaited Tizen. Ciprian Borodesku, CEO of Web Crumbz, added “From a business standpoint, there’s a lot of education needed for the acceptance of HTML5. There’s a gap between what we developers can provide and what the clients think we can provide”. The perception of HTML5 being a less capable platform is also common amongst people who commission apps. Experts point to a tools gap As part of our How can HTML5 compete with Native? report, VisionMobile conducted 32 interviews with industry experts, from Miško Hevery (author of Angular.js) to Max Firtman (author of “Programming the Mobile Web & jQuery Mobile” published by O’reilly) and Peter-Paul Koch (author of Quirksmode). It came as a surprise when Robert Shilston, director of FT labs, champion of HTML5 apps, noted that “the biggest issue for HTML5 is the maturity of tools”. He emphasized not performance, but tools, as the key HTML5 gap. Ran Ben Aharon, head of front-end development of Everything.me, explained it in more colour: “Hearing Mark Zuckerberg denounce HTML5 made me angry at first, but then I looked at some data and realized that the main reason was not performance or APIs but the lack of memory management and debugging tools”. Even though developers identify performance as the #1 problem of HTML5, a number of experts claim the actual challenge is tools. There’s no contradiction here, performance and tools are related. How can you improve an app, if you can’t measure it? How can you fix a bug, if you can’t replicate it? HTML5 is like a car without a dashboard [tweetable]Tools are to HTML5 what a dashboard is to a car[/tweetable]. You can’t run at high speed without knowing how fast the engine runs or you might end up totalling the engine. Likewise, you can’t produce fast HTML5 apps if you don’t have quality debugging and profiling tools. With HTML5, coding and debugging are two separate processes. There is no self-contained IDE here. Developers code on the editor (e.g. vim or sublime) and debug on the browser, i.e. using Chrome developer tools. But debugging tools are difficult to master and they require a thorough knowledge of the underlying technology, e.g. what is a reflow, how does the garbage collector work, how is a memory leak created. Louis Stowasser, author of CraftyJS noted “it would be great to have something like YSlow for game developers”. Why pick YSlow and not Chrome developer tools? Well, because the former offers insights on what to fix rather than data requiring interpretation. Moreover, each browser has its own set of debugging tools. As a result, [tweetable]developers need to become familiar with at least 4 different environments to match the most popular browsers[/tweetable] of the market. And though it’s generally true that these tools look alike, it’s the little bits and pieces that make the difference. Patrick H. Lauke, former product manager at Opera Software, highlighted the fragmentation of the browser debugging tools by commenting on a W3C public discussion board about our research: “Opera Dragonfly was the first to offer remote debugging and proposed a unified protocol for debugging. Sadly, other browsers showed very little interest and instead went their own separate ways to build something similar but different”. This also touches on the browser politics issue, due to be the subject of another blog post. Better tools are needed HTML5, as far as performance is concerned, is adequate for most use cases. And tools like famo.us and Goo Engine provide a testament. The question is no longer *whether* HTML5 can produce quality apps, but *how* easy it is to create quality web apps. What the HTML5 platform desperately needs is easy-to-use debugging and profiling tools. With the right tools we could see external debugging tools hooking to multiple browsers and even apps able to profile themselves via standard debug APIs. Web development attracts millions of developers who are new to software engineering because of the learning curve; it’s very easy to get started. The complexity gap between building basic sites and single page web apps (SPAs) is too big of a leap for many to jump over. Improved tool usability is one of the best ways to bridge that gap while also increasing productivity for those already building complex web apps. What other improvements do you think are needed in HTML5? Download our research and participate in the discussion. #tools #famous #html5 #profiling #opensource #debugging #api #gooengine #performance

Why outcome-based segmentation should be the cornerstone of developer outreach strategies. VisionMobile’s Data and Operations Manager, Christina Voskoglou, explains why everyone running a developer program should focus on outcome-based segmentation and not technologies, demographics and platforms. 00 Shooting the duck Two statisticians were hunting for ducks by a creek. Spotting one taking off behind a bush both hunters fired simultaneously: The first man’s shot fell 1 meter too low while his friend’s shot flew 1 meter too high. Thrilled, they dropped their rifles and started congratulating each other, hopping about, happily chanting: “We got it on average, we got it on average!”. The duck, even happier than the statisticians, had of course in the meanwhile flown away to safety. This is a lesson on how working with averages is a sure-fire strategy to miss your targets. [tweetable]There is no average person. And there’s no average developer[/tweetable]. 01 “Are you talkin’ to me?” There are mobile platform companies like Microsoft and Apple. There are ad networks like AdMob and Inneractive. There are back-end tools companies like Parse and StackMob. There are cross platform tools like Appcelerator and PhoneGap. All of them are serving developers. All of them are competing for developer attention with marketing dollars. Most of them are talking to the Average Developer. Consumer segmentation has been a popular strategy since airlines figured out how to sell an airplane seat in 100 different ways to 100 different people. Segmenting a population to better understand it has long since been proven to be doing a better job at getting those campaign response rates up than simply addressing the whole population with an ‘on-average’ interesting message. Now companies from Amazon to ZTE are figuring out how to grab developer attention through segmentation. The bigger and more heterogeneous a population is, the more effective segment-based outreach campaigns are. And one could hardly wish for a faster-growing and more diverse population than mobile developers across geographies and platforms. Question is, how do you segment developers effectively to make sure you’re talking to the right people with the right message? The classic approach practiced by platform vendors is to segment based on demographics, skills or technology considerations such as platforms – e.g. Android vs. iOS developers. Trouble is, technology used is a choice that may have been made by different developers for different reasons. For example, a developer may have chosen Android to take advantage of its wide customer base, while others because of its lower cost of development vs. iOS. Simply grouping together people who made the same choice doesn’t necessarily result in a homogeneous group that behaves in a coherent way – choices made by Android developers who care more about reach will differ to choices made by Android developers who want to learn at low cost. If we fail to understand the drivers behind these choices we won’t be able to understand how and why choices change over time, for example why developers would switch from native to HTML5 or switch their main platform from Android to Windows Phone. Nor will we be able to see how to convince developers to switch from an existing choice to a new one – e.g. from a tool they use today to a new one offered – or why and how developers decide to commit resources and take risks in the app economy. [tweetable]Effective developer segmentation can only be based on what drives developers[/tweetable], what they’re trying to achieve in the app economy. In our Developer Segmentation report we adopted an outcome-based approach to segmentation, backed by hard data from a survey of 6,000+ app developers. The research resulted in eight distinct behavioural segments: The Hobbyists, the Explorers, the Hunters, the Guns for Hire, the Product Extenders, the Digital Content Managers, the Gold Seekers and the Enterprise IT. By focusing on the motivations that drive developers to adopt a new technology our model provides actionable insights on which developer groups to approach and how. 03 A success story Let’s consider a common scenario of an outreach program pivoted around supporting developers to succeed in the app economy. So, how do developers succeed in the app economy – how do they perceive success? You can simply assume that most people care about revenues – for example Microsoft and Nokia’s AppCampus program is pivoted on rewarding developers with money for a limited app exclusivity. However, our research proves that [tweetable]revenue-based success is only half the truth[/tweetable]: We found that just above 50% of all developers give success a definition that involves direct revenues. This implies that if you addressed all developers out there with a revenues-oriented message, about half your marketing budget would be predictably wasted. What if you segmented developers based on the platforms they use – Android vs. iOS vs. Windows Phone et-al? The next chart presents the popularity of four success metrics (out of the six explored in our research in total) within each platform – Android, BlackBerry 10, HTML5 mobile, Windows Phone and iOS. We have normalised the results over the developers’ desired outcomes in the app economy to remove bias and isolate the effect that platform choice alone has on success definitions. Differences between platform-defined segments are obviously very small to be actionable. For example, there is no great difference in what platform segments think about reach as a success metric – around 60% of all segments alike say reach is important. Platform-defined segments obviously fail to define distinct clusters of developers that perceive success in different ways. If you’ve used platform-based segmentation to understand your developers, you’ve been wasting your money. Segmenting developers based on app categories leads to similarly un-actionable results. For example take four category-based developer segments – those developing games, apps, games and apps and enterprise apps. How do developers differ based on their success metrics? Do game developers vs. app developers measure success in different ways? Again, technology-based segmentation fails to understand differences among developers with respect to success perceptions: All four app-category segments give approximately the same weight to knowledge gained (47%), while exactly the same percentage within each segment (6%) doesn’t care about success at all. ‘Games only’ developers seem to differentiate themselves from the other three segments with respect to reach and slightly with respect to direct revenues, however the resulting differences are not intuitive: Why would game developers care less about reach and more about revenues than other segments? 04 What are you trying to achieve? In our Developer Segmentation research, we segment developers in terms of what developers are trying to achieve. This is based on the Jobs-To-Be-Done segmentation methodology popularised by Harvard professor Clay Christensen. The results are not just refreshingly clear. They are refreshingly actionable. Consider the success metrics distribution for five of our eight outcome-based segments as shown in the graph below. First, notice how direct revenues are important to only 27% of Hobbyists as compared to 81% of Hunters. Hobbyists more than anyone else state that they don’t care about success (23%), while Explorers define it mostly in terms of knowledge gained (72%). Product Extenders, who aim in promoting a non-mobile product, care most about reach (70%). It is evident that [tweetable]outcome-based segmentation results in distinct behavioural groups[/tweetable]. Success metrics is obviously not the only instance where segment dissimilarity occurs. In our Developer Segmentation report we explore how outcome-based segments differ in their motivations (personal, commercial, community), in the choices they make (including platforms and tools), in the way they think (challenges, platform selection reasons), in markets they target (devices, audiences, app categories) and in the ways they make money (revenue models, monthly revenues made). We also profile them in detail (including their geographical distribution, their experience and role) and discuss what share of the app economy each segment holds. 05 Mind the sub It may be that you are interested in understanding a subpopulation of developers – you may be addressing only developers of a particular region, or developers that use a particular platform. In such cases, you will get more accurate profiles if you segment only the subpopulation of particular interest – e.g. Asian or Android developers – rather than the whole developer population. Consider for example Hunters in Russia vs. those in the US. As Hunters will always be hunters, both groups are mainly after revenues. However, Russian Hunters care more than their North American colleagues about the knowledge they gain, and also a slightly higher percentage states to be indifferent to success. These differences point to a less ‘mature’ market and therefore a less ‘mature’ set of hunters in Russia: Most probably a higher percentage of Hunters there than in the US are at their early stages, currently more focused on building know-how rather than reaching customers – something you wouldn’t have picked about Russian developers if you had just used the ‘global’ profile of Hunters. If you care to understand developers, you need to understand what motivates them, what they consider success and what they’re trying to achieve. Our Developer Segmentation research has done just that. What other stories have you seen where developers are poorly understood or mis-marketed? – Christina (@ChristinaVoskog) #developersegmentation #mobiledeveloper #segmentation