Where we start
Sessions 2 and 3 were about the whole product: the moment that predicts staying, and the engagement curve you can defend. Tonight narrows to one feature at a time, which is how most product decisions are actually made. A team ships a thing, a number called "adoption" appears on a slide, and a decision about the next quarter follows from it. The trouble is that "adoption" is not one measurement. It is a family of at least three, they routinely disagree, and the easiest one to make go up is the one that says least about whether anyone got value. The same cohort of 8,348 new repositories from session 2 gives us six features to practise on, and the practice is the point: by the end you will read any adoption slide and know which of the three questions it answered and which two it skipped.
★ What you walk out with tonight. An adoption scorecard for one feature of your own product, five rows on one page: breadth, depth, time to adopt, the value signal you would accept, and an honest column saying which of those rows the team could push up without a single user getting anything. Plus the one question that deflates a celebratory adoption slide in a sentence: "was that first use a choice, or did the product do it for them?"
Three questions hiding inside one word
5 min liveTake the most ordinary thing a new GitHub repository can do: receive a push of code. Ask "was pushing adopted?" and three honest answers come back that do not resemble each other. 39.1 percent of the 8,348 new repositories received at least one push in their first week. Those that did received a median of 2 pushes, mean 3.6. And the median time from the repository's birth to its first push was 0 hours: it happened in the same hour the repository was created. Same feature, same week, same repositories. One word, three measurements.
LiveBreadth, depth, time: define each before you compare any3 min▶
Breadth is the share of eligible units that used the feature at least once in a window. Three words in that sentence need a decision: eligible (who could have used it), once (or a higher bar), and window (a week, a month, ever). Change any one and the number moves. For pushing, breadth in week one is 39.1 percent of 8,348 new repositories.
Depth is how much the adopters used it, and it is only ever measured among adopters. Median 2 pushes and mean 3.6 tells you the typical adopter pushed twice and a few pushed a great deal. Quote the median first; a mean over a long tail describes the tail.
Time to adopt is the gap between becoming eligible and first use, and the median is the honest summary because the tail is long: half of pushing repositories pushed within their birth hour, and 489 of the 3,268 waited past day one. A time to adopt of 0 hours is not automatically good news. It can mean the feature is irresistible, or it can mean the product did it as part of setup and the user never chose anything.
Self-studyWhy the three disagree, and why that is the point2 min▶
Breadth rises with anything that puts the feature in front of people: a default, a prompt, an onboarding step. Depth rises only when the feature keeps earning its place in a workflow. Time to adopt falls when the feature is near the start of the journey or is triggered for the user. So a team optimising a single "adoption" number will, without meaning to, optimise breadth, because breadth is the one that responds to placement. That is not dishonesty; it is what happens when a family of measurements is reported as one. A review that asks for all three, every time, removes the incentive.
The analyst track builds this table for all six features in session 6, from the same real rows, as a feature funnel: saw the feature, tried it, used it again. The leader version of that funnel is the three questions above, asked in order.
The 90 percent feature nobody used twice. A common pattern, no numbers claimed: a collaboration feature is placed in the new-account flow, and within a quarter its adoption reads above 90 percent because nearly every new account passes through it. Depth, when someone finally asks, is one use per adopter, and time to adopt is the same minute as signup. The feature was not adopted; the onboarding was completed. The scorecard you build tonight makes that visible on one page instead of three quarters later.
The most adopted feature is the one nobody chose
6 min liveNow widen to all six things a new repository can do in its first week and put the fourth question beside breadth: of the repositories that used the feature, how many came back in weeks five and six, compared with those that did not? "Branch created" is the widest-adopted feature of the six, 5,744 repositories, 68.8 percent. Its adopters came back at 4.3 percent against 3.0 percent for the rest. "Issue opened" is the rarest, 44 repositories, 0.5 percent. Its adopters came back at 29.5 percent against 3.8 percent. The broadest feature carries almost no signal, and the narrowest carries the strongest, and 44 is a small group, so hold the second number loosely.
LiveWhy "branch created" is 68.8 percent and means nothing3 min▶
When a repository receives its first push, GitHub records the default branch coming into existence. So most "branch created" events in a new repository's first week are not someone deciding to branch; they are the by-product of the first push. The feature's depth confirms it: median 1, mean 1.4, one branch per repository and rarely another. Its time to adopt confirms it again: median 0 hours, and only 87 of 5,744 first happened after day one. And its value signal is close to nothing: adopters came back at 4.3 percent, the rest at 3.0.
That is what a setup artefact looks like from the outside. Breadth high, depth at one, time at zero, value flat. Any feature the product performs on the user's behalf during setup will produce this exact shape, and it will top every adoption chart in the company. The chart is not lying. It is answering a question nobody meant to ask.
LiveThe value signal, and its two warnings2 min▶
The fourth row on tonight's scorecard is a value signal: some later outcome that the feature is supposed to serve, compared between adopters and non-adopters. Here it is coming back in weeks five and six, the same outcome the activation bench uses. Repositories that opened an issue in week one came back at 29.5 percent against 3.8 percent for the rest; repositories that opened a pull request, 12.0 against 3.7; a release, 11.1 against 3.9; a wiki edit, 9.1 against 3.9.
Two warnings travel with every one of those pairs. First, they are correlations. A repository where someone opened an issue is a repository that already had a second person or a plan; the issue did not make it come back, it marked a project that was already alive. Proving that nudging people to open issues changes return needs an experiment, which is the experimentation course's job. Second, the groups are small: 44 issue repositories, 36 releases, 11 wiki edits. A rate on 11 repositories is one repository away from a different story. Quote the count with the rate, always.
Self-studyChoosing the value signal for your own feature2 min▶
The value signal must be an outcome the feature was built to serve, measured later than the feature use, and available for non-adopters too so there is something to compare against. Coming back is the general-purpose choice; a feature-specific one is better when it exists, a report feature judged by reports shared, an integration judged by data flowing through it a month later. Two traps: choosing an outcome that is the feature use itself restated (adopters of export "exported more"), and choosing one so far downstream that everything in the product correlates with it. Write the signal down before you look at the number, because after you look, every signal that favours the feature will seem like the obvious choice.
Five thousand repositories that "adopted branching". Read straight off the real rows: 5,744 new GitHub repositories created a branch in their first week, which would be a triumphant adoption number for any feature team. Nearly all of it is the default branch appearing when the first code arrived. Nobody chose it, nobody used it twice, and the repositories that did it came back at 4.3 percent against 3.0 for those that did not. If your product creates anything automatically during setup, a default project, a sample dashboard, a starter template, that thing is currently the most adopted feature you have, and the chart cannot tell you.
More features, more return, and why that proves less than it looks
4 min liveCount how many of the six features each repository touched in its first week, then look at who came back. Repositories that used none, 2,171 of them, 26.0 percent, came back at 2.0 percent. One feature, 3.0 percent. Two, 5.7. Three, 11.8. Four or more, 37.5 percent, on 16 repositories. The staircase is real and it is the most seductive chart in feature analytics, because it seems to say "get people to use more features and they will stay". It does not say that. It says busy projects use more features, and busy projects come back.
LiveReading the staircase without falling down it2 min▶
Three things are true at once. The gradient is real: at every step, repositories that touched more features came back more often. It is a correlation: a repository with two contributors, a plan and some code will open issues, open pull requests and cut a release, and it will also come back, and no part of that says the features did it. And the top of the stairs is tiny: 187 repositories used three features and 16 used four or more: 2.2 percent and 0.2 percent of the cohort. Nearly every new repository used two features or fewer.
So the honest sentence for a review is: "repositories that used more of the product in week one came back more often; we cannot tell from this whether using more causes staying, and the top two steps are too small to quote as rates." That sentence is less exciting than the chart and it is the one that survives the next quarter.
Self-studyThe "adopt three features" target and what it does to a team2 min▶
The gradient tempts leaders into a target: get every new account to three features in week one. What follows is predictable. Teams put features into onboarding, trigger some automatically, and the count of features touched rises for everyone. Breadth goes up, depth stays at one, time to adopt falls to zero, and the value signal does not move, because the accounts that were going to stay were already the ones touching three features, and forcing the other accounts through the same motions does not give them the same project. The gradient has been pushed into the setup-artefact shape from Part 2. Whether a nudge toward a feature changes staying is a causal question, and the only tool that answers it is a controlled experiment, which the experimentation course covers. Everything on this page is what you can know before you run one.
The launch that was celebrated for automatic first use. A common pattern, no numbers claimed: a team ships a feature whose first use is triggered by the product, a template applied to every new project, a summary generated on every save. Adoption in the launch review is near total and the team is congratulated. Months later someone measures depth and finds a single use per account, and the value signal is flat against accounts created before the launch. The number that was celebrated was the share of accounts the product had performed the feature for. The question that would have caught it in the launch review is one line: "was that first use a choice?"
The adoption scorecard for one feature of yours
★ 22 min · everyone buildsPick one feature of your product, ideally one that appears on an adoption slide today. You are writing five rows on one page, plus a column that most scorecards leave out: for each row, could the team make it go up without a single user getting value? The GitHub numbers on this page are your worked example; your own rows will be definitions and, where you have them, your own numbers, which will differ.
Name the feature and the eligible unit. One feature, in the Object Action name from your session 1 plan, and the unit that could have used it: an account, a workspace, a project. Write the window. Everything below is "in the first N days of eligibility", and N is a decision you make now, not after the number is in.
Define breadth, depth and time to adopt, in that order, before looking at any number. Breadth needs "at least how many uses" and the window. Depth is measured among adopters only, median first, mean second. Time to adopt is the median gap from eligibility to first use, with a note on how many first used it after day one, because that tail is where the chosen adopters live.
Choose the value signal and write it down before you look. A later outcome the feature was built to serve, available for non-adopters too, compared as "adopters vs the rest". Coming back in a later window is the default; a feature-specific outcome is better when you have one. Then write the two warnings under it, so they travel with the number onto every slide.
Fill the inflatable column, honestly. For each of the four rows, ask: could the team make this go up next quarter without any user getting anything? Breadth usually yes, by placement or automation. Time to adopt usually yes, by the same means. Depth rarely. The value signal never, and if you can think of a way, your signal is too close to the feature use itself. Then write the choice test: is the first use a decision the user makes?
Write the one-line verdict, and date the page. "Adopted and valued", "adopted, value unproven", or "setup artefact". Bring it to session 6, where the product review reads scorecards like this one and asks the six questions that catch the rest.
Order matters more than the numbers. Definitions before numbers, value signal before you peek, inflatable column before the verdict. A scorecard filled in the other order will always find that the feature is doing well, because every ambiguous decision gets made in its favour.
Before session 5
30 min- Find the most adopted feature in your product according to whatever chart the company uses today, and apply the choice test: is its first use a user's decision or something the product does during setup? Write down which, and what the chart's number would be if automatic first uses were excluded, or who could tell you.
- Ask for depth on one celebrated feature. Uses per adopter, median first. If the answer is one, you have found a setup artefact or a one-time task; either way the adoption slide meant something other than what it said.
- Draw your own breadth gradient in words, no data needed: which kinds of accounts touch many features in week one, and would they have stayed anyway? Write the confounder in one sentence, the way "busy projects use more features" does for GitHub.
- Bring the scorecard. Session 5 builds the same five rows for an AI feature, where the first row, acceptance, is the one everyone quotes and the value row is the one almost nobody measures.
Three questions
Clear all three and leader session 4 gets stamped in your passport.
1 · "Branch created" reaches 68.8 percent of new GitHub repositories in week one, the highest breadth of the six features. Its adopters came back at 4.3 percent against 3.0 for the rest. What is the most defensible reading?
High breadth, depth at one, time at zero and a flat value signal is the shape of something the product did for the user. The count is correct; the word "adopted" is what does not fit.
2 · Repositories that opened an issue in week one came back at 29.5 percent against 3.8 percent for the rest. Which sentence belongs on a review slide?
Quote the rate with its count, name it a correlation, and say what would prove more. A repository that opens an issue already had a second person or a plan; the issue marked the project as alive rather than making it so. Small is a flag to carry, not a reason to hide the finding.
3 · A team is set the target "every new account touches three features in week one" because of the breadth gradient. Which outcome does the gradient itself predict?
The gradient says busy projects use more features and busy projects come back. Forcing the quiet ones through the motions gives them the motions, not the project. The rows a team can inflate are exactly the ones the target rewards.
What this session teaches, and where it came from
Every fact on this page, and its verification tier, is recorded in the course's source map.
Leader session 4 cheat sheet · pin this
Now put an AI feature through the same five rows. Code assistants report acceptance rate, the share of suggestions a developer takes, and it is the number that best tracks how productive developers feel. Whether the accepted code is still there ten minutes later is a different number, and a constructed two-version stream shows the two can point in opposite directions. Session 5 reads the one published study at source and builds the scorecard for a feature that suggests rather than waits. Bring tonight's scorecard.