Customer Discovery Won't Save You
We did everything right. We talked to 40+ potential customers before writing a line of code. We validated the problem. We built a Figma prototype and demoed it to 10 design partners before anyone signed a contract. We read the books, followed the playbook, and felt confident we understood what we were building before we built it.
Then users got access to the real product and almost none of them used it.
The ones who did had a rough experience — not because the product was broken, but because they weren't using it the way they'd told us they would in discovery. The gap between "this is how I'd use it" and "this is how I actually use it" turned out to be enormous.
That was the first punch.
Discovery research describes intention. Usage data describes behavior.
These are not the same thing. People are genuinely trying to help you when they describe how they'd use your product. They're not lying. They're just forecasting their own future behavior, which turns out to be something humans are bad at.
The classic example from behavioral economics: people say they'll eat the salad, and they order the burger. At Flashdocs, our users said they'd use the platform to automate their full document workflow, and then they used it for one narrow slice of it while doing the rest manually.
If you'd asked them after the fact why they weren't using it the way they described, they'd have given you a coherent explanation. But that explanation wouldn't have existed before they actually tried it.
The only way to get real data is to watch real usage.
10 design partners sounds like a win. It was actually a trap.
We were proud of this number. It felt like validation. 10 companies had agreed to be early adopters, given us access to their workflows, and committed to giving us feedback.
What we got was 10 slightly different use cases that sounded similar in discovery and turned out to be meaningfully different in practice. Their problems overlapped maybe 60%. Their workflows overlapped less.
So we built for the intersection. Which meant we built something that partially solved everyone's problem and fully solved no one's.
The feedback was also unsyncable. One design partner wanted faster document generation. Another wanted more template flexibility. A third wanted tighter Salesforce integration. These weren't contradictory requests, exactly, but there was no obvious priority ordering that made sense across all 10 of them simultaneously.
In hindsight, one design partner would have been better. One large partner whose problem we had to solve completely, because they'd paid for it and expected it. That constraint would have forced us to actually understand a single workflow deeply instead of stitching together a shallow understanding of 10.
Depth beats breadth at the design partner stage. Always.
What I'd change: build in 6 weeks, not 6 months.
The discovery phase at Flashdocs took about 6 months. By the time we had real product in users' hands, we were so invested in the problem we'd diagnosed that we were slow to update when the usage data contradicted it.
The emotional and organizational cost of changing direction is proportional to how long you've been going in the original direction. 6 months of discovery creates a lot of organizational gravity.
If I did it again, I'd run a 6-week sprint to something users could actually touch. Not a demo, not a prototype you narrate over — something they interact with alone, when you're not in the room. The data you get from that is worth more than 40 customer interviews.
The interviews aren't useless. They're useful for identifying problems. They're close to useless for validating solutions.
This isn't an anti-research argument. I'd still talk to customers before building. But I'd treat that phase as problem confirmation, not solution validation — and I'd move to a real product much faster, because the only feedback that actually counts comes from people using it without you watching.
You can do all the customer discovery in the world. Reality will still surprise you when it arrives.
Build faster. Find out sooner.