What Is a Feature Stub? Definition + Example
A feature stub is a placeholder UI element — a button, link, or toggle — inside a live product for a feature you haven't built yet. When a user clicks it, they see a short "coming soon" message and often a chance to register interest, so you measure real demand before writing the code.
Quick Answer: A feature stub is a fake-door test scoped to a single feature inside an existing product. You add a visible control for a feature that doesn't exist, and when real users click it they get a brief explainer instead of the feature. The click-through rate becomes a demand signal you use to prioritize your roadmap — evidence, not opinion.
Most product roadmaps are ordered by argument: whoever makes the loudest case for a feature wins the next sprint. A feature stub replaces the argument with data from the people who matter — your actual users, in your actual product, at the exact moment they wanted the thing. It is one of the cheapest experiments in the lean toolkit, and in Testing Business Ideas it sits squarely in the family of "single feature stub" and fake-door tests used to gauge interest before committing engineering time.
How a feature stub works: measure intent, then show coming soon
A feature stub works by exposing the entry point to a feature and instrumenting the click, without building anything behind it. The mechanics are deliberately simple.
You add a real-looking control. This is the "door": an "Export to PDF" button, an "Enable dark mode" toggle, a "Connect Slack" link. It looks and sits exactly where the finished feature would live, so the click reflects genuine intent in context — not a survey answer about a hypothetical.
You capture the click as a demand signal. Every tap is logged. Click-through rate on the stub tells you what share of users reached for the feature when it was in front of them. That is the core measurement: revealed demand from real behavior, not stated demand from a focus group.
You show an honest interstitial. When the user clicks, you show a short message — "This feature is coming soon" — ideally with a one-line explainer and an optional "Notify me" input. That email capture doubles the signal: a click shows interest, an email address shows enough interest to wait for it.
This is the same fake-door logic behind a standalone fake door test, but applied to one feature inside a product people already use, rather than a fresh landing page. Because the audience is real users mid-workflow, the signal is often sharper.
A concrete feature stub example
Say you run a note-taking app and users keep asking, in scattered ways, for AI summaries. Building it is expensive. Instead of guessing, you stub it.
Step one: place the door. You add a "Summarize with AI" button to the note toolbar for a slice of users. It looks shipped.
Step two: instrument and gate. Clicking it opens a small panel: "AI summaries are coming soon. Want early access?" with an email field. You log every click and every email.
Step three: read the signal. Over a couple of weeks you watch what share of active users click, whether the same users return to click again, and how many leave an email. A control that gets ignored is a quiet, cheap "no." A control that gets clicked repeatedly — and harvests emails — is a roadmap priority backed by behavior.
The point is not the specific feature; it is that you learned whether to build before you built. That is the whole economic case for the technique.
Feature stub vs painted door: how the in-product test compares
A feature stub is closely related to the painted door test — both show a working-looking entry point that leads to a "not yet" message. The difference is mostly scope and placement. The table below sorts the distinctions qualitatively; none of these are hard rules, just typical tendencies.
| Dimension | Feature stub | Painted door test |
|---|---|---|
| Scope | One feature inside a product | Often a whole offer, plan, or page |
| Audience | Existing, logged-in users | Existing users or new visitors |
| Placement | In the live product UI, in context | Product, pricing page, or landing page |
| Primary signal | Feature click-through, interest emails | Clicks on an unbuilt option or path |
| Best for | Prioritizing the roadmap | Validating demand for a direction |
Takeaway: Treat "feature stub" as the roadmap-scoped member of the painted-door / fake-door family — same mechanism, narrower target. When you want to decide which feature next, the stub is the precise tool; when you want to test a broader offer, reach for the painted door.
When a feature stub is the right in-product test
Use a feature stub when you have live users and a build decision that is expensive to get wrong. It shines under a few specific conditions.
You have real traffic to measure. Stubs need users to click them. Pre-launch, with no audience, a stub has nothing to measure — start with the broader validation work in the complete guide to startup idea validation instead.
The feature is costly to build. The more engineering a feature demands, the more a cheap demand signal is worth before you commit.
You can act on the result. Only stub features you'd genuinely build if demand appears. A stub for something you'll never ship just erodes trust.
Mind the ethics — transparency over trickery. This is the line that keeps a stub honest. Show the "coming soon" message immediately; never let a user believe a feature exists and then dead-end them. Don't stub features you have no intention of building, and don't let a stubbed control block a task the user was trying to finish. A frustrated user is both an ethics failure and a polluted signal. The goal is to learn from a small, transparent moment of "not yet" — not to bait clicks. Run each stub briefly, read the click-through and email signal, then either build the feature or remove the door.
Key Takeaways
- A feature stub is a fake door scoped to one feature — a placeholder button, link, or toggle inside a live product for something you haven't built.
- The click is the measurement. Click-through rate on the stub is a demand signal from real users in real context, not a survey guess.
- The interstitial should be honest and immediate — a short "coming soon" message, ideally with an optional email capture that strengthens the signal.
- It belongs to the painted-door / fake-door family, grounded in Testing Business Ideas, but is narrower: its job is to prioritize the roadmap.
- Transparency is non-negotiable. Don't frustrate users, don't dead-end tasks, and don't stub features you won't build.
- Feature stubs need existing traffic — pre-launch ideas should validate demand through broader methods first.
Frequently Asked Questions
Is a feature stub the same as a fake door test?
A feature stub is a type of fake door test. Fake door is the general pattern — a visible entry point for something unbuilt. A feature stub applies that pattern to a single feature inside an existing product, using the click-through as a signal to prioritize the roadmap rather than to validate a whole offer.
Is feature stubbing ethical or is it deceiving users?
It is ethical when done transparently. The user should see a clear "coming soon" message the instant they click, never a broken or misleading dead end. The rule is: only stub features you would actually build, respond quickly with an honest explainer, and never block a task the user was trying to complete.
How long should I run a feature stub?
Long enough to collect a meaningful number of clicks from active users, then stop. Because the audience is your existing user base, a short window is often enough to see whether the control gets ignored or reached for repeatedly. Once you can read the signal, either build the feature or remove the door — leaving stubs live indefinitely erodes trust.
What metric does a feature stub actually measure?
Primarily click-through rate — the share of users who click the stubbed control when it's in front of them. A secondary, stronger signal is how many leave an email for early access. Together these tell you revealed demand: what users did, not what they said they might do.