How I Use Data To Build Better Products

Joe Procopio
Jul 8 · 8 min read

If an organization isn’t using data to develop and grow its products, then its days are probably numbered.

But while everyone talks about data, rarely does anyone explain what to do with all of it. So companies wind up skipping a data-driven approach because there isn’t any time. Or they use data incorrectly and get a false sense of potential success. Or they go totally data-driven and leave the human element out.

Let’s fix that, because every new product, every new feature, every growth experiment, should be using data to make decisions.

The science of data is made out to be far more intimidating than it really is. It’s also overhyped as a kind of nerd quest that will make selling tons of product as simple as punching a magic algorithm into a computer.

The truth is it’s easier than ever to collect, analyze, and react to data — from sales data to performance data to marketing data.

I’ve been building products with data since 1999 — before Google Analytics, before Hubspot, before anyone had an API. I’ve gotten it pretty much down to a science at this point, and I can get a decent data analysis out of a rock and some string like MacGyver.

Right now, as you’re reading this, I’m using data to build two completely different product lines. One uses a lot of data, the other uses just a little. I’m going to use each of these as examples in the hopes that you can find your happy data place somewhere in the middle.

In the first scenario, let’s call it the “Lite” scenario, all I’ve got is a collection of unrelated web pages that show me basic usage stats. But one of those stats is revenue, and when I have revenue, I have the one single truth. I can trace everything else back to dollars.

I’ve got no APIs, so what I have to do is check in regularly to get daily, weekly, and monthly stats, plus any reference points I want to track for any experiments I want to run. All of this goes into one massive spreadsheet with a dozen tabs.

It’s not automated. At all. But once I have the structure down, all it takes a few minutes to maintain it. Plus it’s fun. I geek on this shit.

In the second scenario, the “Heavy” scenario, I’ve got a software platform that cost millions of dollars to build and is constantly being developed, upgraded, and maintained by a team of excellent software engineers. Everything is in the cloud, it’s totally flexible, APIs everywhere, and it even has a replicated read-only database that I can hit with SQL in real time and not screw everything up.

In the Heavy scenario, all I need to do is fire up something like TablePlus or SQL Server Management Console and run stored SQL statements to generate reports.

In both scenarios, I have a weekly Data Day. That’s when I spend an hour or two aggregating all my data and running analysis on every bit of it — which I’ll describe over the rest of the post.

In the Lite scenario, I’m logging into various websites and copying the most recent numbers into the spreadsheet. I don’t get revenue until the end of the month, so I’m doing a lot of extrapolating as to what that dollar figure will be so I can grade performance continually in “real time.” Then I have a monthly Revenue Data Day when I get the revenue numbers.

In the Heavy scenario, I’m getting revenue in real time, so I get to spend much more time on analysis.

Once I’ve collected all my data, my analysis serves to:

  • Catch errors — I’m looking for spikes in the data that suggest glitches in the software, the process, or some external market factor I don’t know about yet.
  • Catch opportunities — I’m looking for patterns that suggest my customers are doing something new and different.
  • Keep score — I’m comparing incoming data to my previously defined expectations for new products, new features, and any growth experiments that are currently underway.
  • Make plans— I’m rewriting goals, dreaming up new ideas for the product, and considering new experiments.

Here’s what I’m doing during Data Day analysis:

The first set of data I look at is sales. I total the entire revenue number first to get a sense if this was a good week or a bad week or an inconclusive week. This will color the rest of my analysis, dictating if I’m looking for problems or opportunities or both. If any number is way off, I’ll skip down to the end and do Forensics, then come back.

The next thing I want to understand is where those sales came from, so I trace the revenue back as far as I can by using the data to answer these questions:

  • How many customers were in a position to buy, but ultimately decided not to?
  • How many customers were in a position to buy, but didn’t get to the offering?
  • How many customers came into the “store,” but never got into a position to buy?
  • How many customers were made aware of the store, but never entered?

Then I take all of the breakdown and use it to confirm or adjust my goals for the month, the quarter, and the year.

I get the results of all this analysis to discuss with the executive team. If we need initiatives to adjust our focus, we use this analysis as our guide.

