Two-Speed Offer Testing
Validate willingness to pay, then shorten real-world feedback loops
- Difficulty
- Moderate
- Time to result
- ~weeks to results
- Steps
- 5
- Confidence
- 99%
Two-Speed Offer Testing combines a fast pre-build demand test with a longer real-world learning loop. Shadow testing begins with a concept, prototype, page, or paper description shown to likely customers before the finished product exists. The critical question is whether they will pay, and the strongest evidence is an actual order or commitment rather than a favorable opinion. Once the product is made, field testing begins: the business and people close to the market use it themselves. Direct use exposes failures with full context and without waiting for incomplete customer reports, allowing faster correction. The first speed tests commercial demand; the second improves quality and fit. Together they prevent a founder from confusing stated enthusiasm with purchases or a completed build with a finished learning process.
Origin
Josh Kaufman described shadow testing through Kickstarter-style pre-orders and field testing through companies that improve quickly by using what they make.
Core principles
- 01Test purchase intent before building
- 02Orders are stronger evidence than opinions
- 03Using your own product accelerates learning
- 04Short feedback cycles improve quality faster
How to run it
- 1
Create the concept
Represent the offer with only enough detail for a likely customer to understand the problem, result, and proposed solution.
Pro tip A page, images, text, or simple prototype may be enough.
Watch out Do not build the full product merely to test whether anyone wants it.
- 2
Ask for payment
Present the concept to likely buyers and ask whether they are willing to pay for it.
Pro tip A signed order or pre-order is stronger than a survey response.
Watch out Compliments are not purchase evidence.
- 3
Build the usable version
Proceed only after the shadow test provides enough evidence, then make the smallest version that can be used in realistic conditions.
- 4
Use what you make
Have the business owner and team use the product wherever their situation resembles the target market.
Pro tip Keep the people who can fix defects close to direct use.
Watch out Internal use is useful only when it resembles the customer's real context.
- 5
Close the feedback loop
Act quickly on problems observed during use, then repeat the field test.
Pro tip Preserve context around each failure instead of logging only the symptom.
In the wild
A founder publishes a page with images and text describing a product that has not yet been manufactured. Potential customers can commit to a pre-order, providing a stronger signal than saying the idea sounds attractive.
→ The founder learns whether people will pay before funding a long development process.
A software company uses its own product in daily operations. When a workflow breaks, the team sees the failure and its context immediately instead of waiting for an incomplete external bug report.
→ The feedback cycle shortens and product quality improves faster.
Common mistakes
Testing opinions instead of orders
Positive reactions do not answer the critical question of whether a customer will exchange money for the offer.
Waiting passively for bug reports
External reports often arrive slowly and without enough context, extending the learning cycle.
Is it for you?
Best for
Founders who can test a concept before full production and later use the product in their own operations.
Not ideal for
Safety-critical products where prototypes, pre-orders, or founder-only field use cannot provide sufficient validation.
From the transcript
“testing an idea with potential customers”
“is this something that you're willing to pay for?”
“anytime there's an opportunity for you to use the thing that you make, you end up improving the quality of the product or the offer…”
From the episode
Passion to Profit: Create a Business Offer Your Customers Can’t Refuse
Passion to Profit