In today’s era of cheap metrics, highly quantitative marketing, and growth hacking, everyone’s talking about funnels. The most colorful explanation of a startup funnel is easily Dave McClure’s Startup Metrics for Pirates, which goes something like this: (1) user signs up (2) user starts using the product (3) user sticks around (4) user convinces friends to use product and, (5) user pays for the product. AARRR!
Unfortunately, this framework often breaks down for B2B companies. Why? Too often, they apply user-centered thinking to problems that are fundamentally account-centered.
For example, let’s put ourselves in the shoes of a hypothetical growth manager at a SaaS startup, Simon. Simon just got a job at TeamO, a product that allows developers to share their feelings via a git-based workflow. The first thing he does is throw together analytics to see what the 3-month free-to-paid conversion rate is for new signups. Here’s what he gets:
It’s plummeting! Apparently, something terrible has happened over the last year, and drastic changes are in order.
Relax, Simon. You’re looking at things the wrong way.
See, underlying that fall in per-user conversion rates is a function of another trend — TeamO has been marketing to bigger companies, and new accounts are signing up more users than older accounts. Because companies only need a single person to throw down a credit card, that increase in users per company is driving down the frequency with which individual users pay. In fuzzy math terms:
[Account conversion rate] = [User conversion rate]/[Users per account]
When Simon starts looking at free-to-paid conversion on a per-account basis, it looks pretty healthy:
Crisis solved, hey Simon?
Moving from a user-based funnel to an account-based funnel isn’t straightforward, but if you’re building an enterprise product, it’s necessary. Getting started is a three-step process:
Step 1: Group your users
There are two paths to take here, and the correct choice will largely depend on how teams use your product and how willing you are to play with your data model.
Option 1: Automatically group based on the information your users provide
If you’re building a social product, there’s likely some functionality that allows users to create teams (or ‘organizations’). Instead of looking at a per-user funnel, you’ll study your team funnel: how do teams get formed, when do they ‘activate,’ when do they start paying? The great thing about this approach is that the data is already there for you: since you’re leveraging existing groupings to find teams, you can get started on analysis with relatively little setup.
Option 2: Manually group your users into accounts
While this can result in cleaner groupings, it requires more work — you’re going to have to write and run a grouping algorithm on your data. I like using email domain as a starting point and applying the following three rules:
- Each account must have at least one domain associated with it
- A domain can only belong to a single account
- Each user associated with an account must have a domain associated with that account or a generic domain
Step 2: Summarize lifecycle events for groups
As a best practice, you’ll want to use the earliest date of an event across all members of a group. For example, let’s say you observe the following string of events:
- In January 2017, firstname.lastname@example.org signs up for the product.
- In February 2017, email@example.com signs up for the product.
- In July 2017, firstname.lastname@example.org signs up for the product and starts paying for it.
Somewhere in your analytics database, you should have a group called ‘fizzle’ with a signup date of January 2017 and a payment date of July 2017.
Step 3: Analyze time to payment on an account-based level
That ‘admin’ user is an interesting data point — looked at in isolation, it looks like a single user that signed up and started paying for the product in less than one month. Seeing lots of users that fit that pattern may lead you to invest heavily in signing up new users in the hopes that it will have an immediate impact on revenue.
However, by looking at team-based cohorts, we see a more realistic and sobering picture: users acquired today won’t affect revenue until six months down the road. The correct way to look at this is to look at the signup date and payment date for the ‘fizzle’ group we created in step 2 — here, we see that the company has a sign up-to-payment timeframe of six months (January to July).
If that’s a trend, it means that short-term revenue growth is going to have to come from increasing the monetization of existing users and shortening the time-to-payment cycle, not increasing the number of signups.
If you haven’t, read Dave’s slides. Just remember, you can’t afford to only think about the lone pirate— you’ve got to think about the entire crew. Especially the crew member with a credit card.