A few weeks ago I was preparing for user interviews on a product I’m working on. Before talking to anyone, I wanted to know which questions were worth asking and which ones the data could already answer.

That meant reading the product analytics first. Replays, events, errors, funnels — months of data sitting there with no analyst on the team. I started with the metrics that looked important, retention dipping here, feature adoption low there, and spent a while staring at numbers that described what happened but gave me no real direction on what to ask next.

The risk of skipping this step is real. Without it, you walk into interviews asking questions the data already answered, and spend 45 minutes confirming things you could have known beforehand. That’s time the user gave you that you didn’t need to ask for.

This is what helped. Most of it applies whether or not you use the same tool.

How I explored the data

I started with where users were frustrated: rage-clicks, repeated failed actions, dead ends, rather than metrics. Metrics tell you what happened. Behavior tells you where to look.

At this scale, doing it manually wasn’t realistic. I was using PostHog, which has an AI layer that reads session event streams and summarizes behavior without watching recordings one by one. It also wrote the SQL queries I needed. I read and verified them.

Before touching the data, it created a form, asking how I define discovery, who the analysis should cover, whether I had a hypothesis. Only after that did it run the queries.

176 days. Wrong number. Didn’t know it yet.

First investigation: are users finding the new features?

First finding: 176 days from signup to first use. Looks like slow discovery. So the next question: messaging problem? Feature doesn’t fit the workflow? I asked the AI, got reasonable answers both ways, went back and forth for a while, nothing landed.

The tool flagged it before I did. Before touching the data, it came back with one more question: when did each feature actually launch?

I gave it the dates. Turns out they went live a few months back. Maximum possible lag: around three months, not 176 days. That figure was measuring signup-to-now, not launch-to-first-use. Most users signed up before the features existed.

The tool was confident. It had no reason not to be. I hadn’t given it the one fact that would have changed everything.

83% never tried it. Two completely different reasons why.

When the framing changed, the picture changed. 72% of users who try the main feature come back, averaging 17.8 uses. The product works. But 83% never try it at all.

A feature that delivers real value once discovered is not reaching the people it was built for.

“Users don’t like it” and “users can’t find it” look the same in aggregate but don’t have the same fix. Getting this wrong means redesigning a feature that didn’t need redesigning, or running a messaging campaign when the problem was always placement.

The discovery path made it more specific: 60% of users rage-clicked right before finding the feature, stuck somewhere else, clicking around in frustration, stumbling on it by accident. Suggestive, not certain. But it shows the feature isn’t findable through normal use. You have to stumble on it.

The structural reason is placement. The feature lives behind a tab that isn’t open by default. You could use the product a hundred times and never see it. Not a user behavior problem. A placement decision that was never questioned, and one that’s suppressing adoption of something that already works.

Three pieces of context shifted the entire analysis

When I fed PostHog AI actual documentation and product specs, the analysis changed. Not because the data changed because the AI understood what the feature was supposed to do and how the user flow was designed to work.

In practice: before asking anything about the feature, I pasted in the product spec, the user flow description, and the design guidelines. Not summarized. The actual text. That’s when the output stopped being generic.

Without that context, it was pattern-matching against generic behavior. With it, it could tell whether what users were actually doing matched what the feature intended. That gap is where the real diagnosis lives.

Launch date changed the measurement. Placement changed the hypothesis. Product specs made the output specific enough to act on. That’s the part I’d do first next time.

What the data decided, and what it left open

By the end I had two very different types of findings.

The first: users can’t find the feature. Placement, rage-click path, limited newsletter reach all point the same way. No interview needed. It’s a placement fix.

The second: 28% of first-time users don’t return. Quality problem or trust problem, the data can’t tell which. A placement fix and a quality fix are not the same investment, not the same timeline, not the same team. One of them is the wrong answer.

That’s what shaped the interview plan. Who could actually answer the questions still open.

One target: the power user who started on day five, uses the feature hundreds of times, likely got colleagues to try it. The interview goes straight to: walk me through the first time you tried it. What were you doing. What did the output look like. What did you do with it. Data confirmed this person exists, the interview reconstructs why it worked.

Another target: the user with the most rage-clicks in the entire base, over a thousand, who has never touched the feature. The question isn’t “did you know this existed.” It’s “when something isn’t working, what do you do.” Watch where they go. Don’t point to the feature first.

