• Print

10 ways to botch a mobile app

Give your mobile app a better shot at success by avoiding these common mistakes.

App StoreWith the phenomenal growth of smart mobile devices, mobile apps, and their respective app stores over the last several years, just about everyone has an idea for a mobile app. And with each idea comes the belief that it may in fact be the next big thing — a million dollar app that can save its creator from the daily 9-5 grind. It’s true that a fortuitous few have indeed realized their million dollar idea, but for many others their ideas remain dreams alone.

Working in the mobile app industry through these early days of the latest technological gold rush, I’ve seen the same app mistakes made time and time again. Failure, like success, follows a particular pattern. And so, I set out to distill the top 10 reasons why apps often falter or fail, with the hope that this list brings more reason and less emotion into the process of building mobile applications.

Mistake 1. Begin coding immediately

Many fail in the mobile space because they start developing their app as soon as they have an idea. In the extreme case, those with programming skills will actually start coding the app immediately. The first steps, however, should be focused on business and strategy aspects; pixels and design or coding and development come later in the process.

Mistake 2. Ignore competitors and alternatives

One of those business and strategy aspects that many pursuing apps ignore is to identify and use competitor apps. Understanding what competitors do well and where they’ve come up short will provide guidance on what features to develop and how to differentiate an app. Similarly, learning from top apps in app stores or even real-world alternatives, can reveal opportunities for innovation.

Mistake 3. Be purposeless

Wanting a million dollars shouldn’t be the sole motivation for building an app. At the same time, app stores are likely one of the best places to pursue a new venture right now. Ultimately though, it is still a new venture and any new venture comes with a certain amount of risk. Outlining clear short- and long-term goals, that are aspirational yet attainable, will provide a much better foundation for success.

App Savvy: Turning Ideas into iPad and iPhone Apps Customers Really Want — While many books simply explore the technical aspects of iPad and iPhone app design and development, “App Savvy” also focuses on the business, product, and marketing elements critical to pursuing, completing, and selling your app.

Mistake 4. Consider project plans useless

It’s not necessary to create a Gantt chart, but having a project plan for an app is critical. A project plan will demand accountability and set expectations, especially if working in a team. It should also help with one of the biggest problems in software development: actually shipping the app to the app stores.

Mistake 5. Start marketing after the app is launched

Many begin marketing their apps after they are in app stores. Doing so will result in not taking advantage of the initial bump provided by the app store new release lists. Getting marketing moving earlier will allow interested media outlets to have reviews ready when the app hits the stores, thus providing a better opportunity for the app to rank in its category.

Mistake 6. Spend little time thinking about branding

The app name, app icon, app description, and even the app interface are often developed independently of one another. As I’ve written in the past, however, these elements should be considered together because they help create the branding identity of the application. And that’s even more important if there are plans to eventually have more than one app.

Mistake 7. Don’t talk to customers before and after the app is launched

It’s amazing how often people build their apps in isolation. They may get feedback from a couple of friends or family members, but they really don’t develop serious beta testing programs with potential customers. Then, they launch the app and find reviews complaining about buggy or even missing features. Increasing the number of those looking at and using an app through a beta program will result in a more solid and compelling application by the time it hits the app store.

Mistake 8. Include zero contact points within the app

Not hearing from customers can be a symptom of an unhealthy app. It also might be because customers simply don’t know how to get in touch with the creators of the app. Including basic support channels such as in app email or a link to a website can ensure customers will share thoughts, feedback, or bug reports quickly and easily.

Mistake 9. Forget to install analytics

Apps often generate qualitative feedback such as customer reviews, blog posts, and emails. Unless analytics are installed, quantitative feedback is typically only available through download and sales numbers. Analytics tools can offer basic insight into usage patterns or provide very detailed data about specific actions customers are doing inside the app. In either case, hard data is extremely valuable.

Mistake 10. Never update the app

After pushing out an initial version of an app, people give up on it if it’s not a runaway hit right away. To keep customers engaged, it’s a good practice to release one or two updates per month, related to either bug fixes or new features. You can cut back on app update investements if the app continues to show no signs of life, but that decision should not happen a week or even a month after the launch of an app.

Related:

tags: , , ,
  • Canuck

    “The first steps, however, should be focused on business and strategy aspects; pixels and design or coding and development come later in the process.”

    NO! — that’s the disastrous project-management technique we call waterfall (Google it). Please don’t encourage anyone to go back to that. It’s based on the wrong assumption (as proven by billions of dollars of failed IT projects) that business people are so smart that they can plan in a vacuum, and that the job of technicians is simply to implement the business people’s brilliant vision. In 13 years of independent consulting with many large companies and government, I’ve never seen this approach work.

    You start out every project in deep ignorance: you don’t know enough about the business and strategy or the pixels and code. What you need to do is go back and forth to build your knowledge and confidence — start wherever you’re most comfortable based on your own skills and experience (coding or planning), but don’t spend too much time there.

    If you plan first, just do a week or two of research/writing before you move to sketches, wireframes, code prototypes, etc that can get you real feedback from real users (which, you’ll find, will contradict most of your initial plans — see your mistake #7, which is absolutely correct); if you code or design first, create the minimum useful design/prototype before you move our of your comfort zone and do some research and planning (which, you’ll find, will contradict most of your initial business assumptions).

    Keep going back and forth, learning more with each pass — we call this iterative design — and you’ll at least have a chance of succeeding. Otherwise, you’ll face either analysis paralysis or, at best, the pains of cost overruns, dropped features, and missed deadlines.

  • http://411gatineau.com remonatrix

    Interesting Article for sure.

    I have to disagree with Mistake 1 and mistake 5.

    Mistake 1 needs relativity in the sense that not all development shops are created equals. The cerebral point people of your organization are not all zealous.

    I find working with a design, a sketch, helps a lot because you get feedback and people tell you what they want when you show them what they do not want.

    Mistake 5 needs caution especially if you don’t deliver. I have a friend that sold me on this great idea of a project that he had … I in turn trusted his ETA and spoke of this project to other folks … it never materialized … So I created Hype for nothing …

    All and all, great advice …

  • http://www.insuranceactivist.com Alan

    I have to disagree with the twice a month updates…

    People are used to the idea that software is updated perhaps yearly, perhaps even every 6 months. Apps *may* be a little different but not by much.

    Constant updates tells me your program is a sloppy bug-ridden work in progress and you’re using users as testers. That’s not good karma.

    There is actually a reason for NOT updating…

    It seems to me that on the Android market many developers attack their competition by posting “It worked fine until the update…”

    You see those words all over the place. Either almost every developer out there manages to break their creation with every update or something more shady is occurring. However you look at it though, updates ARE an opportunity for messing things up, alienating your most vocal customers, getting your app uninstalled or at least giving your detractors the chance to claim you did all of the above.

    Fixed it?

    Sure you did. But since the latest update…

    A.

  • odvar

    @Canuck No one wants to go back to the Waterfall model. That is not what the author is talking about. He is talking about the entire project not just the development cycle. The project will start with initiation then planning and implementation. It is actually during the implementation stage you actually should start your design and coding using which ever development methodology u see fit. What the author is talking about is more than just coding you make decide after project initiation that the project is not feasible and thats just how projects should be. I encourage you to read a bit about project management.

  • Canuck

    @odvar You’re still advocating a fixed waterfall order (“initiation then planning then implementation” — italics mine), and trying to lock the iterative idea down in an implementation ghetto, rather than letting it inform the whole business-development cycle.

    A successful venture can start anywhere in an iterative cycle. A business can grow out of a quick-and-dirty software prototype from a bored developer, doodles from a graphic designer, an inspired business plan, or often feedback from customers of a different product (as happened famously with Flickr).

    No matter where you start, though you have to iterate rapidly through all the areas — plan-design-build-feedback. It doesn’t really matter that the starting point is “build” instead of “plan”, because you’re going to come back around to “plan” very quickly anyway, and then you can try to make sense out of what your designer, developer, or customers discovered and change the course as appropriate.

    If, on the other hand, you get stuck in any of the stages (including plan or build), you’re toast.

  • http://getappsavvy.com Ken Yarmosh

    Thanks for the comments.

    Research does not equate to the waterfall method and at no point was it stated initial research or planning had to be done only by “business people.” That is a recipe for disaster.

    Beginning with some basic research (often even just a few days or less) offers a starting point to move forward with a more informed software development process. The intent beyond that point is to then test those assumptions throughout the rest of that process. The key is that software development does not solve business problems…they simply address engineering ones.

    In regards to the frequency of updates, it’s a proven best practice that regular updates of 1-2x a month are expected for mobile applications. So, it really *is* that different from other kinds of software. Those who break their app from update-to-update are simply not developing their apps properly. For those that fall into this category, the regression of their apps post-update doesn’t negate the importance of this principle.

  • Canuck

    Ken: thanks for the response. What I took issue with was your listing “Begin coding immediately” as mistake #1.

    If your strength is coding rather than market research, why would it be a problem to start by spending a week coding a prototype, and then a week getting feedback, and then a week doing some planning/market research based on what you learned during the initial prototype and feedback?

    Your planning comes two weeks later, but it will be an order of magnitude more effective, because you’re basing it on real information. Of course, your next iteration through coding will be better too, because you’re informing it with the feedback, planning, and design, and so on.

    “Begin coding immediately” could be a mistake only if you assumed a non-iterative approach, where coding now meant doing no planning much later or never. In an iterative business approach, you start whether you want and keep moving quickly, like riding a merry-go-round instead of a waterfall.

  • http://bizmo.com Brad Florin

    Ken – great advice on creating professional apps that are on par with commercial quality software for Windows or Mac. When it comes to business apps, I would agree with other commenters that less frequent updates are better and reflect stability of the product. Business users do not want to be part of an unpaid beta testing team. Our dev team spent a ton of time making sure the Bizmo Accounting, Time and Billing app is solid for customers, resulting in just one patch release in six months. We are finishing up a 1.1 release that we hope to be stable for a similar time-frame! Brad Florin, founder and CEO http://bizmo.com

  • http://room302.cn dreamtale

    Mistake 1. Begin coding immediately
    ————————————-
    I dont’t agree this,Coding immediately will let you know more detail that you dont’t notice first but need to concern about,All the thought before you really do it is just a thought,Quick action is important.

  • http://www.tapity.com Jeremy Olson

    Canuck: I agree, iteration is very important. I, however, do agree with Ken that even a little bit of initial research could save you a lot of headache. I think a key thing to think about is that you are not building an app in a vacuum. Even if you build a useful app that users like, if you spend a bunch of time on it only to realize a couple weeks later that there is already an established app out there that does exactly what you were trying to do and there is not a big enough pie for two apps in the marketplace, you just screwed yourself. It’s not just about creating a great product, it’s about the market you will be pushing the product into. With a little initial research, you can find the gaps in the marketplace (gaps of quality, features, price, or what have you) and build an app that focuses on filling those gaps.

    I’m all for getting excited about something and making some low fidelity prototypes while you’ve got the fireworks going off in your head (I do this all the time), but don’t go days or weeks before actually buckling down and making sure it’s a viable product in the marketplace.

  • http://fuelm.com Savash Kalay

    Great article Ken,

    All the problems you are listig really start with one “Mistake 4. Consider project plans useless”.

    If i were to give an advice -dont do anything before you plan all events and make sure you flow the action list you created with your planing. We all work differently so follow what make sanse to you the most.

  • Kathy Sierra

    Great post. In comments, though, My heart is with @Canuck on Mistake 1 “begin coding immediately”. However, his clarification that coding immediately fails if you are not already assuming an iterative approach is crucial. But sadly, too many of us have seem the pscyhological lock-in that happens when something is coded… there is an investment in time and energy that makes sweeping changes less likely than when starting with a blank slate. Not always, of course, and often it is not the developer who is locked in, but others who upon seeing something that “feels” real, switch to incremental improvement mode when they SHOULD — at this early stage — be in a far more creative/revolution/innovation mode.

    Our motto was always, “make the demo look as done as it actually is”. Using a “napkin UI”, for instance, that by design renders lines as sketchy scribbles and fonts that look hand-drawn, so that you can show functional software that still “feels” as easily changeable or even throw-outable as a napkin drawing.

  • Julien

    @Kathy Sierra: thanks for describing this technique. It was an epiphany for me reading it: it’s simple, obvious, and not done in practice.

    I’m happily imagining a world where discardable stuff looks like we can discard it, instead of dressing it up as a product for demos.

    Sweet dreams.