Customer Discovery Is an Engineering Problem

Ash Maurya—my co-founder at LEANSTACK, and the author of Running Lean—has spent years teaching founders how to validate their business ideas through structured customer discovery. Working alongside him has fundamentally changed how I think about what engineers build and why.

The standard framing is that customer discovery is a business activity. Engineers build the product; business folks talk to customers. The feedback comes back eventually, filtered through someone’s interpretation, and the engineers build the next thing.

That model is too slow, too lossy, and too disconnected. The best customer discovery is engineered.

Usage patterns are a form of customer communication

Your users are telling you what they think about your product every time they use it—or don’t. The path they take through a workflow. The features they open and never complete. The screens where they bounce. This is honest feedback, uncontaminated by social politeness or the desire to be helpful to the person doing the interview.

Building the instrumentation to read that signal is engineering work. And more importantly, interpreting it correctly requires understanding the product deeply—which engineers do.

When we’ve done our best product work at LEANSTACK, it’s been when engineering was reading usage data directly and forming hypotheses, not waiting for a product manager to translate.

The feedback loop has an architecture

Getting from “user does a thing” to “we understand why and know what to do next” is a system. It has components: event tracking, a way to see aggregate patterns, a way to dive into individual sessions, a way to connect quantitative signal to qualitative conversations.

That system doesn’t build itself. And a poorly designed feedback loop—one that captures too little, or too much noise, or that nobody actually looks at—is an expensive liability. You build false confidence from the data you do have or you ignore it entirely because you don’t trust it.

Closing the loop requires shipping small

The other engineering prerequisite for good customer discovery is the ability to ship changes quickly. If you’re deploying every two weeks, your feedback cycle is two weeks minimum—often much longer. If you can ship daily, you can learn daily.

This is why CI/CD isn’t just a reliability practice. It’s a learning practice. The teams that can move fast aren’t just faster; they’re smarter, because they get more iterations and more signal in the same amount of calendar time.

The uncomfortable truth

Most engineering teams are better equipped to build things than to figure out whether the things they’re building are right. That’s a skills gap, but it’s also a values gap—a cultural assumption that what gets measured is the code, not the outcomes.

The fix is treating customer signal as a first-class engineering concern. Instrument everything worth measuring. Build the tooling to read it. Put engineers in direct contact with customer feedback. And ship small enough that the feedback loop is actually tight enough to act on.