Interview design follows from the hypothesis. Specific moments, not general impressions. “Have you ever sent an AI-generated analysis directly to a client?” tells you more than “what do you think of the quality.”

Before you talk to anyone

Without the data work, interviews confirm things you already know. I could have spent 45 minutes with a user finding out the feature is hard to discover — the rage-click data had already shown that.

Rank your hypotheses by evidence strength before talking to anyone. What’s confirmed doesn’t need interview time. What’s only suggested, a pattern that could mean two different things, that’s where interviews earn their place. Design questions specific enough to tell the two interpretations apart. If the answer would be the same either way, it’s the wrong question.

Match who you talk to with what you’re testing. A power user and a frustrated non-user aren’t just two data points. One shows what worked. The other shows what failed.

The split looks like this:

For each hypothesis: if this were true, what else in the data would also be true? If you can confirm it without talking to anyone, confirm it first.

The data told me where to look and who to talk to. Interviews show what it felt like from the inside. That’s what I’m doing next.

Reading your product data when you don’t have a data analyst was originally published in Bootcamp on Medium, where people are continuing the conversation by highlighting and responding to this story.

Title. Frame 10. Container. Options.

That’s what a Figma file looks like mid-exploration, and usually what it still looks like at handoff.

Not because designers are careless. Because during exploration, that’s not the work. You’re figuring out structure, flow, what fits. Naming is for later.

Later doesn’t happen. And it matters more than it looks.

A developer building from a file with semantic names doesn’t have to invent naming. The system is already there, consistent between design and code. And if you’re using AI to generate code directly from Figma, clean layer names aren’t optional. They’re the input.

I’ve told myself “I’ll rename before handoff.” The honest reason it doesn’t happen: the cost is too high for something that feels like cleanup. The effort of encoding what you already know, layer by layer, matching domain language, matching the tech stack, never quite feels worth it.

What Figma’s AI rename actually does

Figma recently improved AI-powered rename. I tested it on a scheduling form. Figma flagged no layers as needing renaming. I forced it anyway, hoping it would fix the wrong existing names.

It didn’t. Input container appeared three times in a row for three completely different fields. Layers already named, even wrongly, were left untouched. Figma’s AI won’t question a name that looks intentional.

The reason is context. Figma’s AI sees shapes. It doesn’t know the feature, the domain, or what the developer expects. That context is what turns Recipient email container into Form.RecipientsField, a name that tells a developer what the component does, and tells a code generator what to reach for.

So I tried delegating it.

The workflow

The workflow: paste a Figma link into Claude Code. It reads the full layer tree via Figma MCP, structured data not a screenshot. Then it proposes a mapping:

I review, type apply, and Claude Code renames everything directly in the file.

But metadata alone isn’t enough. Without seeing the actual design, some fields come back wrong — a layer named Form.ScheduledDateField when it was actually the Dimension field. Link plus screenshot fixes that. Claude reconciles against the real label text and corrects what the metadata got wrong.

There’s a second gap: layers with names that already exist but are wrong. Claude won’t question them. A manual pass on those is still necessary, but it’s a targeted check, not a full rename from scratch.

After that, naming accuracy is significantly higher. Not perfect, but precise enough that a developer can read the file without asking, and a code generator has enough signal to work with.

How to try it

If you want to try this:

Prerequisites: Claude Code with Figma MCP connected.

Start with this prompt:

“Here is my Figma link: [link]. Tech stack: [React]. Feature: [feature name]. Propose a rename mapping.”

Tech stack is enough. Claude will apply the appropriate naming convention automatically. No need to define format, prefix, or granularity yourself.

1. Review the mapping. Claude proposes names for the full layer tree. Read through before applying.

2. Add a screenshot if labels are ambiguous. Link plus screenshot from the start, not after you spot errors.

3. Type apply. Claude Code renames directly in the file. No copy-paste. No manual panel work.

4. Quick manual pass on layers that already had names. Wrong ones won’t be caught automatically.

The same approach works for variable values, color tokens, spacing, anything that lives in the file as structured data.

Renaming layers isn’t judgment work. It’s translation work, taking what you already know about a screen and encoding it somewhere the file can carry it forward without you.

