10,000 Mobile Apps later and What we learned.
tldr: We downloaded 10,000 mobile apps this year and we’re sharing insights on how we found them, examined them, lessons we learned about building apps, and a heuristic checklist for how not to screw up your own mobile app dev.
This year, Brian and I downloaded over 10,000 mobile apps. We learned a lot about building apps and basic do’s and don’t’s in the process. It was part of the main inspiration for building LinkTexting, a simple SMS text-to-download form builder for mobile app landing pages.
These are simply ways to make your life a little easier along the way. There are no hacks that yield long term value.
The road to a truly high quality mobile app product is paved in the sweat, blood, and tears of engineering along with hundreds to thousands of hours of talking to users.
The mobile app marketplace is one of the most interesting ones Brian and I had ever set out to explore.
500+ new apps daily.
Every day 500+ apps are released into the marketplace. When we met new people in social settings we’d often ask them what obscure apps they like using the most, especially foreigners because they have access to foreign app stores.
We spent $1200 on mobile apps.
We each have our own reasons. Brian has a mobile analytics venture and I think technology is beautiful.
Some of our favorite paid apps are SayHi Translate, Dropcam, Telegram, Venmo, 1Password, Docusign, UX Companion, Timbre, AppStatics, Streak(CRM app), and Helpouts.
How we decided which apps to examine.
These are some of the tools we used.
10 Big Lessons for Mobile App Ventures
- Limit design to mission critical features at the beginning. At the onset of the design, think through which data points are absolutely necessary for a customer to have an experience with your app, and decapitate everything else. Example: We worked with Coride.co, a long haul ride sharing app. We decided that the mission critical information was email address, start location, end location, and time/date. Adam, the founder reconfigured the app to calculate the price and eliminated one of the huge barriers to entry for users, guessing price. Note: We’ll do a detailed story on how we applied many of these concepts and actions to app design in our next post. Follow us to keep track.
- Run a simple UX Check. Use http://ixdchecklist.com. Know the quality of your app by how many basic UX standards you’re meeting. If your app doesn’t score at least 5/10 on the ixdchecklist, then it’s very possible that your presence in SV isn’t benefiting your app.
- Use your own app. Use every feature and iteration of your own app. Every member of the team should do this every time there’s a release. We’ve met founders who haven’t bothered to use their own apps. It’s frustrating to be in the same room as them.
- Run a simple Landing Page Benchmark. Benchmark your app’s landing page versus http://goodui.org . I like to think of this site as the benchmark of silicon valley landing page quality.
- Always give your customers an easy way to complain. A customer should be allowed to gripe or report issues anywhere on the screen itself. Everyone on the team can do support and they should! Apologize if you’re late to respond. I actually feel like total crap whenever I respond later than 2 hours to customers for linktexting. Hopefully we can bring the time down to minutes. We’ve found that some mobile apps don’t allow it.
- Find the best early adopters. Reddit is a great way to get early engaged users and see people call your baby ugly. Quora is too, but don’t abuse it, add value and answer questions about your userbase behavior and what you’ve discovered through research. Research your adopters and problems using these technologies.
- Don’t go multi-platform too early. We’ve seen that timing this properly is extremely difficult. Particularly so for non-technical founders.
- Don’t pay for app reviews or mislead your users in the description. We’ve suspected that some apps do this. At the moment, we suspect that Simpler, the merging contacts app is paying for reviews. We know this by browsing through reviews and trying the apps ourselves.
- What are the uncertainties? If you’re uncertain about a user behavior, then define it and measure it’s outcome so for the next release you’ll have data to use in making the next big design decision. It helps if you understand basic prob/statistics and confidence intervals so that you understand the validity of your tests.
- If you’re a non-technical founder, you’re at a heuristic disadvantage. Sorry.
Simple questions for anyone building a mobile app.
- What specific parameters of information do I need from the user to create a start to end experience for the user?
- Did I use my own app at least 3 times today? At linkTexting we use the app from start to finish every time we push a new update.
- Did every member of my team talk to a user at least once every day/every period? When we mention period here, we mean a reasonable time span given the nature of the target users.
- Did every member of the team see feedback emails from customers?
- What uncertainties do I have? How can I monitor and measure analytics around the uncertainty that I build into my app?
- Did I look at my analytics with the rest of the team on a periodic basis?
The costs of not following these 6.
- Apps like Cluster, a group photo sharing app added functionalities that weren’t required for a killer experience. The company later pivoted.
- We’ve initiated support emails with mobile app companies and found features inside apps that the founder didn’t know existed. It’s the tell tale sign of a founder who is out of touch with product.
- We’ve seen teams where the CEO calls themselves supreme and is the ‘communication layer’ between the customers and their ‘hacker ninja rockstars.’ Sometimes we hear the words “our engineers are heads down working on another priority.” This is usually a red flag for a technically incompetent founder who might be burning out their engineering team.
- The CEO as a ‘communication layer’ doesn’t work. We’ve seen CEO’s who claim to know the ‘vision’ and ‘product roadmap.’ They dictate what they know and make hard demands on teams. Customer feedback is the source code for building a great app. Sharing customer feedback with the rest of the team helps everyone work in unison.
- Our friend Galen Danzinger at Bibs Mobile wanted to program an extremely complex feature into his marathon registration app. We showed him that he could test this by limiting the options and having future events that are fully registered to see if people click on them to express. It was round about, but he figured out that a running event closer to max occupancy yields less registered runners. It turns out people don’t like seeing other people while they run!
- Again, this is about sharing the source code behind product roadmap decisions with the entire team. A founder who is incompetent inside their own analytics system is usually incompetent and if they’re successful, it might be because they have a kickass CTO. You’ll notice the tone of this post is that we consistently favor the technically competent founders of mobile app companies.
Achieving simplicity is hard.
By asking these questions you automatically get closer to achieving something that’s extremely difficult, simplicity. The list isn’t a list to end all lists of potential questions in building your mobile app experience, but will address a majority of the problems that happen.
Got a great question to add to this basic list or have a question about launching your own mobile app?
Shoot us a tweet @linktexting, @datarade, or @blaurenceclark.
Want us to download your app and review it? Message us at support(at)linktexting.com
