I’m gearing up for analytics within Cushion to get a sense of whether certain flows and features are actually used by folks, but before I get that rolling, I figured I’d spend a casual Thursday night on the couch doing what anyone else would be doing—querying the database for metrics that I can measure to validate my assumptions.

I started by spinning up a follower database to provide a read-only database that mirrors the production database, so I can’t mess anything up. While the database was provisioning, I listed my assumptions about Cushion. This was actually a really helpful exercise to get the assumptions down on paper, but also provided guidance on how to write the queries. I tried not to think in terms of number-based questions, like “How many users created workloads?” I wanted to take a stance, then let the data either prove me right or wrong.

This resulted in a list of assumptions, like “Very few people use workloads.” It essentially leads to the same query as figuring out how many users created workloads, but I find myself more eager to discover the result. The obvious downside with this approach is that I’m incredibly biased when it comes to reading into the results. That said, I’m definitely not considering these results to be the last word when it comes to making a decision—they simply highlight areas I should explore further.

While in-app analytics will take care of seeing where new users get hooked or drop off, I focused these queries on active subscribers—the folks who were already hooked and continue to pay for the service. This provides me with much more accurate and useful metrics because it’s not skewed by the countless folks who sign up, click around a few times, and never return. I do want to know why those users drop off, but I won’t find out by querying the database.

To improve the results further, I focused on various timespans rather than all-time. This helped weed out any false positives, like if someone created a few workloads when they first signed up years ago, but none since. The topic of the query helped determine the length of the timespan. When validating whether folks tracked time, I looked at the past month because people who track time do so often. For other topics, like vacations, I looked at the past year because vacations are most likely few and far between—especially now.

Because I love to spreadsheet, I created one for the results. In the first column, I listed all of the features from my assumptions. Then, I created a column for the number of subscribers who actively use those features. The third column calculates the percentage by comparing the previous number with the Cushion’s total active subscribers. To make the results more visually noticeable, I applied conditional formatting to color the rows from green to yellow to red based on the percentage.

Surprisingly, the results were more or less spot-on with my assumptions. Better yet, the features that I feel best represent Cushion are the ones that the majority of subscribers use. Conversely, the features that never seemed to fit are the ones that barely anyone uses. While these two ends of the spectrum represent the green and red rows, the yellow ones were especially interesting. Instead of viewing any of these features as ones I would potentially deprecate for new users, the results simply suggest that I shouldn’t focus on them as standout features when describing or marketing Cushion.

Now that I have the results, I can start thinking about surveys and user-testing for follow-up questions. Also, aside from the assumptions I was able to measure with queries, I still have just as many assumptions that can’t be measured this way, like “Graphs and data tables should be two separate views”—a scandalous idea if I’ve ever seen one. I’m hoping to take this opportunity to establish a rhythm with surveys for folks, so I can continue learning about Cushion’s usage. I’ll admit—I was worried about what I’d learn from these queries, but now I’m actually excited. The more I learn, the more focused I feel.