Before, that translation was expensive enough to skip. Now it isn’t. That’s what changes the file, not discipline, just cost.

We were trying to decide between two versions of a permission screen.

Same model, two different layouts. Both made sense.

But we were deciding on a static frame — and a static frame can only show you layout, copy, structure. Not how something actually behaves when you use it.

The obvious fix would be to wire it up in Figma. But the problem is what happens next: every change means going back in, reconnecting frames, updating interactions one by one. It adds up.

For flows like this, I’d rather have a small artifact in the browser instead. By “artifact” I mean a throwaway prototype that runs in a tab, takes real input, and shows state changes. Not something for handoff or production, just enough to feel how the behavior works.

So I just built both versions in the browser.

I started with a screenshot and wrote a prompt. The structure I keep coming back to is simple:

• write the actual job first, not the spec
• then spell out the logic — rules, edge cases, states that branch
• close with “if anything is unclear, ask before assuming”

With that “ask before assuming” at the end, gaps turn into questions instead of guesses. And with the design system in the mix, the prototype already feels like the product instead of a random demo.

In the single‑column version, team‑granted permissions show up in light purple. Click one and it converts, and a tooltip appears explaining the consequence. I never wrote that copy. It came entirely from the rules and context I’d described.

It doesn’t always land this well. When the interaction is less conventional, it fills gaps with patterns that don’t fit your product. The layout looks right but the interaction is off. The branching logic is wrong in ways you only catch when you click through.

A few minutes later, I shared the link. The dev clicked around, tried both, then came back. We landed on the same one.

Prototyping often gets skipped because by the time anything is wired up, the decision has already been made in a meeting or a comment thread.

A throwaway artifact changes that. It’s fast enough to exist before the conversation, not after.

20 mins of arguing, 2 mins of clicking was originally published in Bootcamp on Medium, where people are continuing the conversation by highlighting and responding to this story.

Getting better answers from AI starts before you open the chat.

You open a chat, describe the situation, ask for options.

AI gives you options. Good ones, even. You ask follow-up questions. More options. You go back and forth for a while, and at some point you realize you’re not closer to a decision.

You’re just deeper in.

The session felt like work. It wasn’t.

AI did exactly what it’s good at, it gave me possibilities. The problem is that possibilities, when you don’t know what you’re optimizing for, are just noise with good formatting.

I hit this working on a navigation problem. A screen with 20+ workspaces, each with 20+ dimensions, each dimension with 20+ values.

I asked AI for solutions. Got a list of options that all made sense. Spent thirty minutes asking follow-ups, trying to get one of them to feel obviously right.

None of them did.

At some point I closed the chat and went for a walk, which is usually a sign that something went wrong.

What went wrong was that I asked AI to help me decide before I knew what I was deciding.

The options AI gave me were answers to “what navigation patterns exist for complex data structures.” That’s a real question, and AI answered it well.

But the question I actually needed to answer was different: what is the user trying to do, and when does the current pattern start to break for them?

Those two questions look similar. They’re not.

The first one AI can answer from training data. The second one requires knowing things that aren’t in the prompt: which workspaces users actually live in day-to-day, whether the primary action is searching or comparing or setting up, where the friction is right now.

I had some of that context. I just hadn’t written it down before asking.

After that I started doing something small before opening any AI chat for a design problem. Three things, in order.

The first thing I write down is what the user is actually trying to do. Not the data shape, not the feature spec, but the job.

In this case: users primarily work inside two or three familiar workspaces. They rarely compare multiple workspaces at once. Main actions are within a workspace, not across them.

Three sentences. Five minutes, sometimes less. But it’s the difference between asking AI to evaluate options versus asking AI to evaluate options for a specific user in a specific context.

Then which direction I’m already leaning, and why. Even if I’m not confident. Especially if I’m not confident.

“I’m thinking sidebar navigation with a workspace switcher at the top, because the mental model feels like being inside one workspace at a time.”

That’s enough. It’s not a decision, just a direction. But it gives AI something concrete to push back against instead of just generating variations — and honestly, writing it down sometimes tells me more about what I actually think than the AI’s response does.

The third thing is the one that changed the most about what I got back. One specific thing I’m uncertain about, tied to a real constraint or failure mode.

There’s a difference between “I’m not sure about the layout” and “I’m not sure if showing twenty dimensions in a sidebar creates cognitive overload, and I don’t know at what threshold that pattern starts to fail.”

