Gartner recently said that in the next few years apps will become one of the most popular computing rools for users worldwide, generating revenue of more than $77 billion by 2017. But while much of the attention has been on the latest cool consumer apps, businesses are finding apps enormously transformative. Building their own custom-made apps allows them to fine tune them to their specific business needs, instead of the other way around, driving a revolution in employee engagement and productivity and opening up new opportunities or improving functionality by embracing the change brought about by new, powerful mobile devices and their correspond- ing next-generation networks.

But not all corporate apps are success stories- in fact, many fail before they’re barely launched.

The consequences of a bad app, of course, starts with the worst possible outcome —nobody uses the app. Other bad outcomes of failed app development include the lost time and cost of the actual project, as well as the loss in potential business or loss in market momentum due to the app not reaching its desired goals. So what are some of the biggest pitfalls that can doom an app from taking off?

Designing apps in a vaccuum

If there is a universal theme to why mobile apps fail, it seems to start right at the beginning, usually with apps that are designed without much thought about who will be using them and what the end goals may be. According to all of the experts we talked to, this pitfall comes about when there is a disconnect between market- ing or line-of-business departments and the engineering or development teams.

On one hand, there are business users looking to mobile for ways to make their jobs easier, or to help them turn what they are working on—no matter where they are—into real knowledge that helps drive business value. On the other hand, there may be engineering or developer departments that measure success quite differ- ently, either by the number of features added to a program or the number of lines of code. If the thought pattern and strategic direction of these two groups are not aligned, experts say, the result will be a mobile app that nobody likes and nobody uses.

‘When people talk about mobile app creation for businesses, they need to realize that it’s not about which tools they should use,’ says Jack Gold, founder and principal analyst at J.Gold Associates, an information technology analyst firm based in Northborough, Mass. ‘That’s not where most apps fail. Most apps fail on something much more basic—it’s when developers never get feedback from end-users on what the end-users need, before or after the app is developed.’

Forrester researchers identify this pitfall as an adoption gap when the business team and developer team have ”different concepts of value delivery,’ a gap that often comes when the two sides never discuss what goals are desired. ‘All too often, developers like to concentrate on stuffing as much new code and as many new features as possible into every release without regard to the level of business value generated,’ Forrester researchers wrote.

Maribel Lopez, CEO and mobile market strategist for Lopez Research, a market research and strategy consulting firm, says the desire by many firms to ‘create a mobile app’ sometimes clouds the thinking over just what is trying to be accomplished.

‘An actual task is not always an app,’ Lopez says. ‘If you’re just looking to make a call to inventory, that’s not an app. If you are trying to mobile-enable a version of SAP, that’s a bigger challenge. The problem is, many developers may not know what it is they are trying to build.’

Sometimes, the disconnected development comes from the other direction, when business or marketing teams ask for an app without figuring out what it is supposed to deliver. One consultant at a large analyst firm told of a major U.S. fast-food chain that developed a mobile app to try to lure customers to its outlets —except the first version of the app failed, because it lacked simple things like menu prices or the ability to link to a device’s mapping app to show if the user was near one of the company’s restaurants.

> See also: Why you need to move on mobile app testing

The app development team also forgot to include store information for the company’s many franchise-owned operations, making many of its actual locations a blank spot to the mobile app. Without such information, the app found few takers among the fast-food consuming public it was theoretically designed for.

‘But the marketing department delivered a mobile app, so they declared victory,’ says the consultant, whose company was called in after the fact to fix the mobile app and reboot the company’s somewhat nonexistent mobile strategy.

Gold says that mobile app developers should be more like consumer product companies and do a lot of end-user research and testing before launch.’Enter- prise companies and other developers generally don’t do a lot of end-user [app] testing, mainly because it’s expensive, it’s time-consuming, and many of them don’t know how to do it,’ Gold says. ‘Go ask any 10 developers about how many user experience classes they took. I’d guess most of them would say zero. They’re just not trained in that skill.’

Brian Katz, a mobile developer for a medical-services firm who writes often about the topic on a popular industry blog, says development teams should do ride-alongs with eventual end-users, to see how they do their daily business tasks. In his field, he notes that his company’s representatives need apps that will keep working when they are inside hospitals, places where wireless reception can be a big issue. If the apps can’t connect in that environment, Katz says, the reps will simply delete them. And a deleted app is one that isn’t working for anyone.

Trying to make an app that does too much

One of the common results of a mobile app developed without end-user input is an app that tries to do too much, or apps that try to cram a desktop full on informa- tion and links onto a palm-sized screen. In fact, says analyst Gold, many early implementations of ‘mobile’ apps were simply screen scrapes of Windows PC apps, ported to the smaller platform.

> See also: 6 ways to make mobile app projects a success

‘We saw a lot of the screen-scrape apps, mainly because it was the easiest way to develop something,’ Gold says. The problem is, while desktop apps may represent a long history of learned knowledge and functionality that is extremely important to either an enterprise developing its own applications, or a company readying a consumer service, that frame of functionality is sometimes at odds with the goal of using a mobile device.

What many recent surveys have found is that, when faced with complex steps in a mobile app, many users give up quickly, even after just a click or two if they don’t get to where they want to go, or obtain the information they need. With so many apps available, many users figure they’re better off trying something else rather than trying to dig through the complexity of an app that has frustrated them. Getting it right, therefore, doesn’t mean making many choices available. In fact, it may mean exactly the opposite.

