Customer Discovery Is a Technical Skill, Not a Soft One

There's a habit in engineering culture of treating customer discovery as pre-work someone else does: a PM hands over a requirements doc, and the "real" work starts once the ticket is written. I think that split is a mistake, especially in enterprise software, where the requirements doc is usually a translation with information loss baked in.

Discovery is a technical skill because the questions that matter are technical questions in disguise. "How do you currently reconcile these two systems?" isn't a soft question, it's asking you to reverse-engineer a data model that exists only in someone's spreadsheet habits. "What happens when this exception occurs?" is asking you to find the edge cases before you've written a line of code. The people best equipped to ask these questions well are the ones who already know what a system needs in order to be buildable, because they know which answers will matter six weeks from now during implementation.

I try to run discovery conversations like a systems interview, not a sales call. I want to know what the current tool actually does, not what it's supposed to do. I want to see the spreadsheet, not hear it described. I want to know what breaks the process today, because that's usually a better predictor of value than anything on a wishlist. And I want to know who signs off on a decision, because the technical design has to route through the same approval structure the current process does, or it won't survive contact with the organisation.

The output of good discovery isn't a list of features. It's a shared, specific model of the problem that both sides can point to and say "yes, that's what's actually happening." Everything else, architecture, scoping, even the pitch to leadership, gets more honest once that model exists.