Mobile Lifecycles, MVPs and Analytics: How to explain it all to clients

When you’re developing apps, there can often prove to be quite a gulf between a client’s expectations and the actual realities of launching and maintaining a live app.

The most common misconception is that building an app is a one-off task, so explaining that this really how isn’t how apps work is the first and most important hurdle to jump.

Establishing this concept with customers up front can help save you development time and ensure that your customers know exactly what to expect from the first iteration of their app.

This article explains the benefits of explaining best practice to customers, establishing a sensible cycle of releases, and the use of in app analytics to streamline development. In the end, following these tips will keep your development time productive and give your customers realistic expectations of what they can expect from both your relationship and their app.

Move clients away from “boxed product” thinking

As we mentioned above, clients need to understand that buying an app is nothing like buying a product from a shelf. Unfortunately, this misconception isn’t helped by the fact that plenty of app developers like to create the impression that it’s realistically possible to deliver an app for a fixed €/$/£ fee!

It’s therefore essential to break clients away from this mind-set. Part of this can often involve explaining the wisdom of trimming down the original app requirements to arrive at a “lean and mean” MVP (Minimum Viable Product).

To those without experience of app development it can seem oddly counter-intuitive to suggest lowering initial expectations and coming up with a shorter features list. Until you explain why, it will likely seem bizarre to the clients too. However, it makes perfect sense.

App users are a demanding and fickle bunch, and an app that does the essentials perfectly is far more likely to enjoy success (and generate positive reviews) than one that squeezes in as much functionality as possible, to the detriment of the overall user experience.

Use popular apps as examples

Thankfully, explaining why it makes more sense to go with a model where an initial MVP is followed by incremental updates and new feature launches is easier to explain to non-technical clients than many other technical concepts are.

This is because the majority of people use a wide selection of apps themselves on a daily basis. There’s no need to come up with complex analogies to explain the tech, when you can simply find examples of good practice from the apps they already use.

Take Uber as an example; At the time of writing, it’s up to Version 2.158.3. That amounts to a whole load of incremental updates! There’s now far more functionality in Uber than there was on launch, but it’s unlikely it would have worked well if Uber had tried to cram everything into Version 1.0.

The key thing here is that Version 1.0 has to execute its functions perfectly.

Emphasize the concept of in-app analytics

Once customers understand all the logic above, it’s time to explain the use and value of in-app analytics.

While App Store reviews will give a (sometimes rather harsh) overview of how customers perceive an app, in-app analytics go much further. These tools can help you and your clients see which elements of apps are being used as intended, places where users seem to be getting confused, and parts of the app that customers appear to have no interest in.

As such, analytical tools allow data-driven decisions to be made on what may need tweaking for the next release, and what features should be added (or perhaps removed) next. This is the “scientific” way to handle ongoing app development, and clearly beats throwing everything into the app and seeing what people like and dislike based on their reviews.

Establish a release cycle

Just because some features won’t make the cut for the first MVP, it doesn’t mean they can’t be pre-planned for later releases.

The key is to establish a rolling program of updates, but also remember that this program should be fluid and flexible to change. There will be times when an update becomes necessary for an unexpected reason — such as a bug fix or a compatibility issue with a new OS or device release. Then there will also be planned version upgrades to add functionality, such as push notifications or UI redesigns.

Keeping apps regularly updated to a planned (yet flexible) release schedule ensures they continue to evolve and meet customer expectations. Frequent updates also allow issues to be quickly “nipped in the bud” before they turn into a review-score nightmare if a mistake is made.

Emphasize the importance of the customer journey

The chances are we’ve all experienced times when a new app release hasn’t pleased us. For some, Facebook springs immediately to mind. The social network has frequently seen serious “push back” from users after a new release or UI change, but people do get used to the evolution, and it’s not as if there remains a vocal group still clamoring to have the 2012 version back!

That said, it’s really important to closely monitor how customers are using apps, especially if a substantial change is made to the overall user experience. This is again where in-app analytics can help. By keeping a close eye on the customer journey, it’s possible to quickly identify if a change has confused or irritated loyal users.

There’s nothing worse than using a system that feels like nobody has tested it. Regular releases, well tested MVPs, and a constant eye on analytics should all contribute to making sure your clients’ apps are never too harshly judged. By making sure that your clients have a solid understanding of the development process, as well as the data behind your decisions, you can ensure that when it time for the app to go live, everyone is happy with the final product.

Thanks to our friends Appsee for posting this.

Originally published at on November 15, 2016.

One clap, two clap, three clap, forty?

By clapping more or less, you can signal to us which stories really stand out.