Sobering Mobile App Statistics

One of my favorite blogs to read is that of Andrew Chen (http://andrewchen.co).  He focuses particularly on the mobile app environment, as well as concepts for achieving virality and growth hacking.

Recently he published two guest posts, by Aaron Schildkrout, founder of HowAboutWe, and the other by Mark Flavelle, founder of Tapstream (which is a REALLY cool product that solves the difficult problem of mobile app deeplinking).  The two articles, with links below, portray a sobering view of the mobile app landscape.

http://andrewchen.co/2014/09/24/mobile-retention-benchmarks-for-2014-vs-2013-show-a-50-drop-in-d1-retention-guest-post/

http://andrewchen.co/2014/10/13/iacs-howaboutwe-co-founder-how-to-avoid-delusional-thinking-in-start-up-growth-strategy-guest-post/

The two articles, in summary, basically says that one-day retention in 2014 dropped over 50% to an unprecedented 14%, and that finding successful growth/acquisition strategy is tremendously hard with no guarantees.

The reality is that the app world has become a very very noisy place.  One could compare it to the Klondike Gold Rush at its peak.  With apps like Instagram selling for $1B, and WhatsApp for a cool $19B, everyone and their mother is looking to cash in on their winning lottery ticket.  However, with over 1.3M apps in the Android store and 1.2M apps in the Apple Store (as of July 2014), its nearly impossible for an independently released app to get any notice.  Releasing a great new disruptive app to the store has become just the first step in a long journey of solving the soduku puzzle of attracting and retaining users.

So what’s the solution then?  If I knew exactly, I wouldn’t be here writing this article.  But what it does mean is that the margin of error is smaller than ever.  My top 5 pieces of advice:

1. Your app must be damn good.  The bar is so high now that crashes, bugs, and poor/confusing user experiences are not accepted.  Users are quick to judge and quick to delete your app off their phone if they find it to be technically unsound.

2. Partner or find an advisor who has done it before.  The mobile ecosystem is a world of its own and takes time to learn and navigate.  Valuable time and resources can be wasted pursuing the wrong goals and attempting to achieve the wrong objectives at the wrong times.

3. Measure everything.  You can’t win if you don’t know how to keep score.  Track all of your vital app statistics via analytics tools such as Flurry, Google, NewRelic, as well as your own custom dashboards.  Carefully analyze and compare your numbers week over week and ensure that you’re trending in the right direction.  Use the numbers and statistics to guide your future decisions.

4. Give yourself enough of a runway.  The race is no longer a sprint or mad dash – but instead, very much a marathon.  Make sure you have enough of a war chest to go through multiple rounds of iterations and perhaps even a pivot.  The odds are you won’t get it right the first time – be prepared for the long haul.

5. Be optimistic.  Jane Park, CEO of Julep, said at a recent alumni gathering that tests showed she was 1000x more optimistic than the average person.  Realize that the odds are stacked against you and have been since the beginning.  If you want a sure thing, go work for Microsoft.  Otherwise, be prepared to fight and do whatever it takes, no matter how many nonbelievers tell you that you’ll fail and you can’t do it.

CMS Quick Review

ahnliu

Over the years, we’ve researched, analyzed, and built dozens of CMS systems for clients ranging from small business and startup websites to Microsoft and Group Health.

In almost all cases, we choose to build on top of an existing CMS platform, customizing to meet the exact user requirements. After all, why rebuild what already exists and has been proven? Our value add is adding additional features to meet our client’s exact needs.

In the CMS Platform world, there’s no one size fits all solution. Considerations include scale (expected monthly page views), open source vs proprietary systems, technology stack, publishing workflow, support and maintenance, and other systems that the CMS may be integrating with.

Our favorites include WordPress, Expression Engine, Umbraco, Telerik Sitefinity, Kentico, Drupal, Joomla and on the enterprise side, Sitecore and Microsoft Sharepoint 2013.

I’ll do a more comprehensive review of these CMS systems in a future post, but for…

View original post 21 more words

Anomo Case Study

Anomo is a particularly interesting client for Vinasource, in that it was founded by Vinasource client James Sun and Vinasource CTO Benjamin Liu, after successful collaboration on the Pirq project, which Vinasource helped develop.  The two co-founders, during Vinasource’s work with Pirq, realized that they shared a similar vision of enabling people to find, connect, and engage with the people around them in a safe and efficient manner.  They found that technology had enabled people to gain unprecedented knowledge of their surrounding, from restaurants to housing prices and gas stations, and yet people still knew nothing about the most important piece of their surroundings – the PEOPLE.  And thus social discovery app Anomo was born!

Anomo began in 2012, utilizing a Vinasource development team consisting of a program manager, 2 iOS devs, 2 Android devs, a PHP dev, a QA Engineer, and a Mobile Architect.  The team was rather large for a startup, but was necessitated by Anomo wanting to launch simultaneously on both iPhone and Android, as well as the need for backend web services development where most of the logic and processing was done.  Total timeline from idea conception to beta launch was approximately 8 months of development time, including a UI redesign halfway through the project.  The app was successfully launched in June 2013, and has attracted over 160,000 users and raised over $1.2M in funding to date, with local Seattle investors including John McCaw, Amit Mital, Scott Swerland, and Maveron.

iOS: https://itunes.apple.com/us/app/anomo-meet-new-people/id529027583?mt=8

Android: https://play.google.com/store/apps/details?id=com.vinasource.anomoinc.anomo

 

From a product/technical standpoint, the app was quite complex/full-featured.  Features included:

• Account Creation / Email based Login / Facebook Login
• User Profiles / Interests / Public Profile Page
• Check In module integrating with Google / Foursquare API to get Places Data
• User Content Creation (creating posts/uploading photos/etc)
• Two-way messaging / Group Chat
• Location Awareness
• Search / Sort by Location
• Invite Friends
• Content Sharing
• Push Notifications
• Gifting / In-app Purchases
• Flurry Analytics
• Hashtags
• User / Content Search
• Filtering
• Followers
• Admin System for managing app, content moderation, analytics, users, etc

The team also developed a responsive modern consumer targeted website located at http://www.anomo.com.

The Vinasource team particularly enjoyed this app in that they got to use and customize so many different features within iOS and Android.  It was certainly a feature-rich app (almost too much so, and we looked to start simplifying the app in later iterations).  The team also worked closely with Anomo stakeholders to analyze data – building, adding, and improving features in highly targeted iterations.  In all, up to present day, the app has had over 20+ iterations and updates already, with each one built upon the learnings of the previous iteration.  MVPs of new features were tested out in each iterations, with successful features rewarded with additional customization and unsuccessful features removed.

Probably the biggest learnings from the Anomo project was from being put in the shoes of a client.  We learned first hand the challenges of being a startup, raising money, of evolving business requirements and pivots that lead to development changes, massive scaling, as well as the numerous non-development related challenges.  In particular, we learned the value of iterative agile-based development to combat changing requirements and environments, as well as the importance of analytics, data-driven decisions, and “failing fast” so as to minimize cost and risk when releasing new features.

 

Is Your Startup Lean and Mean?

Reflecting back through all the learnings I’ve had in my involvement with the hundreds of projects we’ve completed at Vinasource, the most useful one is in appreciating and understanding the value of Lean Startup methodology and MVP products.

“Lean startup” is a method for developing businesses and product, originally proposed by Eric Ries in his appropriately named book, “The Lean startup“, The premise behind the methodology is that companies/startups spend too much time and money on product development before validating their core business and product models. Instead businesses should iteratively develop their product, continuously gathering customer feedback and validation, before further investing into deeper product features.

We’ve seen continuous validation in our own projects of the value of Lean Startup. The truth is, you just don’t KNOW, what the end user of your product really wants. Until you actually get actual customer validation, everything that you believe and are betting your company on is just a guess. Perhaps an educated guess, but truly still a guess. As such, developing a product is similar to the scientific method. Start with a hypothesis, perform an experiment to verify the hypotheses, and then analyze and perhaps refine your hypotheses based on data and learning.

Minimum Viable Product, or MVP, defines this process. The standard definition of MVP is a product that has “just the core features that allow the product to be deployed, and no more.” I actually prefer Ries’ deeper explanation that truly gets to the core purpose of MVP – “a version of a new product which allows a team to collect the maximum amount of validated learning about customers with the least effort.”

All of our projects at Vinasource start with an MVP, whether it ends up getting launched to the public or just shown to our customer for review and feedback. We help our clients whittle down their initial visions and requirements into an MVP, often cutting down months of development time and cost, with a goal of getting a working, usable, live initial version of the product up and running as soon as possible. The completion of the MVP doesn’t mean we’re necessarily “done” with the project, but it does mean that we have a working implementation that can be iterated upon. From there, depending on client preferences, the working product can be shown to early adopters, launched as a beta, or launched as an actual live V1 product itself. The feedback and usage data received from users at this point is often transformational. Features that were originally thought to be core to the product may turn out to be unused and ignored. Similarly, however, other features that perhaps barely even made it into the MVP are determined to be the most well-received features within the product and warrants further development and refinement.

A perfect example of this was in our own product, Anomo, an “anonymous social discovery” mobile application. Our check-in feature and “places” feature, which we spent the majority of our initial requirement/spec definition phase defining and perfecting, turned out to be a bit of a dud, due to the chicken-and-egg problem inherent in new social networks that haven’t yet achieved critical mass. On the other hand, our icebreakers feature turned out to be a massive hit, with over 500,000 questions answered per week. While this didn’t change our overall vision for the product, it did result in a pretty significant change in our philosophy, marketing, and advertising efforts for achieving critical mass.

The other key advantage that we found of the MVP model, particularly in being a services business, is that it allowed us to get an early checkpoint with our clients to ensure that we’ve all properly understood requirements and expectations. Inevitably, intent gets lost in communication. While the client may be describing a Volkswagon, we may have understood that they wanted a Ferrari (or vice versa). Nothing is more clear than working software. With the MVP, we can get initial client feedback, course correct if necessary, and ensure everybody is on the same page, before it’s too late.

Sometimes, MVP may actually mean not building a product at all! The famous example is of Nick Sinmurn, founder of Zappos. Instead of spending hundreds of thousands of dollars to build the perfect, beautiful, scalable, performant website, he first approached local shoe stores, took pictures of their inventory, posted pictures online, bought the shoes from stores at full price, and sold the shoes directly to customers from his rudimentary website at a loss. From that, he was able to establish demand and market fit, significantly reducing risk prior to further development and investment.

The natural tendency for entrepreneurs, particular those with high achieving academic and corporate backgrounds, is to seek perfection in their initial launch. Everything in their lives up to that point has validated their desire for perfection. But in a startup world of limited budget, limited time, and massive competition, building what you need, and ONLY what you need, is vital for survival. While it goes against every grain of your soul, Reid Hoffman’s (LinkedIn) famous quote – “if you are not embarrassed by the first version of your product, you’ve launched too late” (http://startupquote.com/post/855482768) is one at least worth considering.