| name | reference-customer-discovery |
| description | A high-touch discovery framework to achieve product-market fit by co-creating solutions with a specific number of "reference customers." Use this when launching a new product, entering a new market, or when you need to validate deep customer value before scaling engineering. |
Reference Customer Discovery
The "Holy Grail" of product work is creating a solution that customers love so much they are willing to put their reputation on the line for it. This process involves immersing yourself in the customer's environment to solve a problem manually before building scalable technology. Success is measured by a "certificate of appreciation": revenue, engagement, or a public reference.
Core Principles
- Value over Usability: Just because someone can use a product doesn't mean they will buy or choose it. Discovery must solve for Value (will they buy?) and Viability (does it work for our business?).
- The Reference Commitment: A customer is only a "reference" if they have used the product, love it, and will tell others about it.
- Do Things That Don't Scale: Recruit, interview, and even perform the service manually to understand the nuances of the problem before writing a single line of code.
The Discovery Process
1. Define the Target and the Goal
Identify the specific problem you are solving and the "evangelist" persona who has it.
- B2B Goal: Find 6 to 8 reference customers.
- B2C Goal: Find 15 to 25 reference customers.
Why these numbers? Fewer than this might be an outlier; achieving this number indicates true product-market fit.
2. Recruit Early Adopters (Evangelists)
Look for people who feel an "irrational" need to solve the problem.
- Technologists: They love new tech for its own sake.
- Evangelists: They have the problem so badly they are already trying to hack together their own solutions.
- The Pitch: "I am trying to build the best [solution] for [problem]. If I build something you love, are you willing to give me a video testimonial/5-star review?"
3. Immerse in the Problem (The "Out of the Building" Rule)
Don't rely on user interviews in a lab. Go to where the problem happens.
- Spend time on-site with the customer.
- Observe the "no-shows," the workarounds, and the failures in their current process.
- Act as the "manual engine" for the solution (e.g., using spreadsheets and phone calls instead of an automated system) to find where the process breaks.
4. Iterate Toward a Single Solution
If one customer wants a feature but the others don't, do not build it.
- Your goal is to find the common denominator that all 6-8 (B2B) or 15-25 (B2C) customers need.
- Tweak the "menu" or the process until every single reference customer says, "This is exactly what I need."
5. Secure the Reference
Once the manual/MVP solution works, ask for the "payment":
- For B2B: A signed contract or a public testimonial.
- For B2C: A commitment to post a 5-star review on launch day.
- If they hesitate, you haven't solved the value risk yet. Use their hesitation as data for the next iteration.
Examples
Example 1: B2B High-Volume Hiring Product
- Context: A company needs to hire 800 people quickly for a new bakery acquisition.
- Input: No software exists. The PM, Designer, and Engineer go to the site.
- Application: They manually recruit via Craigslist and flyers, call every candidate to remind them to show up, and sit in on interviews. They realize the "no-show" rate is the real problem.
- Output: They develop a scheduling and reminder tool based on the manual "reps" they did for McDonald's and Starbucks. The product launches with $32M in sales because it was built to solve the specific no-show pain points discovered on-site.
Example 2: B2C App Launch
- Context: Launching a new niche social or utility app.
- Input: A prototype or beta version.
- Application: Instead of a "quiet launch," the PM finds 25 people who have the specific pain point. They work with them for weeks, refining the UI and features based on real usage.
- Output: On Day 1 in the App Store, the app already has 25 5-star reviews from the people who helped build it. The "marketing" is just the exact words those 25 people used to describe why they love it.
Common Pitfalls
- The "Nice" Bias: Users often say they like a product just to be polite. Avoid this by requiring a "reputation stake" (the public reference). If they won't give a reference, they don't actually love it.
- Premature Scaling: Building automation before you’ve manually solved the problem for at least 6 customers.
- Customizing for Outliers: Building "one-off" features to please a single loud customer. If it doesn't serve the whole reference group, it's a distraction.
- Relying on PRDs: Writing long requirements documents instead of involving engineers and designers in the actual "on-site" problem-solving. True innovation happens when the engineer sees the customer struggle.
