Waldo is using June to easily access high level product metrics and to measure the impact of their latest releases. This is important to decide which iterations should be prioritized. Shipping fast and being reactive is crucial for them.
The background
Every good product team knows that shipping new stuff is critical but only the best ones manage to keep doing that over and over again. Why? Because what you ship today can quickly turn into technical debt tomorrow if the code is not well tested.
Waldo helps mobile developers to create script-less end-to-end tests to fix bugs during development, not after.
The challenge
Waldo is a growth stage company that needs to ship fast and be on top of its paying customers. Quickly reacting to customer feedback, both implicit and explicit, is crucial for the team to decide what to prioritize next. Alongside, Waldo wants to constantly monitor high level product metrics such as Active Companies, New Users and Retention in a simple way.
In this context, making data-informed decisions (quickly) is an everyday task.
The solution
On a weekly basis Waldo needs to:
- Create weekly updates on high-level metrics for the rest of the company and the investors
- Start monitoring the latest features to validate the next iterations with data
Monitoring usage and retention
June works with templates which means that creating a report to monitor a core metric is very simple and straightforward. Waldo does weekly check-ins on Active Users and Companies as well as Retention.
Acquiring a new customer is said to be 5 times more expensive than retaining one. This is even more true when it comes to paying customers.
For this reason, the Waldo team constantly monitors the retention of its paid accounts to make sure they are constantly getting value from their product.
To check who’s at risk they use a Retention report that takes into account only paying customers and that considers a user retained only if a specific set of actions were performed within the week.
This check is done on a weekly basis looking into all the various cohorts of the table.
Monitoring features
When it comes to analyse a feature normally many dashboards should be created and assembled to get a sense of how it's being used. Instead, with June, all the relevant information are centralised in a single Feature report that can be created with just a couple of clicks.
When a new feature is shipped a new track event that maps to it is implemented. Right away, Manou creates a report to monitor how users are engaging with it. Then, on a weekly basis, he’s checking whether the expectations are being hit before briefing the team on the results.
For Waldo, giving visibility to the whole team on how their product is being used is very important to make sure everyone is aligned and purposeful.
Most of the time, learnings from analytics should be integrated with explicit customer feedback especially when it’s a matter of deciding whether to iterate or not on a feature.
For Waldo, getting to book interviews with customers, was a bottleneck because product designers had to wait days before receiving the right information from the tech team.
Now, choosing the right people to talk with is way easier. Product designers just self-serve the information they need from these insights which can be found in the Feature Release report.
The outcome
Now Waldo is more data-driven than ever before.
The decision to iterate on a feature or not are made fast.
The time between iterations has significantly decreased resulting in better reactivity.
Secondly, paid users are monitored much more closely in a simpler, less time consuming, way.