Both are honest. Only one is useful to hand to AI.

Vague uncertainty gives you more options. Specific uncertainty gives you something you can decide from.

Here’s what the prompt looked like once I had all three:

• Context: Screen has 20+ workspaces, each with 20+ dimensions, each dimension with 20+ values. Users primarily work in 2–3 familiar workspaces. They rarely compare multiple workspaces simultaneously. Main actions are within a workspace: viewing, filtering, setting up. Not across workspaces.
• My direction: Leaning toward sidebar navigation with a workspace switcher at the top. Mental model is “at any given time, I’m inside one workspace.”
• My uncertainty: Not sure if showing ~20 dimensions in a sidebar creates cognitive overload. Don’t know at what threshold this pattern starts to fail.
• Question: With this data shape and usage pattern, where does a sidebar dimension list start to break down, and what’s the first sign of failure?

No preamble. No “can you help me with.” Just context, direction, uncertainty, one question.

The response came back about failure thresholds, not solution options. Which was what I needed.

The thirty-minute session wasn’t wasted. I needed to see all those options to understand that options weren’t my problem.

But I keep thinking about how long I sat there waiting for one of them to feel right. Like if I just asked the right follow-up, something would click.

It didn’t. It usually doesn’t.

The problem wasn’t the AI. It was that I showed up without having done the part only I could do.

Before you ask AI, answer this first was originally published in Bootcamp on Medium, where people are continuing the conversation by highlighting and responding to this story.

TL;DR: Figma MCP lets AI read your files the way a developer reads structured data, not screenshots. It works well when your UI is built from clear components, real variants, and shared styles. It tends to struggle when you try “full page from mockup”. The output can look right but be hard to trust or maintain. Even if you never use MCP, treating Figma less like a moodboard and more like a product database: files by domain, a real system library, product-level naming, explicit states, readable component internals, makes life easier for teams and AI tools you plug in later.

There’s a lot of noise right now about “AI for UI” and Figma MCP. Most of it is about slick demos: “look, we generated this whole page from a mockup.” Fun to watch, hard to trust.

Behind that, there’s a quieter question that feels more important for real product work:

What if Figma behaved less like an infinite canvas, and more like a structured database of your product’s UI?

Once you look at it that way, things start to shift. Life gets easier not just for designers, but also for developers, PMs, founders and, yes, for AI tools like MCP.

This is a tour of that idea, based on real experiments and a couple of failures worth sharing.

1. Figma MCP in simple words

Before talking about “database”, it helps to be clear on MCP itself.

What it is:

MCP (Model Context Protocol) is a way for AI tools to talk directly to Figma via API instead of looking at screenshots.

Without MCP:

AI sees pictures and some text. It guesses spacing, colors, and states. It’s always a bit approximate.

With Figma MCP:

AI can ask questions like:

• “Give me this component and all its states.”
• “What styles and variables are used here?”
• “What happens on hover/click for this element?”

Figma returns JSON data with that structure.

What you can do with that data:

• Generate a spec for a component straight from the source.
• Draft or refactor implementation code, in whatever tech stack you use.
• Build docs or playgrounds that show all states of a component.

There’s one catch: MCP can only use what is actually encoded in your Figma file. Anything that lives only in people’s heads or Slack is invisible.

2. Figma as a canvas vs Figma as a database

Up to this point, I had mostly used Figma like many teams do:

• a canvas with screens
• a place to show flows
• a board to “handoff” to devs
• a bit of “we just know this” logic in the team: which button is the real primary, which version of a flow is actually live, which state “obviously” means error, etc.

When you connect MCP, the way Figma is used starts to matter more.

MCP doesn’t see a pretty canvas. It sees data:

• a tree of nodes (components, frames, groups)
• component names
• frame names
• variant options
• styles and variables
• defined interactions
• any written notes or guidelines in the file

Anything that lives only in people’s heads, Slack, or verbal agreements is invisible.

3. Where MCP really helps (and where it doesn’t)

After a few experiments, some patterns became clearer.

MCP is good at…

Components and patterns that are already clear.

Show me exactly how this component works and help me keep its code, docs, and spec in sync.

For example:

• a well‑defined Button, Tag, Dialog, Table row, etc.
• flows that use these components consistently