Jon Reed, an analyst who writes frequently about enterprise app development, says app complexity is just one way of screwing up a mobile app. ‘Simplicity remains the goal of the mobile experience,’ Reed wrote in a recent blog post. ‘Bite size apps that capture one workflow are often best.’

Reed goes on to note that in a situation like retail merchandising, there may be many functions that could benefit from being mobilised, like managing inventory, processing customer coupons, and sales negotiations. But they all don’t need to be in the same app. Instead, they might work better as standalone apps.

Analyst Lopez says that the desktop-on-a-phone approach also often fails to take advantage of what she calls the “context” of the device.

‘If you’ve just recreated the desktop in a mobile fashion, you haven’t done anything to take advantage of being mobile, like the location of the user,’ Lopez says.

Analyst Gold says finding out what’s important to the user can also direct what needs to be left in and out of the app.

You have to know what the important tasks are [to the end user] and put them up front,’ Gold says.

Some examples of mobile apps that have made a good business out of doing something simple are the chat service WhatsApp, and the picture-sharing service Instagram. Both of those apps, now billion-dollar acquisition stories for their ability to attract hundreds of millions of users, relied on simple functionality as well as attention to connectivity, the next pitfall we’ll explore.

Trying to make devices work everywhere, anywhere

Katz’s point about hospital connectivity issues highlights another mobile app development pitfall: Not taking into consideration the connectivity needs or limitations of connectivity in the environments where the app will be used can also be fatal to an app’s life span.

> See also: Gartner says mobile apps will have a significant impact on information infrastructure

One of the already classic mistakes is to assume that mobile apps will have the same level of Internet connectivity as a PC app used in an office situation. While cellular connectivity can be found in many places worldwide and local Wi-Fi networks are cropping up all over, mobile connections are nevertheless inherently slower and less stable than wired connections or office wireless networks.

Gregg Ostrowski, who leads enterprise developer relations for top BlackBerry Enterprise customers and partners, tells of multiple mobile-app project failures3 he has seen because the apps were designed to work with in-house wireless networks, where access to necessary corporate data was fast and secure. Once outside the company walls or campus, however, performance issues related to connectivity—either the inherent randomness of different cellular technologies or performance issues related to security measures like VPNs—doomed the mobile apps to failure.

Analyst Gold says tailoring the app to the environments it will be used in is crucial to a mobile application’s chances of success.

‘It’s not that the user interface is bad, but the user experience is bad when you go up one level of complexity,’ Gold says. Making apps that use data in the cloud is a good way to keep storage demands lighter on mobile devices, but then Gold asks: what if the users need to work on a plane, or in other offline situations? Does the app also support local data storage for those situations?

‘It’s all about doing it smart, knowing what is needed and when,’ Gold says. ‘It’s not that mobile apps are necessarily worse, because there are a lot of lousy PC apps. But the PC [connectivity] environment is more forgiving.’

Analyst Lopez says that the connectivity needs of the app can help developers ascertain which tools they should be using for design, a smarter way than simply picking a design environment or platform based on whim or personal preference.

> See also: Top 5 strategies for testing enterprise apps

‘The tool selection should be based on what the app requires,’ Lopez says. ‘If it’s just something that’s looking for pricing information, you can get it done in HTML5 and be up and running quickly. If it’s something that requires the deep input of the device, you might want a native experience.’

Not building flexibility into the app from the start

If there was a final pitfall most mobile application experts agreed upon, it’s the idea that a mobile app would ever really be ‘finished’ in the way that desktop or packaged applications used to be. Instead, a better solution is to develop a frame- work that allows for fast creation and multiple iterations of a mobile app, since user demands and device introductions change far more rapidly than the old one- or two-year product development lifecycle.

‘You can’t take a year to build something anymore,’ says analyst Lopez of a mobile app development effort. ‘If you do take a year, by that time the users will want something different.’

One of the biggest trends pushing this need to change rapidly, especially in the enterprise environment, is the so-called ‘Bring Your Own Device,’ or BYOD phenomenon, where users are bringing their personal devices to use in work situations. With users dictating device choices and line of business leaders having more IT budget to work on fast-acting needs and demands, app development teams need to create a structure that can create new versions quickly, just to stay in sync.

In a traditional IT department environment, Lopez says, a request for a new application may be put on a work grid, resulting in a prototype app delivered in six months. ‘But if the marketing department needs something to happen in three weeks, they don’t have an option to wait,’ Lopez says. Often, such teams are turning to places like Amazon for cloud services or agencies for quick-hit projects.

‘You can see where the disconnect happens between IT time and marketing time,’ Lopez says. In many environments, she says, those two functions are still run in different ways.

The downside of not being able to develop quickly enough is often a situation where marketing strategists or line-of-business leaders start looking outside the company to get projects delivered quickly. That situation can create a mishmash of applications developed under different systems with different code bases. Though some short-term goals may have been accomplished, the long-term success of the app team and the overall mobile business strategy is jeopardized by having to manually integrate and align many disparate parts.

> See also: Five mobile app development success stories

The good news is, there are new development tools and environments that are designed with rapid mobile app development in mind, with automated features for tasks like debugging and integrating different types of code. Developing under such new structured systems also allows for uniformity in progress management and results measurement, which also need to change in a mobile app development world.