Deviniti More Than Doubled Trial Conversion by Finding the One Behaviour That Predicted It
Deviniti Apps builds software for the Atlassian ecosystem. One of its teams had loyal customers and a steady stream of trials, yet fewer than three in ten of those trials were becoming customers. The fix was not a bigger funnel or a longer roadmap. It was a single thing successful customers did in week three that nobody had noticed.
Book a free intro call →
This is the pilot inside a wider Product Operating Model transformation at Deviniti Apps. Rather than change every team at once, leadership and ProductTrio put the method to work on one team, Luna, which looks after the Actions for Jira Service Management app and one other product, against a business number that mattered. What the pilot proved became the template for the rest of the organisation.
Strong engineering, and no line from business goals to product decisions
Deviniti Apps, the product side of Deviniti, had several successful apps in the Atlassian Marketplace, real technical depth, and an established position in the ecosystem. What it did not have was a product strategy connecting business goals to product decisions. Teams worked from technical roadmaps rather than a product vision, and success was counted in features delivered and development velocity. That made everyone busy and nobody certain: no one could say which of last quarter's releases had moved anything.
The market was not standing still either. The Atlassian ecosystem had become far more competitive, which raised the bar on how fast value had to reach customers and how clearly a product had to differentiate. A build-and-ship rhythm was no longer enough to keep up.
Measure the team, then the business, then the product
Before changing how anyone worked, we measured where the team actually stood. Four members of the Luna team answered a Product Model Maturity Survey in May 2025, an earlier and shorter draft of the one now published as a ten-minute assessment. Scored on the same four-level ladder, the team came out at 58.5 out of 80, which puts it in the product team band rather than the delivery team band. The headline number turned out to be the least interesting part of it.
The structure of a product team was already in place, and the team agreed about it. Every question about the trio came back at the top of the scale from all four people: who does what, which ceremonies they plan and learn in together, and how value and viability are shared between them. What was missing sat one layer underneath. Focus scored lowest. All four said their planning was guided by effort estimates, story points or hours, which was the single weakest answer in the survey, and half named velocity and story points as the metrics they watched most closely.
The second signal was disagreement. On five questions the four answers spanned the full width of the scale. Asked how the team shares accountability for outcomes, two said each role focuses on its own deliverables and two said the team collectively owns success metrics and learns from failures together. Asked how often priorities move on outcome data, two said continuously and two said rarely. A team whose members describe how it works in opposite terms does not have a shared operating model yet, whatever its org chart says. That was the gap the pilot existed to close.
Then we went to the business numbers rather than to the backlog. Deviniti's own Tableau data had to settle one question first: was this a retention problem or an activation problem? Retention came back healthy. Revenue from new customers consistently exceeded churn, and every customer segment stayed beyond twelve months. Activation was where the money was leaking. Around thirty trials arrived each month, and fewer than three in ten converted, against historical peaks above fifty percent.
“We had healthy trial volumes of around 30 monthly signups and zero churn issues, but new customers just weren't activating. We needed to understand what successful customers do differently during their trial period.”
Product Manager, Luna team at Deviniti Apps
Six hypotheses, and one that came back at a hundred percent
We split trial instances into two cohorts in PostHog: the ones that became paid licences, and the ones that never did. Then every hunch the team held went through the same three steps, so intuition had to survive contact with data before it could shape a roadmap.
Say what you think is happening
- Written from intuition or customer feedback, in plain language. For example: “Users don't find actions on the Customer Portal, which is why activation is low.”
Go and look
- Path analysis in PostHog on how many trial users reach the portal, and how many click an action once they are there.
Keep it or kill it
- A number the team has to accept either way. In this case, only 15% of portal visitors clicked an action. Five of the six hypotheses died at this step.
Every single customer who made actions available to end users on the customer portal during week three of their trial went on to pay. Not most of them. All of them.
One behaviour, and a hierarchy that connects it to the money
A perfect predictor is only useful if a team can act on it. So the behaviour became the target, and the target was tied explicitly to the business result it was chosen to predict.
- Interviewed trial users in their third week, to find what actually stopped them making actions available.
- Ran experiments on the discoverability of that setting.
- Had customer success reach out to trials during week three, rather than at the end.
- Measured each change in PostHog against the product outcome, not against whether it shipped.
The behaviour hit its target. The business number it predicted overshot.
- Outcomes are measured weekly, not reviewed quarterly.
- Experiments run before full implementation, and are judged on the product outcome rather than on delivery.
- Learnings are written down, so the next team starts from evidence instead of from scratch.
- The framework was documented and handed to the rest of Deviniti Apps: product outcomes on three-month cycles, product objectives set annually with quarterly alignment, business outcomes on a one to three year horizon.
If your teams ship fast and nobody can say what moved, the missing piece is a behaviour
An output-driven team is rarely a lazy one. It is usually a team that has never been handed a target it can actually influence. Feature counts and velocity are easy to measure and hard to argue with, which is exactly why they survive. The way out is not a better roadmap format or another planning ritual. It is finding the one user behaviour that predicts the business result you care about, and then pointing everybody at that.
Deviniti found theirs by comparing the customers who paid against the customers who did not, and by being willing to kill five hypotheses to keep one. The pilot was deliberately small: one team, one metric, one quarter. That is what made it cheap enough to try and convincing enough to scale.
Shipping fast, but nobody can say what moved?
Book a free intro call and we will look at where your business goals and your product decisions have come apart, and which single team is the right place to start.
Book a free intro call
.svg)
.svg)
