Discovery-Focused Test & Experiment Plan

The Fastest Product Teams Test Assumptions, Not Features

There is a persistent myth in product development that speed means building fast. The fastest teams in the industry are not the ones who code the quickest. They are the ones who figure out what not to build before writing a single line.

The Problem

Every product decision rests on a stack of assumptions. We assume customers have this problem. We assume they will pay to solve it. We assume our solution is better than alternatives. We assume we can build it within our constraints. Most teams treat these assumptions as facts and discover they were wrong only after shipping.

A 2023 Pendo study found that 80% of features in the average software product are rarely or never used. That is not a development problem. It is a discovery problem. Those features were built on untested assumptions that turned out to be false.

The discovery test plan exists to systematically surface and validate the riskiest assumptions before committing engineering resources. It is not about slowing down. It is about eliminating the most expensive form of waste: building the wrong thing.

How This Prompt Works

This prompt generates a structured test plan for product discovery. It takes your product hypothesis and decomposes it into its underlying assumptions across four categories:

• Desirability: Do customers want this?
• Viability: Does this make business sense?
• Feasibility: Can we build this?
• Usability: Can customers figure out how to use this?

For each critical assumption, the prompt designs a lightweight test: the method, the target audience, the sample size, the success criteria, and the timeline. Tests are ordered by risk, so you address the assumptions most likely to kill the idea first.

According to Teresa Torres' research on continuous discovery, teams that test assumptions before building reduce their time-to-value by an average of 35% because they avoid building solutions to problems that do not exist or solutions that customers cannot use.

When to Use It

• Before committing to a solution to validate that your biggest bets are not blind spots
• When stakeholders disagree to convert opinions into testable hypotheses
• During quarterly planning to evaluate which roadmap items have the highest assumption risk
• After a failed launch to retroactively identify which assumptions were wrong

Common Pitfalls

• Testing the easy assumptions. Teams naturally gravitate toward testing what they can test quickly, not what matters most. The hardest assumption to test is usually the one most worth testing.
• Conflating discovery with validation. Discovery is about learning. Validation is about confirming. If you design every test to confirm your hypothesis, you are not discovering anything.
• Over-engineering tests. A discovery test does not need to be an A/B experiment with statistical significance. A five-person usability test or a landing page smoke test can eliminate an assumption in days.
• Skipping the "so what." Every test needs pre-defined success criteria. "We learned a lot" is not a result. "7 of 10 participants could not complete the core task" is a result.

A 2022 Harvard Business Review analysis found that companies practicing systematic assumption testing launch 30% fewer features but generate 47% more revenue per feature. Less, but better.

Sources

• Torres, T. (2021). *Continuous Discovery Habits*. Product Talk LLC. https://www.producttalk.org/continuous-discovery-habits/
• Bland, D. & Osterwalder, A. (2019). *Testing Business Ideas*. Wiley. https://www.strategyzer.com/library/testing-business-ideas
• Pendo. (2023). State of Software Report. https://www.pendo.io/resources/state-of-software/