---
name: duo-product
description: Make product decisions the way Duolingo does — long-view over short-term, ruthless prioritization, ship-and-learn over plan-and-ship, dogfooding, and the "intuitive by default" quality bar. Use when the user is roadmapping, deciding what to cut, debating whether to ship, defining a quality bar for a feature, or trying to install a "product-led" culture in a team that defaults to feature factories. Source the Duolingo Handbook principles 1, 2, and 3 (Take the Long View, Raise the Bar, Ship It).
license: MIT
metadata:
  author: HKTITAN
  version: "1.0.0"
  graph: true
---

# Duolingo Product — Map of Content

Three of the five handbook principles describe how Duolingo *decides what to build* and *what good looks like*. This skill collects the decision rules so a small team can borrow the operating system without copying the product.

This skill is structured as a **graph**: scan the descriptions below, follow only the `[[wikilinks]]` you need.

## The three decision lenses

- [[references/take-the-long-view]] — Principle #1: if it helps short-term but hurts long-term, it's not right.
- [[references/raise-the-bar]] — Principle #2: every feature must be intuitive, delightful, useful, and polished.
- [[references/ship-it]] — Principle #3: clock-speed, ruthless prioritization, kill what isn't working.

## Long-view applied

- [[references/hundred-year-brand]] — the asset class the long view is investing in.
- [[references/intuitive-by-default]] — products shouldn't have to explain themselves.
- [[references/performance-is-access]] — speed on the worst hardware in your user base is an access problem, not a polish item.

## Bar-raising applied

- [[references/dogfooding]] — using the product daily as a quality forcing function.
- [[references/polish]] — what "polished" actually means in review, with concrete tests.
- [[references/ownership-clarity]] — every critical task has one owner; ambiguous ownership is the bug.
- [[references/scope-floor-for-v1]] — a numeric floor below which you don't launch, plus the promise never to call it finished.
- [[references/quality-tiers-by-reversibility]] — tier effort by audience and how hard the work is to take back.

## Ship-it applied

- [[references/ruthless-prioritization]] — how to cut, not how to fit more in.
- [[references/kill-criteria-product]] — the rules for stopping a project, not just an experiment.
- [[references/bounded-deliberation]] — give open decisions an option budget and a time box, and tier advice by experience level.

## Scoping and framing what you build

- [[references/difficulty-with-mitigations]] — publish what's hard about your domain, paired line-by-line with the mechanism that answers it.
- [[references/teach-the-invariant]] — build the shared core, name the axes of variation, hand off the rest.
- [[references/fit-the-artifact-to-the-moment]] — when users have no time, ship the flat lookup page, not the guided flow.

## Sibling skills

- [[../duo-retention/SKILL]] — the long view *is* a retention bet; nodes interlock.
- [[../duo-experimentation/SKILL]] — *Ship It* runs on the *Show Don't Tell* protocol.
- [[../duo-culture/SKILL]] — *Raise the Bar* is a hiring problem before it's a product problem.

## Sources

- Duolingo Handbook (2025), Principles #1–3