MCP can:

• extract a spec
• help generate or refactor the implementation
• generate simple docs or playgrounds for testing

This is useful whether you’re a designer, dev, PM, or founder. You get:

• a shared, concrete description of a component,
• less guesswork when implementing or reviewing.

MCP is not so good at…

Generating full production screens from mockups.

You can ask an AI connected to MCP:

“Here’s a complex screen in Figma, generate the whole page code.”

I tried it. It looked great in a demo, but here is where it hurt in code review:

• a big chunk of code that technically matched the layout
• lots of one‑off components created on the fly
• huge files mixing layout, UI, and mock logic
• behaviour that didn’t match how our product actually works
• something that would be painful to maintain

That’s when I stopped thinking “one click from Figma to full app” was interesting for serious products.

For a quick demo? Sure.

For a product that will evolve for years? Probably not worth it.

4. Clean Figma helps MCP

These are not magic checklists that make AI “fully understand” your Figma file. But when files use real components, product‑level names, and explicit variants, designers and engineers spend less time debating what’s real and MCP has fewer chances to guess or hallucinate.

The trade‑off is real: making every frame and layer perfectly structured is slow and doesn’t scale. Figma isn’t a real database with schemas and constraints, discipline still comes from people and process.

Because of that, I aim for baseline structure:

• structured enough that someone who wasn’t in the original context (or an AI) can read it.
• light enough that designers are not spending their whole week cleaning up layers instead of designing.

With that in mind, here are five habits that have actually helped in my own work.

Let Figma reflect the product, not the project history

Instead of a pile of files named after sprints or experiments (‎dashboard_v2_final, ‎new-idea-jan), it helps to organise around real product areas:

• Navigation / workspace
• User management
• Billing
• …

Inside those files, people (and tools) can answer basic questions like “Which screens belong to Billing?” or “What’s the current user management flow?”.

Make it obvious what is “system” and what is “one‑off”

MCP has more to work with when designs use reusable components, variables, and styles instead of one‑off frames.

In practice:

• Keep system pieces (buttons, inputs, cards, table rows, banners) in clearly marked component pages or libraries.
• Use those components in screens and flows, instead of redrawing similar UI over and over.
• Reserve “raw frames” for true one‑offs or early sketches.

For MCP, this is the difference between:

• “Here is a ‎Button that’s part of the design system” vs
• “Here is a blue rectangle with text that kind of looks like a button.”

The first can be tied to actual implementations. The second is just pixels.

Use product language in names, not visual nicknames

Names carry most of the meaning in a file.

Good names:

• match the domain and product language (‎UserTable, ‎WorkspaceSidebar, ‎ReportFilters, ‎BillingSummaryCard),
• stay stable even if the visual styling changes,
• can be recognised by anyone reading a spec, PRD, or codebase.

This is helpful for devs and PMs, and it’s also exactly what MCP tools read: component names, page names, descriptions.

Clear names give AI a much better chance of choosing the right building blocks instead of inventing new ones.

Turn options and states into real properties

Figma and MCP both treat variants, variables, and styles as meaningful.

For key components, it helps to explicitly model:

• options (different tones, sizes, layouts),
• states (default, hover, pressed, disabled, loading, empty, error).

When these are set up as component properties and variants (instead of a bunch of unlabeled duplicates), MCP can:

• tell which states exist,
• understand how they relate,
• use that information when generating code or docs.

Keep the internal structure legible

When MCP extracts node information, it’s effectively reading your component tree the way a developer reads a DOM or component hierarchy.

It helps if that tree:

• uses semantic names inside components (‎Avatar, ‎Title, ‎Meta, ‎Actions),
• avoids very deep, unnecessary nesting (‎Group 23 / Frame 17 / Group 42),
• keeps decorative wrappers obvious (‎Background, ‎Divider) and separate from content.

This doesn’t change how the UI looks, but it makes it much easier to understand for people, and for MCP when it’s trying to turn that structure into code.

None of these habits require a specific stack (React, Vue, etc.) or even MCP itself. They’re the same foundations Figma pushes: strong design systems, consistent use of components, variables, and styles, and clear structure.

With MCP in the mix, these details don’t just help humans, they directly affect how well AI tools can read and build on top of your designs.

5. Why this still matters without MCP

