Why The Best Apps Are Built On Behavioral Data, Not Just User Feedback
Cofounder of InList.com, a premier app for attending exclusive international events, and cofounder/owner of software company Syragon.
gettyMost founders I know default to the same product-development instinct. A user emails support asking for a feature. A handful of people mention the same request on a call. Someone on the team says, “We keep hearing about this,” and it goes on the road map. I did this, too, early on. It feels responsive, like listening. But feedback is a biased, self-selected sample; it’s the loudest users, not necessarily the most representative ones, and it tells you what people think they want in the moment, not what actually changes their behavior.
I came to product from the engineering side, not the marketing side, which shaped how I think about this problem. Before co-founding InList, a members-only platform for booking curated nightlife and events across dozens of global markets, I spent years as a software engineer, including building enterprise integration systems used by millions of people. Running a product across that many markets makes the limits of feedback obvious fast: Members in one city rarely write in about the same things members in another city do, even when the underlying product issue is identical.
Usage data doesn’t have that blind spot—it shows you what’s actually happening regardless of who speaks up. Here’s what changes when you make the shift to behavior-first, and how to start making it in your own product.
When someone asks for a feature, they’re usually describing a workaround for a problem, not naming the problem itself. Someone who asks for “more filtering options” may actually be telling you the initial results aren’t relevant enough to need filtering in the first place. The request is real, but the fix it implies is often the wrong one. Before building what was asked for, look at what people were actually doing right before they asked for it.
People are naturally better at describing what’s frustrating them than at diagnosing why it’s happening. A feature request is someone’s best guess at a fix, filtered through whatever they already understand about how the product works, which is rarely the full picture of what’s actually going on underneath it. Treating that guess as a spec skips the step where you find out if it’s the right one.
At InList, operating across dozens of markets taught us that the same behavioral pattern doesn’t always have the same cause. A high drop-off rate at one step might mean something different in one city than another, depending on the season or the type of event being booked. Early on, we made the mistake of treating every market’s usage data as one dataset, which risked averaging away the exact signal we were trying to find. Once we segmented the data we already had, before drawing conclusions, the real signal showed up.
Watching someone use a product finds friction faster than any survey. People are unreliable narrators of their own confusion: They rationalize it, blame themselves or simply forget by the time anyone asks them about it. Bringing in someone unfamiliar with a flow and watching, silently, where they hesitate or backtrack surfaces problems that would never otherwise turn into a support ticket or a piece of direct feedback.
This gap between what people say and what they actually do is well established in behavioral research. It shows up any time you compare stated intentions to observed action, from shopping habits to software use. The practical upshot for product teams is simple: A usability session where you watch someone attempt a task, without prompting or leading them, will surface more real problems in 20 minutes than a week of collected feedback will.
Early on, InList’s customer lifetime value and retention numbers looked concerning taken at face value. They suggested members weren’t sticking around. Talking to members directly told a different story. They loved the service; they just didn’t need it as often as we’d assumed. That conversation is what pushed us to expand what we offered, giving members more reasons to come back more often.
Neither signal alone would have gotten us there. The data flagged that something was worth investigating. The conversation told us what it actually was. Founders who trust behavioral data blindly risk “fixing” a problem that was never really broken. Founders who only listen to feedback risk chasing whatever a vocal few are unhappy about that week.
None of this makes user feedback obsolete. It makes it more precise. Founders who chase feature requests end up with a product shaped by whoever happened to speak up loudest that week.
Founders who start with behavior—and confirm it with real conversations—end up with a product shaped by what’s actually happening at scale.
Forbes Technology Council is an invitation-only community for world-class CIOs, CTOs and technology executives. Do I qualify?
