Metrics-Based Teams
Give each team one outcome metric instead of permanent ownership of a feature
- Difficulty
- Advanced
- Time to result
- ~months to results
- Steps
- 5
- Confidence
- 99%
Metrics-Based Teams replace permanent feature ownership with accountability for a single measurable outcome. Rather than create a leaderboard team, Duolingo creates teams for outcomes such as time spent learning, retention, ad revenue, or subscription revenue. A metric team may change the leaderboard or any other relevant feature, but its success is judged by whether its assigned number improves. The team runs many A/B tests and uses daily measurements so it can see effects quickly and avoid the attribution delay of monthly windows. As Duolingo expanded to roughly 40 or 50 teams, it grouped related teams into areas such as monetization and growth. The mechanism keeps product work connected to results while adding a coordination layer only when the number of autonomous teams becomes unwieldy.
Origin
Luis von Ahn said Duolingo discovered metrics-based teams after hiring its first experienced engineering manager and retained the model as the company scaled.
Core principles
- 01Organize around outcomes rather than features
- 02Give each team one metric to improve
- 03Let teams change any relevant feature
- 04Use rapid experiments to attribute impact
- 05Group related teams into areas as the organization scales
How to run it
- 1
Select the outcome
Choose a metric that represents a real user or business result, such as retention or daily revenue. Avoid naming a feature as the team's purpose.
Pro tip Use a metric that can move through several different product interventions.
Watch out A narrow activity count can reward motion without improving the outcome.
- 2
Create clear ownership
Assign one team responsibility for improving the metric. Give it enough cross-functional capability to design, build, and evaluate changes.
Pro tip Keep one primary metric even when the team monitors guardrails.
Watch out Multiple primary owners weaken accountability.
- 3
Open the feature surface
Allow the team to work on any feature capable of affecting its metric. Treat features as shared instruments rather than organizational boundaries.
Pro tip Define coordination rules where several metric teams may change the same feature.
Watch out Feature fiefdoms can block the experiment most likely to improve the outcome.
- 4
Experiment on a short cycle
Run controlled tests and measure the assigned outcome on the shortest meaningful interval. Duolingo favors daily measures because they speed causal learning.
Pro tip Choose an interval that is fast without becoming unstable or seasonally misleading.
Watch out Changing several variables without controls makes attribution difficult.
- 5
Scale into areas
When many metric teams create coordination noise, group related outcomes under a broader area such as growth or monetization. Preserve metric ownership inside the area.
Pro tip Add the area layer only after the autonomous-team model becomes a coordination problem.
Watch out Premature hierarchy can recreate feature silos and slow experimentation.
In the wild
Duolingo's first metrics-based team focused on whether users returned every day. It improved the streak mechanic and related product experiences rather than owning one fixed feature.
→ The company reported one and a half million daily active users with streaks longer than a year at the latest number Luis could disclose.
After the number of teams became a 'goat rodeo,' Duolingo grouped related teams into areas. Its monetization area included separate teams responsible for daily ad revenue and daily subscription revenue.
→ Related teams gained a coordination layer while retaining responsibility for distinct outcomes.
Common mistakes
Naming teams after features
Feature ownership encourages teams to improve their territory rather than the result the business needs. Start with an outcome metric.
Using a slow measurement window
A monthly metric forces the team to wait too long to assess a test. Use the shortest interval that remains meaningful.
Leaving dozens of teams ungrouped
Autonomous metric teams eventually create coordination overhead. Group related outcomes into areas without removing their direct accountability.
Is it for you?
Best for
Product organizations with enough users to run frequent controlled experiments across interconnected features.
Not ideal for
Very early products without reliable metrics, sufficient experiment volume, or a clear product-market fit target.
From the transcript
“we do not do feature based teams we do metrics based teams”
“the only thing they do is they have this one metric and every quarter it has to increase”
“when we care about a metric that we want to optimize so a metric could be daily revenue or or you know whatever it is…”
From the episode
#607: Luis von Ahn, Co-Founder and CEO of Duolingo — How to Be (Truly) Mission-Driven, Monetization Experiments, 10x Growth, Org Chart Iterations for Impacting Metrics, The Intricate Path to an IPO, Best Hiring Practices, Catching Exam Cheaters, The Allure of Toto Toilets, The Future of Duolingo, and How to Stand Out in Your Career