AbC — a strategic, bootstrapped data framework for Product Managers

7 min readJul 14, 2019

tl;dr: here’s the template I use for strategic data analysis. You’re welcome to use it in your company.

As a product manager, you know you need to be data-driven, data-oriented, and a data-ninja-warrior in general. What you’re not always told, is how. In this post, I’ll share with you my approach to doing so, which I call Adoption by Customer. Yeah, it abbreviates to AbC, if you’re into that sort of stuff.

A personal intro

When I started working at one of my past companies, the company had absolutely no data strategy. No analytics tools were implemented in the product (a web app) other than a very basic implementation of Google Analytics, that showed page visits and little more.

I was told that “analytics take precious dev time that should be invested on features for the customer, not for the product team”. And in any case, one of the executives proclaimed, “if you have any questions, just ask me. I know my users inside and out”. This scenario, while a bit extreme, actually describes quite a lot of early-stage companies. So how do you go from this to having a solid product data strategy?

Strategic analytics

Before we get going, I’ll explain what I mean when I say “strategic”.

One way to segment product work is to Strategy vs. Tactics/Execution. In Chess, strategy is a general long-term plan a player might have. I’m by no means a Chess expert, but in general, many times you’re aiming to have control over the center of the board. That’s a strategy. You also want to get your king to safety, barricaded by a wall of pawns. That’s a strategy. A tactic, on the other hand, is a very short-term set of moves, sometimes just one or two, that often (but not always) serve a strategy.

In product management, a strategy might be to focus on a specific market or customer type, or to invest in increasing the reliability of the product as opposed to building new functionality. A tactic might be to invest in a specific feature, or to run a bug sprint.

It is common for product managers to measure tactic moves. In this post, however, I’d like to discuss a broader type of analytics — high-level data around your product that can lead to strategic decisions: which modules should we focus on, and which should we leave untouched? Which segments of customers are our strongest, and which are weak? How can we increase adoption of certain features?

Bootstrapping your way to the data

The story above is meant to illustrate one thing — in smaller startups, a good data framework is one that gives you maximum value for minimum effort. You can spend days and weeks analyzing data, but that’s a luxury you only get as the company grows, when you can start hiring full-time analysts and BI people.

To get the data I needed, some politics was required to get the 1 dev-day required to add MixPanel’s free version to our app. I also learned to query our MongoDB database, with a 1-day online course that gave me most of the knowledge I needed. This, together with some fancy Google Spreadsheet skills, is really all you need.

Inglorious Spreadsheets

Step 1: the simple adoption metric

My Journey began with a simple need: I was working on a new mobile app for our customers, which up until then only used a web app. I needed to know that the app is being used by customers, and by how many. That number was easy enough to get using MixPanel: I defined usage as “The number of times a customer’s users logged into the app”, and defined the adoption threshold to be at least 3 log-ins.

The reason I used a threshold of 3 and not 1 is to remove any users that were just exploring the app once or twice, but then abandoned it.

This one simple metric was great. It showed that month by month, we were going from 20% adoption, to 40%, to 60%… We were on the right track.

Step 2: from a single figure to customer-level data

While “one metric to rule them all” is a great way to make sure your work brings value to users, it has one downside: it’s not very detailed. It doesn’t tell you who are the customers that are using it, or why.

As a PM, you want to be doing everything in your power to help the product. Yes, it means speccing out features and working with dev, but it also means giving product education sessions to sales; thinking of new advertising campaigns with marketing; making sure help center articles for your product are useful to users; and so much more.

As for my mobile app, I wanted to know more, so I converted my adoption metric to a spreadsheet:

This spreadsheet, while simple, is a combination of two data sources: our customer data (typically stored in your DB), and usage metrics, in my case derived from our MixPanel dashboard. I crossed-referenced the sources using the ugliest of vlookups (a spreadsheet function), according to the customer’s ID.

This gave me so much actionable data:

which customers are using it? Next time I wanted to talk to one of them for feedback, it was a matter of a single filter for “using”.
Which customers are not using the product? I quickly whiped up a survey and asked them why that was. Does it lack important features? Do you not need it? Or did you simply not know about it?
Is the app more used by newer, or older customers? If it’s adopted by newer customers, it might mean that your sales team is doing a great job pushing it, but that support/success are not doing enough. In that case, you can run a quick product education session for them.
Which customer success manager has the most customers using the app? They might be in for a shoutout in the next meeting!
Which success managers don’t push it hard enough? They might not be aware of its advantages! Let’s have a quick chat.

The details change according to your specific use-case, but you can already see how with very little effort, we added a lot of depth to our analysis.

Step 3: cross-product extravaganza

The process above, in all its simplicity, was so useful, I quickly did the same for all of our products. In practice, it was a bunch of MongoDB scripts and MixPanel queries I had saved and needed to run once a month. It was very manual, but actually took no longer than one hour to run.

It was a 30-sheet monster of a spreadsheet, but it worked magic. I’m attaching my template, and you’re more than welcome to use it yourself. The added value was huge:

every single product manager got to enjoy the same insights I have
we could now have a “score” not just for each product, but for each customer — depending on how many products they used. This also allowed us to segment our customers better
customer success managers got insight into their customers: they saw clearly which customers were not using the full potential of the system and were in risk of churning
in roadmap discussions, we could easily get insight into our core products, those used by 70%-90% of customers, and make sure we give them the attention they deserved.
we could also see which products are underperforming, and decide whether we wanted to double-down or ditch them.
this also helped with dev allocation. Do we really want an entire team working on a product that serves just 15% of our customers?

Step 4: track

At that point, the data gave us a wide snapshot of our product lines. The next step was to make sure we could track the changes in that data.

This meant tracking each product’s adoption rate and plotting a month-over-month chart of it. this gave visibility into which product are improving, which are not, and which are actually deteriorating. It doesn’t solve the need to find out why that is, but it’s a great start.

We also wanted to make sure we don’t lose any data, so that if we later want to analyze the evolution of specific customer segments, we could, so each month I actually created a new copy of the spreadsheet, and kept the old versions on record. This came in handy when a success manager suspected a certain customer was churning, and wanted to compare their stats today to that from a few months ago.

Step 5: automate

Once the company grew and a BI team was recruited, an old dream could finally become a reality — we could at last take this big, ugly spreadsheet, and replace it with a shiny new analytics dashboard, which updated in real-time, and which we could segment and analyze a lot easier than we could the spreadsheet.

In just a couple of years, that small company in which “data” was once almost a profanity, now had a real data-driven product organization.

That’s it, hope you enjoyed! Let me know what you think in the comments below, and don’t forget to dish out a few 👏 👏 👏!