Header Ads

Data-Driven Mobile App Iteration: Seeing the Wood From the Trees [Mind the Product]


Imagine a lumberjack wanting to cut down a tree with his chainsaw. It’s a pretty simple, straightforward task. But what if the lumberjack never knew that he could turn the chainsaw on? Or that he cut down 1,000 trees when he needed just one specific tree? Not quite the ideal way to use the tools at your disposal.

Unfortunately, this analogy can easily be translated into the world of mobile app iteration cycles. Many product managers know they need to use data, and they are using it – just not in an ideal way. In a world that no longer revolves around “if” but “how” we use analytics and data, what does it take to cut through the noise, focus on what’s important and end up creating superior mobile app iterations?

Data-Driven Problems

Product managers who want to be data-driven, but aren’t exactly sure how to achieve this, usually fall for one or more of the following traps during their analysis for mobile app iteration:

  1. Track everything possible in their app without an exact idea of how to use the data
  2. Spend huge amounts of time dissecting the data but do not reach a high-enough level of confidence to act on it
  3. Focus their efforts on the wrong elements of data, spending less time, but still ending up with information that’s not exactly ideal

This is as if our example lumberjack cut all trees, regardless of whether they’re useful to him. Or if he focused on all the wrong trees, weed, underbrush and sickly plants.

Sometimes, product managers may use the wrong tools to understand the problems they have with their app. For example, they just look at quantitative data such as uninstall rates and blindly make changes in the next mobile app iteration cycle in the hope that rates improve. Even if they do, there would be no way of confirming which change prompted the improvement. It’s like trying to cut down a tree without turning the chainsaw on first.

It might be that they gather the right data, but without a clear end goal or use case to strive towards, they end up using that data in the wrong way, or not using it at all. All the trees in the world won’t mean much if they rot away in the lumber yard. Product managers need to know how they plan to use data – and they need to use it.

In order to avoid being caught in the bear trap that data-driven intelligence can be, product managers need to:

  • Have clear goals on what to use data for
  • Gather data that they can feel confident to act upon, using the right tools
  • Act on it

Picking the Right Trees (or Data)

A usual mobile app iteration cycle looks like the image below:

measure-learn-build-730x391.png
Image credit: The Next Web

Product managers first gather data, then they extrapolate useful insights from them, then they act on them by building new features and improvements. They then rinse and repeat the process, only this time they include whatever they built last time around. But it’s never that simple. Obviously, this image is an oversimplification of the process which can actually be counterproductive.

So the first thing they need to pay attention to is to make sure they’re not monitoring useless data. It’s time to pick the right trees from the forest.

Depending on what the project’s current phase and end goals are, these can be anything from analyzing crashes, to the number of new account registrations, retention rates, to quit rates and uninstalls. For the sake of argument, let’s say our product manager is focusing on uninstall rates on their app, as they’re quite high.

Now, clear goals need to be set. “Reducing uninstalls” as a goal is one of the bear traps – the goal should never be a vague, numerical one. Instead, the goal needs to be to understand what is behind the unusually high rate of uninstalls and focus on that. At this stage, proper usage of qualitative analytics tools is essential. By using qualitative analytics tools, like Appsee, product managers can get a clear, completely intact view of how their app, including the latest features and improvements, is being used. As seen in the image below, qualitative data helps streamline the data analysis process. Insights can be obtained directly and those insights can then spur further qualitative data analysis. This is when our lumberjack turns the chainsaw on.

flow-appsee-dark-73830.png

Watching a couple of real-time user session recordings allows product managers to see the exact moment users decided to uninstall an app, which can help them understand which pain points, UX or performance roadblocks motivated users to ditch the app altogether.

Finally, don’t allow this data to sit idle. Qualitative analytics, together with their quantitative counterpart, allows product managers to be truly proactive. Instead of waiting  for aggregate data to address a crash or usability issue, they can detect product issues instantly and iterate with confidence . They can dramatically improve release cycles, save countless hours guessing the meaning behind a certain metric, and validate hypotheses and test results with clear, visual proof.

In Conclusion

Using app analytics to improve iteration cycles is generally seen as a “must” in a product manager’s workflow. But just as a lumberjack can cut down a tree with a chainsaw without actually turning it on, it is essential for product managers to know exactly which tools to utilize, how to use their tools, and for what end goal.

There are three steps along that path: first is to choose the right data (the right tree), second is to use all the tools at your disposal, both quantitative and qualitative (turn on the chainsaw), and finally – to make sure data gathered is used towards an end goal that was previously set up. Only that way will product managers make sure they’re not wasting their precious time and resources doing nothing and going nowhere.

The post Data-Driven Mobile App Iteration: Seeing the Wood From the Trees appeared first on Mind the Product.


Source: Mind the Product http://ift.tt/2kGagkw
Powered by Blogger.
// check for file exists steve added below // check for file exists steve added above