Habit Testing

Habit testing is Nir Eyal's three-step operational method for finding habit-forming product-market fit, modelled on the build-measure-learn loop: identify who your habitual users are and how many you would expect, codify the path they share, then modify the product to route new users down that same path. It is a design framework rather than a tested claim, and the worked examples that circulate with it rest on company-supplied figures reported by an author with an interest in the framework's success.
What it is
The three steps are meant to be run in order and each answers a different question.
Identify asks how many habitual users the product should have, decided in advance rather than after looking, so that the answer is a target and not a rationalisation. The number is a judgement about how often a person with this need would reasonably reach for this product.
Codify looks at what those users actually did in their first days and weeks, searching for what Eyal calls a habit path, a series of similar actions shared by the most loyal users. The point of the step is that the path is discovered rather than designed: you are reading behaviour that already happened.
Modify then redesigns onboarding so that new users are routed down the same path.
The method is the part of the book that is not philosophy. It is the part a product manager can run on a Monday morning, and it is stated plainly enough to be falsified by whoever tries it.
In effect
Two worked cases are usually given. A Bible reading application that passed its hundred-millionth install with tens of millions of regular users, which Eyal presents as a habit that was found and then had distribution built around it rather than the reverse. And a weight-training application whose founder, Eyal reports, read his book in 2015 and built a prototype from it, in a market notorious for habit failure given how many gym memberships lapse within months.
The second case needs its chain of custody stated. Everything in it traces to a single source, an article by Eyal about that company. The founding story is Eyal reporting what the founder told him, and the encyclopaedia entry that repeats it cites the same article, so it is repetition rather than corroboration. The download and usage figures are, in Eyal's own words, what the founders tell him: unaudited and self-reported to the author. And the article functions as a case study validating the author's own framework, in which the company's success is evidence that his book works. That is a reputational interest and it should be stated wherever the numbers appear.
The method itself does not depend on those cases being verified. What it depends on is whether a team running identify, codify and modify finds something they would not otherwise have found, and that is a question each team can answer for itself.
What it does not say
It is not a research claim. No study tests the method, and it is recorded here as a framework.
It does not come with audited evidence. The figures attached to its best-known case study are company-supplied, reported by an interested party, and have not been independently checked.
It does not tell you whether the habit should exist. The method finds and amplifies whatever pattern the loyal users already show, and says nothing about whether routing more people down that path serves them.
And the industry context figures usually quoted alongside the fitness example, about spending and drop-out rates, fail on their own sourcing and are not cited here.
Sources
- Eyal, N. (2014). Hooked: How to Build Habit-Forming Products. Portfolio. Identify, codify and modify at pp. 200-204; the habit path definition at p. 203; the Bible application at p. 190 and the fitness application at pp. 192-197.
- Eyal, N. "The One Fitness App That Hooked Me For Good." Read in full. The sole source for the founding story and for the download and usage figures, both of which are company-supplied and reported by the author of the framework they are used to validate.