It’s been a long time since my last post about professional topics…I decided to take a break from blogging last year to get acquainted with my new role as a product manager at a new company and spend quality time with Capi, a lovely dog (and now part of our family) that we adopted in August 🐕
During this time, I’ve collected plenty of ideas to share with you on my blog. One of the ideas that resonated with me is how to unveil the potential of Analytics to prioritize a backlog, a sometimes challenging task that, ideally, should be based on data. Needless to say Analytics should not be the only source of truth for prioritizing stories. Information can be also collected from interviews with end-users of your product, from the pre-sales and sales teams, and internally from your development teams, among others. However, Analytics can really provide you with some in-depth insights on how and how often your customers are using your application.
There is one more caveat that I’d like to mention when using Analytics to this end and this is the fact that it only reflects the usage of existing features. There is literally no way to compare the ROI of existing features with the possible benefits of implementing new features. So, once again, Analytics is a useful reference tool, but it cannot anticipate the potential of future implementations.
Defining the Goals
In order to make the most out of Analytics data, first, you need to make sure that the goals of your development project are clearly defined. That is, basically, which customer needs you want to meet (why somebody would use your app) and your definition of success (ideally with some target metrics). A good example could be: our users can order a customized meal in less than 2 minutes and get it delivered within the next 30 minutes. You can compare the defined metrics for different aspects of your app with the actual data usage provided by Analytics.
Another important step is to clearly define the user roles to be used in your stories and try to match them with the user segmentation/cohorts defined on Analytics. More on that below.
Google Analytics collects useful information about customer behavior that its AI component translates into trends. To visualize it, you can create different types of reports:
What is going on right now. How many active users are on your site, from where they connect, and how many pages and which ones are being viewed per minute. You can also get information on the devices that are being used (desktop vs mobile). Note: there are more categories that I’ve intendedly left out because they’re not so relevant for the purpose of this post. This report can be used as a reference, but it’s not very helpful to make decisions about priorities, as it only provides data based on a snapshot.
What you can use to get more accurate information about the average use are time ranges. Most of the cards allow you to select a date range (e.g. Last week, last month, last year, custom…). As a product manager, you can compare data from two different time ranges and find out if the current behavior is similar to historical behavior, if there is a new trend on how users are navigating your app, or, in case you have legacy stories/bugs in your project, to assess if it’s worth to work on an enhancement or bug fix (based on the number of visits) or if you should rather focus on other topics (opportunity cost: saying “yes” to something always means saying “no” to something else).
All about your users. How many returning users visit your app vs new users, their language and location (including city), browser, operating system, and screen resolution. How much time do they spend on average on your site and how many times do they visit it. You can also configure demographic and interest reports to get segmented data about gender, age, and interest category.
You can analyze the behavior of cohorts, which are groups of users who have something in common, and compare them to identify the differences between two cohorts or between the cohort and all users. Afaik for now, you can only create cohorts based on the acquisition date. However, within a cohort, you can add any custom segments that you have previously created in Analytics.
How do your users find your site/app: do they have a bookmark they use everytime they want to access your app? Do they google it? Do they use a referral link? This section can be especially helpful for planning marketing campaigns and investing in SEO (not in the scope of product development, but still interesting).
Here you can follow the user flow, which is extremely useful to design and update your app. You can filter by country (e.g. where do my German customers start), browser, language, and even screen colors! and then follow their journey throughout your app with 1st, 2nd, and 3rd interactions.
You can define activities that are important to measure the success of your app and track which users are completing them. There are macro-conversions (e.g. the user buys something on your app) or micro-conversions (e.g. the user signs up to receive a newsletter). As a product manager, you will be mainly interested in micro-conversions to keep track of how many users complete an end-to-end workflow.
Most Frequently Visited Pages
The All pages view in Analytics lists the pages that are visited more frequently. Based on this data, you can make informed decisions about prioritization. Working on the most visited pages first is a good way to implement the Pareto rule and make sure that you will focus on something that is relevant to a higher number of customers and/or sessions.
Backlog prioritization should be also oriented to increment the return of investment, which can be calculated as an intersection of the business value and the effort required to implement a feature. And here is where Analytics also comes into play. Stories that have higher business value (that is, impacts a higher number of users) and require lower effort (fewer story points) can be moved to the top of the backlog.
With this, I’m not saying that the customers should define the roadmap. The product roadmap should be planned by the project manager in alignment with the product owner. However, when features are translated into epics and stories, criteria like the number of customers using a feature can be used to decide which stories should be implemented first (provided there are no dependencies).