Feature Validation Template for User Research

A fake door test places a button, link, or menu item for a feature that does not exist yet. When users click it, they see a message like "This feature is coming soon. Sign up to be notified." You measure click-through rate to gauge demand. Use it when you want to test whether users want a capability before investing in design or engineering. It works best for features that are easy to describe with a label (e.g., "Export to PDF," "AI Assistant"). It does not test usability or value, only initial interest.

Use a Wizard of Oz approach. Present the user with a realistic interface (even a static mockup), and deliver the result manually behind the scenes. A classic example: a PM testing an "AI-powered report generator" shows users a button, manually creates the report based on their data, and delivers it as if the AI generated it. The user experiences the value. You learn whether the output is useful before building the automation. It is time-intensive per participant but produces high-quality evidence about feature value.

Reframe validation as risk management, not as a delay. "This feature will take 3 sprints to build. A 3-day validation experiment either confirms we are building the right thing (and we proceed with confidence) or saves us 3 sprints of wasted effort. The expected value of testing is positive either way." If they still insist, document the skip and set a post-launch measurement plan so you can evaluate the feature's actual impact. Sometimes the political cost of insisting on validation exceeds the benefit. Pick your battles.

Not every feature needs formal validation. Apply the risk filter from Part 1. Features that are small (< 1 sprint), easily reversible, and backed by strong existing evidence (analytics, multiple customer interviews) can skip formal validation. Features that are large (2+ sprints), hard to reverse, or based on assumptions should be validated. A practical rule: validate the top 1-2 features in your backlog per quarter, not every line item.

Feature validation sits between problem discovery and solution delivery. First, you identify and understand the problem through research ([customer interviews](/templates/customer-interview-template), data analysis, ethnographic observation). Then you generate feature ideas. Feature validation tests whether your proposed solution actually addresses the problem effectively before you commit engineering resources. The [Product Discovery Handbook](/discovery-guide) covers this full sequence. ---