Mobile Application Development Strategies - Techdirt · PDF fileMobile Application Development ... the complexity level for mobiles is exponentially ... We recognize that it may be

Embed Size (px)

Citation preview

  • Mobile Application Development Strategies

    March 7, 2007

    For additional insight from the Techdirt Insight Community, please contact Techdirt at http://www.insightcommunity.com or 888.930.9272

    The Issue p. 2Summary of Responses p. 2Techdirt Analyst Recommendations p. 4Insight Community Responses pp. 5-15

  • Techdirt Insight Community Mobile Application Development Strategies, March 2007 2

    Outline A Strategy For Developing A Mobile Application

    Developing applications for the mobile world is incredibly tricky. Unlike the PC world, where the choices are pretty obvious, the complexity level for mobiles is exponentially more difficult. You basically take car-riers multiplied by OEMs/handset vendors multiplied by operating systems multiplied by development platforms to set the base level of complexity. Add to that the rapid churn rate of users, and it becomes even trickier. So, for a company thats developing mobile applications, and wants to maximize coverage while minimiz-ing integration costs, what is the best strategy? We recognize that it may be different for enterprise apps and consumer apps -- but are interested in both areas, so please give thoughts on both markets. Feel free to think outside the box, but hopefully the answers are practical. As a secondary question, if the strategy is to attack one platform at a time, what sequence of carriers/platforms/vendors makes the most sense, for each of the consumer and enterprise markets?

    The ISSue

    SuMMAry of reSponSeS

    One thing that became very clear in the Insights pro-vided by the Techdirt Insight Community is that this is a really hard problem -- one that many of the experts had experienced first hand. The group, however, did have many practical thoughts.

    The first could be summarized as looking for the path of least resistance. Many noted that it helped to look for some kind of least common denominator for moving forward, with some going all the way down to the level of simply offering an application via IVR, SMS or WAP. Taking a step up from there, many peo-ple suggested focusing on Java as the platform of least resistance. No one really did so enthusiastically, given the many problems associated with Java, particularly the inconsistency of its implementation among hand-set vendors, which undermines the write once, run everywhere tagline -- but of all the choices it often has the least problems. Following that, the most com-mon suggestions were some combination of Symbian, BREW or Windows Mobile -- though which one often depended on the type of application in question, as well as the targeted location. This highlights the impor-tance of spending time on defining the requirements for your application, carefully considering the target market, and determining how simple an application can support your core functionality while delivering it with an acceptable user interface.

    A second important consideration in choosing a devel-opment strategy is what the corresponding marketing

    strategy for the application would be. While this may not seem directly relevant to development, it is key due to the nature of the market. If you cannot establish certain key marketing relationships, then the develop-ment strategy may need to change drastically. While it is considered a pain, getting your application on deck from big-name wireless carriers is definitely a compelling strategy, if you are targeting the consumer market. Our Community makes it clear that this is no easy task, and may require either exceptionally talent-ed sales people or a multi-pronged approach targeting a variety of carriers, while still preparing to prove out the application off-deck. If you must go off-deck with a consumer application, then they recommend part-nering with one of the popular aggregators, such as Handango, and also preparing to spend a significant amount (both in terms of money and effort) on mar-keting. For an enterprise application, other potentially easier sales channels exist, such as selling directly to corporate IT departments, or through resellers.

    A third issue that plays into the decision making is tar-get location. Many of the respondents focused mainly on a go-to-market US strategy, and noted that things changed if you were more focused on a European strat-egy -- where Symbian dominates. One of our bloggers pointed us to a marketshare chart (Figure 1) which was created by Symbian, so theres a bit of bias -- and it also normalizes the population of each region, which may be distorting.

  • The final major concern brought up by our community was what additional features of a handset your appli-cation needed to access. If it doesnt require access to more detailed systems (3D graphics was named a few times), then there will be fewer problems.

    The end result is that there really arent easy answers to the problems facing mobile application developers -- and, it seems that the best strategy may be a multi-faceted approach. Depending on the target markets, its advisable to focus on platforms that quickly give you more bang for your buck (Java mostly; Symbian if focusing outside of the US). Following that, what shines through all the discussion is that partnerships are key. Finding the right partners, whether theyre the mobile operators, marketing partners or even de-velopment partners who can help port your app for you become key considerations.

    There were two additional suggestions from our com-munity that could prove useful. One was to focus on developing the core functionality in-house, but then licensing it out to others to develop more detailed sys-tems and/or porting it to other platforms. A related suggestion was to open up your application, either ag-gressively by going open source and hoping that others will port to additional applications, or while retaining control by simply opening up certain aspects to allow others to develop hooks or tools to allow you to more quickly tackle additional markets and platforms.

    Unfortunately, there doesnt appear to be any kind of silver bullet, but a phased approach that looks for a few different paths of little (if not least) resistance, fol-lowed by iteration as the market adjusts, seem to be the strategies recommended by nearly all of our Com-munity members who took part.

    Techdirt Insight Community Mobile Application Development Strategies, March 2007 3

    Fig. 1: Smartphone OS Market Share, 2006. Source: http://mobilephonedevelopment.com/archives/322

  • Techdirt Insight Community Mobile Application Development Strategies, March 2007 4

    TechDIrT AnAlyST recoMMenDATIonS

    One of the main problems our Community faced in providing direct recommendations to this insight was that beyond just the complexity described in the ques-tion, the many different types of potential applications in which the company posing the issue might be in-terested presented yet another dimension of complex-ity to the equation. Had the community known more about the application in question, the strategies would have been more specific.

    Knowing more about what you are trying to achieve ourselves, we can provide a few more specific recom-mendations. The key remains exactly what was dis-cussed above. Nearly all of the technical design choic-es depend heavily on the go-to-market strategy for the application. The more well-defined that is ahead of time, the clearer a development path becomes.

    Given your existing relationships and access to certain mobile operators worldwide, for consumer focused apps, its going to make a lot of sense to leverage those relationships as much as possible -- obviously for things like making sure your application is included on-deck, but even for development help as well. Even using your core system, you should work with the op-erators so that they can customize the application to work with the various platforms and handsets they support. This will be essential, as its likely on many low-end phones, developing an embedded version of the application will be necessary, since a Java version wouldnt be allowed to access enough of the handsets functionality to make the application work, or be use-ful. Providing a thorough developers kit will be im-

    portant.

    On the enterprise side, it makes less sense to leverage those connections, but to focus on developing your ap-plication with a partner like RIM -- who dominates the business market within the US so it runs well on their BlackBerry devices. Successfully proving the applica-tion on the enterprise side with RIM will have others in the corporate space banging down your door to help port your application to their platforms.

    Finally, we recommend watching a few technologies very closely, that while still early in development, may make the process much easier in the future. Things like Flash Lite and Operas widgets could provide a much simpler path to more widespread compatibility with minimal development time, though theyre gen-erally aimed at web-based applications. Looking even further out, there are some new players in the space, such as DartDevices, who have a compelling virtual layer/virtual terminal approach to mobile application development. Its system not only allows you to run a single app on many different devices, but also to access apps found on one device from any other connected device. However, the company is early on in develop-ment and faces the same problem you do in getting its platform adopted more widely first.

    Overall, this is not an easy problem, but focusing on the go-to-market strategy first, followed by leveraging existing relationships with key partners, while moni-toring some new developments, appears to be the most likely path to success.

  • Techdirt Insight Community Mobile Application Development Strategies, March 2007 5

    InSIghT coMMunI