It’s possible to ignore MCP and still benefit from this shift in perspective.

Seeing Figma as a kind of product database quietly improves a lot of day‑to‑day work:

• New designers understand the product faster without a guided tour.
• Developers spend less time translating vague frames into real behaviour.
• PMs and founders can browse designs and flows without constantly asking “which of these is real?”.
• Design decisions become easier to reuse, not reinvent.

If MCP enters the picture later, it simply becomes another consumer of the same clarity.

In the end, the question is not “How do we make Figma ready for AI?” but:

How do we make Figma a place where the product is described clearly enough that anyone — human or machine — can build on it without guessing?

Figma as a canvas is great for exploring ideas.

Figma as a database is what lets those ideas turn into a real, working product.

Most teams need both. MCP just makes the gap between them impossible to ignore.

Your Figma file is not a database. It should be. was originally published in Bootcamp on Medium, where people are continuing the conversation by highlighting and responding to this story.

In Part 1, we get started with the analysis of the Job-to-be-done, as well as the company’s values and its test-driven culture. Then, we delved into Duolingo Product Metrics, and how they balanced three goals User Growth, Monetization, and Educational Value to ride an incredible growth trajectory.

Part 2 will focus on Product Stickiness, and how Duolingo helps its users be motivated and form a habit of language learning.

Product Stickiness

Games are a great example of sticky products. Many product designers try to “gamify” their apps by adding badges, rewards, and scoreboards.

But it isn’t that simple. Most people don’t play games just to earn virtual points and badges.

The key here is the “core loop”.

Duolingo does this in many ways to help users be motivated and form a habit of language learning.

Here are three worth highlighting:

(i) Streaks

(ii) Duolingo Plus Feature: Learning from Mistakes

(iii) Encouragements

(i) Streaks

One of the product aspects the Duolingo team experimented with a lot, is the concept of the “streaks”, which is borrowed from the gaming industry.

Users start feeling invested and they try not to break this streak. The bigger it gets, the more they want to keep it. This feature plays a huge role in getting users hooked on learning.

Notification reminders to encourage users to come back…

The Duolingo team knows how to make learners feel excited about their accomplishment milestones (one week, one month, one year streak, and beyond).

… and make the streak sharable. This helps Duolingo grow super rapidly with better and more engaged users.

🚀 The number of people with a streak of 7 days or longer, used to be about 20% of DAUs, and now it’s about 60%. Every day, thousands of people share their Duolingo streaks on social media.

(ii) Duolingo Plus Feature: Learning from Mistakes

This is a new feature of the subscription service, Duolingo Plus, that engages and delights the subscribers on their language-learning journey. Learners love this feature because they can learn from their mistakes.

The badge “broken heart” with the counter also motivates learners to practice their mistakes. Nothing feels more satisfying than turning their broken heart into a gold heart by correcting all their mistakes!

🔥 This feature generated very positive results for subscription growth and learner engagement, including a 5% increase in total subscription bookings.

(iii) Encouragement

Positive emotions make the interaction between a user and the digital product more delightful. There’s no denying that the cute animations of the mascot, Duo the owl, make the whole learning experience joyful.

As you’re doing lessons, he will sometimes pop up to do things like encouraging. Messages like these seem small but they can bring a smile to users’ day. 🤗

Duolingo Community

Besides Product Stickiness, Duoling borrowed from the gaming industry the powerful concept of community.

They have a large and active community where learners can ask questions, learn from other users, swap tips, and share resources. 18K+ members on Duolingo Discord. Every day, thousands of them are enthusiastic fans of Duolingo.

Hope you found some bits of this useful.

I’ll be doing product case studies to help us learn about best practices. Stay tuned!

References

Do this one thing to make your product sticky ▪ Interview with Duolingo’s Chief Product Officer Jorge Mazal ▪ Gina Gotthilf, VP of Marketing and Growth on growing Duolingo to 200 million users ▪ How we brought the streak milestone to life. ▪ New Plus feature: helping you learn from your mistakes.

Note: This is the next part of the product case study: Duolingo. I did write it on April 28, 2022 and shared it on my Linkedin profile.

Don’t make the mistake of going to Paris without knowing the language. 😜

Don't Be *That* Kind of Emily in Paris-Learn Some French, First

