Ever since returning from the Uplinq conference, we’ve been involved in some rising conversations towards how developers, businesses/organizations, and people can better understand mobile in the context of making or marketing mobile applications – especially in the faith-based arena. It is true that not only are purchasing tendencies slightly different, but there are also some other considerations that carry some more weight than others.

This post will serve as a high-level understanding of this subject, and hopefully provoke some decent discussion towards taking some steps forward.

Identifying Opportunities
Probably one of the more striking things to hear is that there are tons of developers who don’t know what to build. The other side of that is that there are a number of companies and organizations which have specific needs, but don’t know how to go about finding the developers or marketing communities that have those resources to assist them.

So, let’s start with the question of “how to identify mobile opportunities within this faith-based space?”

Similar to MMM‘s noted content areas, there are specific areas in which I commonly hear needs:

• Real or near-real-time translation services
• Multimedia editing and distribution
• Enhanced SMS/MMS services
• Moderated communication or devices
• Parental or organizational mobile device and web management
• Curriculum development, collaboration, and analytics

These areas aren’t large items in and of themselves, but do point to some of the basic (and no so basic) area to which there’s a need. Of course, after you get to this point and know that you have an opportunity in hand, what’s a next step?

Connect with Developers or Marketers (or Your Intended Audience)
This is the aspect of mobile that’s understood to be called engaging networks, or building out your social web. For example, when looking to address a need in language translation, you connect with organizations such as Wycliffe who have done this for sometime. You connect with those platforms (web, Symbian, Java, etc.) which have a heavy presence in multiple regions and languages. And you leverage existing works (many lexicons are already in an accessible XML or XML-like format).

Connecting doesn’t just mean grabbing their resources, it also means to become a participant in the discussion around that resource. You improve the code-base, or you engage in the design and testing, or you improve the visibility of the effort in your own social networks. In other words, you don’t need to be a developer or a large organization for many applications, just an idea is enough sometimes to kick-start the effort.

This enables you to not just get an application done, or find one that suits you best. But, it gives you something to say as an opinion/thought leader in that community when its time to change or clarify focus.

A Common Debate: Focus on App Stores or Mobile Web
No matter whom you speak with, there’s going to be a discussion (or plenty of discussions) about the idea of building an application for a specific mobile platform or building the application as a web service, accessible to more devices, but dependent on several environmental factors. Many things depend on the application, and how much connectivity and native device functionality will be needed. But, it’s not as difficult of a scenario as it might seem. Here is some guidance in this area:

• Ascertain from the outset where the content within the application will be used, and focus your efforts there primarily, with a secondary use case in your back pocket;
• How much existing content exists in another application; do you need to just bridge to the API, or build a custom data set to support your functionality;
• Do you have the budget to build, test, and deploy to several platforms, or only a select few which are vital to answering the problem;
• Is your offering unique enough to be found amongst the thousand of applications which inhabit many mobile app stores.

Part of the debate stems from a failure to understand the needs and abilities of the target audience. For example, if you are considering to build an application to assist missionaries manage expenses while on their trips, consider that they are most likely using a rented or more rugged device (possibly w/o a touchscreen), they are not going to have an expensive data plan to go through several web pages before an item is recorded, and they are probably in need of some kind of off-device backup mechanism.

Target the choice about whether you build an application or offer a web application based on the real needs, not just what’s popular to develop for.

Defining the Successful Application
After the application is built, and the audience has received and begun offering feedback, you want to ask the question about the application’s success. Did the application set out to enable what you wanted it to? Were there any hurdles in the build, testing, or marketing phases of the project that you’d know better about the next time around?

You also ask the hard questions such as: were there too many hands in the pot (too many project managers, developers, marketers, etc.); was the marketing effort enough to justify the actual versus potential users; was the support structure accounted for; and so on.

Logging your impressions of the project from its initial thoughts, to the moment where you consider the solution built will enable you to best denote what success looks like. And while you might have some wild expectations, it’s key to stay realistic, and persistent (because sometimes, applications developed in a flurry can have a long shelf life without much maintenance).

Other Points
There are some other points that you should consider when making or marketing a mobile application. Here are some which follow the points above:

• Get involved with developer relations groups such as WIP Connector, Code.Google, and the various carrier and manufacturer developer groups
• Pay attention to both the popular and niche analysts who dissect trends and understand some of the intricate details towards the lifecycle of mobile
• Don’t be afraid to try something new in respect to the user interface, or even the entire user experience; however know that things which look and act familiar, are more likely to be used
• Develop your support and feedback system early in the process (example happening here with MeeGo)
• Consider security: not just device loss, or corporate management, but scenarios which are out of your hands such as fraud
• Whether the application is free or paid, consider various community and monetization strategies to support the effort after the initial project
• Document your journey (aka, write whitepapers and case studies); chances are, you might be traveling a road others will want to learn from, so your lessons learned here prove to be vital beyond the scope of your product

Beyond this, I would simply say to just go out and create something. Find out those pain points in your local or global communities, and work with as many hands as possible to use your gifts to develop into the solution.

Much like when Paul and Apollos noted how they might plant and water, but the Holy Spirit is the cause of the increase and the Body is edified towards Christ and the Father; you too want to plant and water in mobile those things that the Holy Spirit can (and will) use to enable us all to glorify the Father (John 17:21-24).