The Probe Record: Seven Lines That Turn a Feature Request into an Experiment
Updated
Knowledge on this page was mainly distilled from Prioritize Feature Requests Before You Know Your Customer.
Generosity without records is just motion. A feature request becomes an experiment the moment you write down what it is supposed to teach you. The probe record is a minimal seven-line log, four written before building and three filled in after shipping, that prevents a temporary experiment from quietly becoming permanent scope.
Before Building
- Who asked, and what were they doing when the need appeared? Captures the context of the request, not just its content.
- What pain sits underneath the requested solution? Forces you to separate the symptom from the cause, even if you ship the symptom.
- What would shipping teach you that a conversation would not? Justifies the cost of building over the cost of an interview. If you cannot answer this, an interview is cheaper.
- What condition removes this feature later? The exit condition, written before the first line of code, is what makes the probe reversible rather than permanent.
After Shipping
- Who adopted it, and how fast? Often different from who asked. The gap between asker and adopter is where segment insight lives.
- Did money, retention, or urgency follow? Separates polite usage from real demand.
- What does it cost to keep alive, against what it is still teaching you? Ongoing maintenance without ongoing learning is technical debt disguised as a feature.
What the Record Reveals
The two "who" lines deserve the most attention: who asked and who adopted. When three or more probes surge and their adopters all share recognizable traits, the probes have done their real work. They have drawn you a picture of your customer.
An example filled in retrospectively for the anonymous-email feature in a 1990s dating app illustrates both the value and the cost of skipping this discipline. The pre-build lines could be reconstructed decades later. But line six, whether money or retention followed, was recorded as "we never checked." The record exists precisely to prevent that gap, so the signal a probe generates is captured while it is still actionable.
Q&A
Is seven lines really enough to track a feature experiment?
The constraint is deliberate. Heavier documentation discourages experimentation and rarely gets maintained. Seven lines capture what you need to decide whether the feature stays, goes, or points toward a customer segment. If a probe warrants deeper analysis, the record gives you a structured starting point.
Can the probe record be used for service businesses, not just software?
Yes. A service business can pilot a new offering for one client with an agreed end date, priced as an experiment. The same seven lines apply: who asked, what pain, what you will learn, what ends the pilot, who adopted, whether real demand followed, and ongoing cost versus learning.
What happens when a probe's exit condition is never triggered?
If the feature keeps teaching you something or becomes essential, the question expires naturally and the feature graduates into the core product. The exit condition is not a guarantee of removal; it is a guarantee that removal stays possible and that the feature earns its continued existence.