You’ve probably heard of Duolingo, an app where you can learn languages through super-fun gamification.

Recently I installed Duolingo. Impressed by the learning experience, I tried to dig deeper into how Duolingo nailed its product and became the №1 education app.

Some key statistics

• Duolingo has over 500 million registered users and 42 million monthly active users.
• The company experienced a huge surge during the pandemic but carried substantial gains through 2021. In 2020, $161 million in revenue, an increase of 129% year-on-year. In 2021, $294 million in revenue, an increase of 55% over the prior year.
• In July 2021, Duolingo became one of the few Ed-Tech companies that entered IPO.

With a fantastic growth trajectory, Duolingo has demonstrated how technology has changed education.

How is that possible?

In this product case study, I will cover the following sections.

(a) Analysis of the Job-to-be-done

(b) Product Metrics

(c) Product Tradeoff Triangle

(d) 1% improvement every week

(e) Product Stickiness

(f) Monetization

(a) Analysis of the Job-to-be-done

The job that Duolingo’s users are hiring the product for is:

Help me learn a new language in a fun, effective, and accessible way. I don’t want to spend too much time, money, or effort on learning a new language.

Founded in 2011 by Luis Von Ahn (known for his work in re-CAPTCHA) and Severin Hacker, Duolingo started with a question: What if education can be free and high-quality for everyone?

Over the past decade, Duolingo has re-invented the way we learn and do business

1. Give the product away for free. They have a principle to never change: all of Duolingo’s 100+ language courses in 40+ languages are fully accessible to users for free.
2. Make learning fun. Learning a language is really hard work, and the hardest part is staying motivated. Gamification is the key to getting learners to stick with it. - Luis Von Ahn, CEO of Duolingo

(b) Product Metrics

Duolingo is a consumer subscription product. It works on the freemium model with the free model having ads and online-only access.

The team cares about:

• Engagement Growth
• Revenue Growth
• Learning Experience

The company chooses DAUs (Daily Active Users) as their North Star Metric.

North Star Metric is a guiding metric, all energy and brainpower will flow in that direction. It gives the company a sense of whether what is going or isn’t working out.

The Duolingo team also invests in other metrics which help leverage their North Star Metric.

For example, number of lessons completed, lessons completed per session, number of minutes spent on Duolingo per session, and number of average total minutes per day per user. They also look at the number of people who get from a certain part in the learning tree to another part.

Jorge Mazal, Chief Product Officer at Duolingo, said that they run modeling on different metrics, and identified a metric that turned out to be super high leverage, which was CRR (Retention Rate). They put a team just to optimize that metric. The more they can keep users engaged, the more they’ll add paid users.

(c) Product Tradeoff Triangle

The team cares about Engagement, Monetization, and Educational Value. That’s why they create 3 teams to work on these 3 goals. Each team is responsible to improve the metrics linked to its specific goals.

There are synergies between these goals but also many tensions between them.

How does the Duolingo team find a balance?

They stick to their guardrail metrics that never change.

At Duolingo, these guardrail metrics are engagement and retention, and not monetization. They have taken the long view of the business and do not sacrifice long-term usage for short-term gain.

Guardrail metrics keep organizations and product teams on the right track and aligned with business goals and values.

(d) 1% improvement every week

Duolingo is one of the best examples of product-led growth. They use their product as a primary driver of customer acquisition, conversion, expansion, and retention.

The company has built a strong test-driven culture.

“Test everything”, they rely on experiments and data to make decisions from small ones like updating a single button in the app to launching a new major feature like Leaderboards.

Any team member is empowered to propose and run experiments. It’s common to have 100s experiments running simultaneously in a week. Duolingo team members believe that they are improving their app by 1 percent each week.

If you enjoy this post, check out the exciting continuation of Part 2 (Link here).

You will learn some Product Stickiness Ideas and how Duolingo helps its users be motivated and form a habit of language learning. 😉

References:

Duolingo’s values: a letter from the CEO

How Duolingo (DUOL) educates the world and rewards investors

Choosing Your North Star Metric

Interview with Duolingo’s Chief Product Officer Jorge Mazal

Gina Gotthilf, VP of Marketing and Growth on growing Duolingo to 200 million users

How Duolingo Runs Experiments at Scale

Duolingo A/B testing process: 1% improvement every week