You are here

Why your next mobile app will fail, and how to avoid it

public://pictures/esherman_0.png
Erik Sherman, Journalist, Independent

The old saying "Success has many parents but failure is an orphan" has things backwards when it comes to mobile apps. When an app fails after considerable time, effort, and money has been invested in its development, everyone is responsible. And although not an absolute certainty, chances are good that the entire project will now be canned.

Mobile app failure goes far beyond a bug or flaw that can be remedied. Luckily, there are common categories of problems most likely to cause an app to fail. Knowing them won't necessarily make your app immune to failure, but it will help you proceed intelligently and look for the signs that things could take a nasty turn.

[ Get up to speed fast on the state of app sec and risk with TechBeacon's new guide, based on the 2019 Application Security Risk Report. ]

Defining failure

To understand the categories, think about what failure means. Dictionaries define failure as a lack of success or the state of not meeting a set of goals or objectives. In other words, there's no such thing as general failure. A project will only fail in context of something you're trying to achieve.

In that sense, there are two basic types of failure, because there are two major categories of goals: those set by the company to meet strategic demands, and those the users set in terms of what they expect from the app and how they think it should perform.

But you can also fail if your goals don't support company strategy. For example, "copying your competitor to get something out there in a hurry is a recipe for failure," said Mark Lister, vice president of experience engineering at London design company Ness SES.

[ Is it time to rethink your release management strategy? Learn why Adaptive Release Governance is essential to DevOps success (Gartner). ]

Market problems

You could also fail by not reading what was possible or needed in the market. Ness, for example, had released a highly popular sports-event-related app and thought that developing a continuing series would be smart. But event organizers started developing their own, and it became the most natural choice for consumers. The market opportunity had already closed.

Levent Gurses, president of Virginia-based app development firm Movel, built a social media management app for restaurants and clubs a few years ago. "We had tested the original idea by conducting a fairly detailed customer survey which included questions such as, 'If you had an app that would provide this functionality for this price would you use it? Would you pay for it?'" he said.

The answers sounded positive, but Gurses learned the hard way that asking what they would do in theoretical circumstances is the least reliable type of question you should ask when doing market research. "Once the app was done and we started promoting it, we quickly learned that restaurant and club managers, or their employees, were simply too busy or uninterested in the app. No benefits could convince them to use it on a regular basis."

Market research is fine, but the real test is how people react to tangible products. Gurses now creates usable prototypes and spends time with prospective users to see whether they embrace the concept or ignore it.

App concepts should elicit a "when can I have [it]?" reaction, said Robert Pieta of Onenigma. He leads development on PorterKey, but he tried another product, Reach News, last year. "After showing Reach to many people, we grouped the feedback we got into clusters. Many clusters were positive, especially the design. However, there were no clusters that indicated genuine excitement for the product."

And others like Flipboard had extended their products to directly compete. "We're focused on trying to keep the development loop as tight as possible (they create and quickly show apps), said Pieta. "If the excitement isn't there, we know it's not the right thing right now and jump on something else."

Furthermore, you need to be sure that the market realities can support the business goals. If your business plan calls for people to pay for an app and users are unwilling, there will be a fundamental problem. Perhaps you could substitute ad revenue, but now you have to consider whether that has the potential to generate the level of revenue you need.

Technology

Negative reviews can kill an app, so anything that slows performance, causes errors, or crashes an app can lead to negative reviews. By definition, you're upending user expectations. However, the technical issues go far beyond bad network or battery management or null pointer exceptions, and these problems can be difficult to find.

Aaron Fraser, founder of New York-based company FaceLinkTweet, hired overseas developers to create an app that combined messaging, free phone calls, and video uploads. It was a first venture for the company, which badly underestimated potential popularity of the app.

"So many people were logging in and uploading videos and photos that the servers crashed," Fraser said—and that was with a dedicated server. "When you're a startup you try to work within a budget and try to cut corners. So I learned that cutting corners isn't always the best thing."

But experience and provisioning what seems to be abundant capacity may still fall short. Mobile design and development firm PointSource created a loyalty program app for a major household retailer. PointSource and the client extensively talked through what was necessary and the expected traffic, so the firm sized cloud services for traffic spikes of 10 times that level.

Unfortunately, the client, worried about proprietary traffic information, decided that it—not PointSource—would monitor how the app was doing. "They launched the app Labor Day weekend and got 10 times the [expected number of] downloads the first day," said CTO Erik Burckart. About 30 hours into the launch, traffic hit 50 times expected levels, or five times the planned peak capacity.

Fortunately, because they had used a cloud service, it was possible to quickly spin up additional processing capacity. However, because the client hadn't implemented 24-hour monitoring, the project missed the early signs that could have warned of the oncoming problem. Instead, no one realized there was an issue until the app started receiving bad reviews online. Now PointSource stresses the need for round-the-clock monitoring to look for early warnings that there are problems.

Similarly, Burckart said that clients, especially Fortune 500 companies, often want to control testing because it can be perceived as something that "anyone" can do, and so the business decides to save money. However, he remembered an experience with PointSource's second geospatial app. The client undertook the testing and provided the test plan for review, but everyone missed that the testing was clustered in certain parts of the country. Luckily, a project engineer on a personal road trip happened to try the app and found some big problems with the data. One answer is to use an app testing company that crowdsources work to people all over the country.

Process and communications

The dynamics of the development process and communications among all those involved are critical to success. Burckart remembers an insurance company in which the CIO asked for an app that could provide information to its customers. The company's marketing agency was involved and the result was an app with versions for Windows, Android, and iPhone. "It wasn't cheap to build," Burckart said.

"Toward the end of the beta, when they were about to go live, was the first time the marketing department saw it," he said. "It went to the app store for one week before the chief marketing officer had it pulled."

The marketing department had actually commissioned the app from another company, a decision influenced by that company's relationships with other companies and the discounts it provided for the goods and services it could provide customers. These were two completely different concepts of the definition of a minimum viable product.

The CIO and CMO didn't get along, and eventually the CEO had to become involved to settle the issue.

There are many other potential process issues. Development should use DevOps, agile, or a similar methodology that allows rapid iterations and frequent updates to provide the type of release schedule that enables the continuous identification of bugs, as well as the refinement necessary to create an app with ongoing success. Developers and marketers should watch the developments of competitors as well as user preferences and habits to help guide the app's future.

Meeting expectations

Each of these areas has a multitude of possible variations in what can go wrong and throw an app project off track and into the failure zone. You may never be able to outguess every possible error. What you can do is plan and be observant for ways your original intent and the expectations of users could be undermined. That alone will give you a fighting chance of achieving the full success your project needs and deserves and avoiding the risk of mobile app failure.

[ Get Report: Buyer’s Guide to Software Test Automation Tools ]