Guide
Why Market Research Lies — and How to Validate Features With Real Revenue
Short answer: market research doesn't lie on purpose — it measures the wrong thing. Surveys and interviews capture stated preference (what people say they want); products live or die on revealed preference (what people actually use and pay for). The two diverge constantly. The only validation worth trusting is real usage and real revenue — and there's a way to get that signal without betting a quarter of engineering on a feature first.
The feature research told me not to build
A real example. We wanted to add a significant feature to our platform — big enough that building it was a serious commitment, and we didn't actually know if users would want it. So we did the responsible thing: we asked. Market research told us not to add project-management tools to the platform.
We built it anyway, because we could see what the research couldn't. Today everyone treats that feature as obvious — "genius," even. They can't imagine the product without it.
That cuts both ways, and that's the uncomfortable part. The same research process that told us not to build something essential could just as easily have told us to build something nobody would ever touch. Stated preference is a weak signal in both directions.
Why users say one thing and do another
It isn't that people lie. It's that answering a question is free, while using a product costs time and attention. So:
- People predict their own future behavior badly.
- Answers anchor on how the question is framed.
- Interviewees avoid sounding negative, so they over-state interest.
- Nobody factors in the friction they'll feel in the actual moment of use.
The result: stated preference is noisy at best and actively misleading at worst. Revealed preference — clicks, usage, and revenue — is the only thing that reliably predicts whether a feature matters.
The trap: you can't see revealed preference until you've built it
Here's the catch that keeps founders stuck. The signal you can trust — real usage and real money — usually only appears after you've built the thing. So you're forced back onto the weak signal (research, conviction) precisely when the stakes are highest. That's how startups burn quarters on features nobody wanted.
What to trust instead: ship the feature without building it
There's a way to get revealed-preference data before you commit to building. Instead of constructing the feature yourself, find another startup that already has the technology, integrate it into your product, and set that integration as the revenue source in a revenue-share agreement. The feature goes live in days, the partner earns only from the revenue it generates, and you watch what real users actually do with it.
That's exactly what we ended up doing in place of the market research we would've talked ourselves out of anyway. We borrowed a connection's technology, shipped it as a feature, and let real usage decide. It cluttered the platform, users didn't take to it, and we removed it — and because it was a revenue-share integration, nobody lost a development budget. No downside. The full mechanics of that play are in Integrate, Don't Build.
On Ordana, the AI surfaces the partner whose technology fills your exact gap, the contract and revenue-share are set up in as little as 15 minutes, and Stripe attributes the revenue to that feature automatically — so the "real money" signal is clean and measurable from day one.
The takeaway
Don't throw out market research — just stop treating it as proof. Use it to generate hypotheses, then validate with behavior. Build the things you've proven people want. For everything you're unsure about, integrate first on revenue share and let the revenue tell you the truth before you spend a quarter finding out the hard way.
Related reading: