Hey there,
If you’re new: Thank you for subscribing to the databeats newsletter where I publish guides for growth practitioners to drive data-powered growth.
If you’re not, well, I have something new for you: I’m now offering a lifetime membership to the databeats community – more info at the bottom of this post.
Last week I introduced the idea of Burning Questions.
Today’s post is the first in a series that explores the process of getting answers to burning questions.
Let’s get into it.
What data is needed?
Figuring out what data is needed to answer burning questions is an inherently collaborative process – Growth needs to involve Data or Engineering to figure out what data is needed either to arrive at a satisfactory answer or to run a data-powered experiment.
However, a keen understanding of the product, the underlying data model powering the app, and the org’s data infrastructure is empowering for a person hungry for growth. It enables them to have better conversations with their data and engineering counterparts and move fast without compromising on data quality.
Now, let’s use the same burning question we used earlier (in the previous post) to illustrate the process of figuring out what data is needed to get to a satisfactory answer:
“We’re acquiring a ton of users every day but very few end up hitting the activation milestone; what’s preventing the rest from performing the actions leading to activation?”
This also happens to be one of the burning questions I had during my time at Integromat. It was frustrating that we were acquiring close to a thousand users every day but less than 5% of those users were becoming activated and we didn’t have the data to figure out why.
I must add that the path to the activation milestone wasn’t straightforward due to the nature of the product. It had a relatively steep learning curve, particularly for users who were used to a product like Zapier which was a lot easier to use albeit a lot less powerful. Zapier offered a linear, step-by-step process to build workflows (they still do) whereas Integromat’s users would land on a blank canvas with endless possibilities.
This approach was rather novel at the time, but as a result, only a small number of users we acquired were able to create and activate (or turn on) their first workflow and hit the coveted activation milestone. On Integromat, workflows were called scenarios, a term I’ll be using quite often going forward.
The task at hand was to identify where in the onboarding journey were users getting stuck and dropping off, and then figure out ways to fix that to ultimately increase the activation rate (one of the core metrics for SaaS businesses).
Account-level Data
SaaS companies measure activation at the account or organization level rather than the user level, and depending on how one defines an activated account, it can take more than one user for an account to hit the activation milestone. I’ll go much deeper into account-level data in a future post.
Here’s the formula to calculate the activation rate:
Activation rate = number of activated accounts / number of confirmed accounts
A confirmed account is one that has completed the account creation process and the account details have been verified to ensure that the account belongs to a legitimate entity – a person or an organization.
In Integromat’s case, even though activation was measured at the account level and multiple users could work together inside an account, creating and running a scenario (or workflow) didn’t necessitate collaboration – an account owner could alone build a scenario and their account would be considered activated.
At the time, our goal was to get every new user to create their first scenario on Integromat. This included new users who joined an existing account that had already hit the activation milestone. However, and this is something we figured out later, a significant chunk of account owners did not actively use the product themselves but had someone else build scenarios on their behalf. This insight helped us optimize our onboarding and cancellation flows, eventually leading to higher activation and retention rates (we would proactively reach out to account owners who had canceled a paid plan because the primary user who built and maintained the scenarios was either a past employee or a freelancer who was no longer available).
An update on where I’m going with databeats
I’ve always been hesitant about turning on paid subscriptions, primarily because I don’t like to gate/paywall what I create. I spend a ridiculous amount of time crafting every piece and thwarting my reach doesn’t feel good.
Moreover, reaching new people isn’t getting any easier – quite the opposite, in fact. The tech overlords and doing everything they can to fortify the bulwark between creators and their audiences. Heck, even Substack (where I’m writing this) is moving in that direction (which is rather unfortunate).
But I decided to try paid subscriptions anyway because launching a paid community has been on the cards for the longest time, and doing it via Substack seemed like the easiest way to make it happen without overthinking things.
However, I quickly learned that a monthly subscription doesn’t make much sense for a community, especially one that’s just getting started. It takes a while for members to start deriving value and for the host to figure out how to deliver value consistently. This has also been my experience as a member of several paid communities.
Moreover, I don’t like the idea of asking people to leave the community if they choose to cancel for whatever reason. Attracting the right people to a paid community is incredibly hard. And if someone decides to spend their time and money to be in a community, asking them to leave – whether they’re contributing or not – just doesn't feel right (to me).
I prefer that people pay once to join and never leave.
It feels nice to know that even if a member isn’t able to derive immediate value, there’s time, and I need not worry about losing them. This worldview was reinforced when I joined a community last week that charges once and provides a ton of ongoing value. I don’t feel that I need to spend too much time in the community and am happy with whatever little bit I’m deriving from it. Most importantly, there’s something calming about paying once and not having to deal with all the burden that comes with a subscription (tracking renewals, collating invoices, retrying failed payments, and so on).
So here’s the deal:
Pay once to join the databeats community and never leave. You’ll get access to the private Slack community + jam sessions where community members come together to discuss projects and challenges + live conversations with expert practitioners. And you’ll get answers to all your questions about data and growth, of course.
Get a full refund if you’re not 100% satisfied. And no, you won’t even be asked to leave. I know that sounds a bit crazy but I’m confident that you will derive more value than you expect as long as you leverage what the community has to offer.
Substack doesn’t offer one-time payments so please use this link to join.
Or if it’s easier, you can choose the Lifetime tier on Substack and then cancel the subscription.
Still on the fence?
Read my story to know what makes the right person to be doing this.
Take a look at the databeats wall of love to know what others have to say.
Message me on LinkedIn if you have questions.
Finally, all posts will be free for everyone to read. And those who choose to support databeats with a subscription here on Substack will be directly contributing to our mission – to beat the gap between data people and non-data people for good. They will also get occasional posts with half-baked ideas and my writing and diagramming process, as well as quarterly updates on the progress and what I'm thinking next.