The churn study that turned into a product bet
Churn was climbing and nobody had a structured explanation, only loose theories. I ran the company's first churn study and the result became the growth hypothesis for the following year.
A product sold for one month of the year
Qulture.Rocks is a performance management and organisational culture platform. The best-selling product was Performance Review, run once or twice a year. Outside those windows, most clients had no strong reason to open the platform at all.
It was also a period of financial squeeze from the pandemic. Companies were cutting anything that looked like a nice-to-have, and we needed to make sure we weren't read that way.
Going into 2024, churn was rising. Several theories were circulating and none had been tested against the data. I decided to run the company's first churn study.
What the chi-square test showed
I ran a chi-square test crossing several client behaviour variables against cancellation.
What that test actually does, in plain terms
It checks whether an association exists between two categorical variables. Here, between a client's usage pattern (Performance Review only versus multiple products) and whether they cancelled. It compares what was observed against what you'd expect if there were no relationship at all, to separate a real difference from a coincidence in the sample.
The pattern came out clearly: clients using only the Performance Review product, the best-selling one, cancelled far more readily than those using other products alongside it.
Which made sense. If the review happens once or twice a year, the client has no reason to keep paying through the other ten months.
What this test proves and what it doesn't
Chi-square establishes association, not cause. It shows the two groups cancel at rates far enough apart that chance is an unlikely explanation. It does not show that restricted usage is the reason for cancelling.
There are at least two competing explanations the test alone doesn't rule out. The first is reverse causation: a client who has already decided to leave stops exploring new products, which would make restricted usage a symptom rather than a cause. The second is composition: companies that buy only Performance Review tend to be smaller with smaller contracts, and smaller companies churn more on their own, especially in a cost-cutting year.
I treated the finding as a hypothesis strong enough to steer a product bet, rather than a demonstrated cause. That's what the available data supported.
The second pattern, which I wasn't looking for
The same analysis surfaced something else: the most engaged companies were the ones where the HR person in charge kept constant contact with us. Frequent meetings, active questions, close follow-up.
That was Customer Success territory. I took the finding to the team, and they built a plan to pull more check-in meetings with the least engaged companies. A good finding doesn't have to be yours. It just has to reach whoever can use it.
What I chose not to do
The easy reading of the result would be to push cross-sell: if clients using more products churn less, then selling more modules fixes it. I didn't go there. In a cost-cutting year, asking for more budget is the worst possible moment, and it would treat the symptom without touching the reason, which was the platform sitting empty ten months a year.
The question I picked instead was: which product the company already owns can sustain usage all year?
The bet was the development plan. It was already born out of the Performance Review, and unlike the review, it makes sense to use it all year.
Every development plan could come out of a review, so it required no new sale and no contract change. And following someone's development happens continuously by nature. It was the only product in the portfolio that filled the empty window without charging an already squeezed client anything more.
What I built
I started by removing friction for people already using the development plan, on two fronts.
-
Notifications at every stage
I started notifying the user at each stage of the plan, to keep development alive through the year rather than only at review season.
-
Fill it in from where the person already works
The change with the most potential. Giving people the option to fill in the plan straight from Slack, removing the friction of opening yet another platform. If the problem was that people didn't come back, the fix couldn't depend on them coming back.
What I'd do differently
I didn't stay long enough to watch churn move. I left the company a few months after starting this work, and churn is a slow metric: the effect of an engagement change only shows up at the next renewal cycle, which could take up to a year. I don't have the final number, and I'd rather say so than imply otherwise.
The right tracking would have been by cohort. Split companies between those that increased engagement with the development plan, measured by fill frequency, notification usage and Slack adoption, and those that kept the previous pattern. Watch usage month by month as an early signal, since churn only confirms much later. And cross it with CS to see whether the more engaged group actually renewed more or signalled less intent to leave in check-in conversations.
And I'd test the reverse causation. All it took was looking at the timeline: did restricted usage show up from the start of the contract, or only in the months before cancellation? That single check separates symptom from cause, and I had the data to run it.
I like questions nobody assigned me.
This study wasn't in my scope. If your team has one of those sitting still, come find me.