Know your high performing customers
Do you struggle trying to decide what to build next? What needs to go on the roadmap to really move the needle on customer acquisition and growth? One day a couple months ago I was scrolling through Twitter when I saw this tweet:
When I read this I was immediately interested in running these numbers over @ Crunchy Data. So, I reached out to our head of Growth, Christopher Winslett and asked if he could help, and the data we found not only helped us identify ways we could improve the current experience, but sparked ideas and opportunities for our roadmap into the future.
Case Study: How we evaluated our high performing customers
At Crunchy Data we are building the best managed Postgres experience in the market. This is important context for us to dig into an example of how we used the information gathered from our top accounts to guide improvements to our product roadmap.
All of our top customers use more than one database.
This is a common use case for companies, but there was not a single top account that didn't leverage multiple databases.
Staging, dev, or test databases
Databases for specific teams or products
Okay, interesting data point. People use multiple databases. Big deal right? This is the hard part. How do you use quantitative data to identify insights you can use to qualitatively improve your product?
We focused on two things:
What are our customers saying to Support?
What opinions we hold about our product are not being met?
Let's dig into the insights we identified and how these two points helped us get there.
Problem: Teams need to be able to identify if a database is a production database.
This problem was identified from a strong opinion we hold about our product. We want to provide the best developer experience for managing a database in the market. Specifically:
We will keep customers from shooting themselves in the foot.
Currently all UI is uniform for our databases in the dashboard. The only indication for what database you are in is the name in the nav bar, and occasionally somewhere on the page. When you have a team of developers hoping between staging, test, and production databases we can do a better job keeping these team members from accidentally thinking they taking an action on one of their non-production databases.
Our solution? Let teams identify which databases are considered production databases and make sure that is clear on every page used to manage that database inside of the dashboard.
Problem: Allow grouping of related databases
This problem was identified through correlation with support tickets we received about confusing navigation. At the time we were unsure of what caused the confusion, but now that we are seeing this data we can make improvements that will allow grouping related databases and reducing the number of clicks/pages are required to move between related projects.
An exercise like this not only helps you find problems, but also opportunities. I am not going to dig into these specifically, but just to share what they might look like when you are doing this we had a couple big questions on where we could start to position our roadmap.
Can we make using a database for local development better?
Can we make it easier to copy production data to seed staging, test, and development data?
Go evaluate your top customers!
When building a product your roadmap is always being pushed and pulled. You (the business, the product managers, the developers, etc) are pulling ideas to be built into the product, and at the same time your customers are pushing the product where they want it to go. Your job is to find a way for these to work together.
Exercises like we just went through are great ways to do this. Observe how your users are pushing the product into their use case, and go pull data that will help you build a better product to support them.