The next step is to compare productivity against revenue to get performance. I need to confirm where we’re strong, where we’re weak, and that we’re burning efficiently as we grow.

These are like long-term growth experiments, except I’m looking at things we’re already doing and customers we already have. I’m looking for patterns in their usage that give me hints as to which features and which customers we should be focusing on.

This analysis sets up a lot of the Growth Experiments I’ll be going over next.

For example: At Spiffy, my performance data analysis led me to discover that a good number of our customers were declining a suggested and needed upgrade during their service, but then they’d add the same upgrade the next time they booked their service. We were missing some of those upgrades, right? The ones who forgot about it. So that led to an experiment to prompt those customers to add the upgrade when they book their next service so they won’t forget.

The experiment I mentioned just now is one of the most basic I can run. The likelihood is very high that the experiment will succeed, but we’ll test it first anyway because you never know what you’ll find out.

On the other end of the spectrum, I’m also in the middle of testing a new product offering with a large corporate partner that has much broader implications and is a lot trickier. More reward, more risk, same analysis.

I can use the same set of sales and usage data for most of the growth experiments I want to run.

To run these experiments, I narrow down a customer segment, in this case by location. The size of the sample should be small enough to not be painful if we mess up, but large enough to matter. In fact, I’ve already had to add locations because the sample size wasn’t statistically significant. Then I run the experiment.

I usually check in on growth experiments daily or even a couple times a day in the beginning, to flesh out facts like my sample size is too small. Then I try to get to success or failure as quickly as possible.

While all the previous data analysis is about increasing the size of our market, marketing data analysis is about increasing the size of our megaphone to the market.

For the Heavy scenario, we’ve got Hubspot and MailChimp and Google Analytics and all the social media accounts and everything is integrated and automated. In the Lite scenario, I’m just grabbing metrics from the ad server and from Google Analytics and throwing them in one of the spreadsheets. Google’s reports leave a lot to be desired, so I do it myself.

Marketing data analysis is actually just another review of the sales and performance data, but this time I go all the way back to first interaction, or where the customer first became aware of the product offering. I’m looking at impressions, email opens, click-throughs, and conversions, all compared to ad spend. I’m adding the cost of acquiring the customer to the cost of serving the customer.

The main difference with this analysis is that if marketing data is telling me to change something, that usually means changing either the marketing channel or the messaging or both. It’s only in rare cases that marketing data analysis leads to a product change, usually when my customers are confirming a hunch I already had from doing all the prior analysis.

With marketing data, I’m also running experiments, but these are growth hacking experiments, not growth experiments. They’re A/B testing offers, discounts, and messaging. They’re varying the channels, the audience, and the spend. But it all eventually ties back to sales and revenue.

Forensics is the special projects part of Data Day. When I start to see patterns I like or I don’t like, especially when I don’t like, I pull the corresponding data and comb through it to figure out what to do.

This usually means drilling down to and eventually combing through individual records— maybe single transactions, or customers, or product specs, or even code.

For example: In the Heavy scenario, we noticed anecdotally that chargebacks were becoming an issue. We didn’t have any idea where the spike came from, so I spent a couple hours at the end of a data day pulling transaction data that correlated to chargeback data and drilling down into the individual transactions themselves.

Turns out it was a combination of a single product, a single feature, and a couple customers exploiting a loophole. Rather than spend thousands of dollars on sophisticated software to sniff out bad actors with machine learning, we just closed the loophole. Problem solved.

Thanks, Data Day!

When I think about saving thousands of dollars with a few hours of data analysis, it almost overshadows all the additional revenue these product changes generate without the days and weeks of guesswork trying to figure out how to grow.

Data-driven product development doesn’t have to be scary and it doesn’t have to be all-in. There are a lot of ways that using data to build and grow our product is going to add to the bottom and top line, all without having to hire a data science team.

Joe Procopio

Written by

I’m a multi-exit, multi-failure entrepreneur. Building Spiffy, sold Automated Insights, sold ExitEvent, built Intrepid Media. More about me at joeprocopio.com