When leaders think about the most decisive moments in a software project, it is easy to focus on delivery milestones or product launches. However, the true make-or-break often occurs much earlier in the technical discovery process.
Patrick Dajos is the founding engineer at San Francisco-based Hyperbound and founder of the premium development agency Avalonia, he believes that the technical discovery process is the stage where real success is defined.
“Miscommunication at the start costs ten to twenty times more later,” says Dajos. “It means more iterations, higher costs, and more effort. That’s why I focus so much on understanding the client from the very first call.”
With experience spanning early stage startups to Fortune 10 companies, Dajos’ perspective is shaped not only by years of building systems from scratch, but also from his experience translating non-technical ideas into working products.
Beyond Requirements: Discovery as Relationship-Building
“Discovery isn’t really about collecting requirements,” he says. “It’s about building a relationship with the client. Clients describe what they want, but rarely why they want it. If you don’t surface that why, you’ll make the wrong trade-offs later.”
This emphasis on intent is what makes discovery tricky but also essential. Even highly technical stakeholders often describe symptoms instead of causes. “Once you nail that shared understanding of the why, the product stops feeling like guesswork. It becomes more predictable, and you can already anticipate what features are going to come up next.”
Technical discovery is as much about psychology and power dynamics as it is about scope and architecture. In business-to-business SaaS in particular, the relationship between engineers and non-technical stakeholders is “extremely valuable.” In his experience, when those relationships click, clients rarely churn.
Case Study: A Fortune 10 Client
Hyperbound, where Dajos is a founding engineer, recently worked with a Fortune 10 company that requested private role-play sessions as a feature. On the surface, it was a straightforward request that, without deeper inspection, appeared purely technical. However, Dajos recognized that understanding the business culture and internal dynamics was just as important as the technical specification.
“They didn’t explain why at all, only that they wanted private calls,” he recalls. “At that scale, hierarchies are filled with ego and people worried about losing their jobs. It meant the feature had to be inaccessible to managers and admins, only visible to the person who made the call.”
Because he understood the company’s dynamics, his team delivered the correct solution on the first iteration. “That’s when you realize discovery calls aren’t only about technology. They’re about empathy and context. Getting that right saves months of wasted effort.”
Practical Tips for Effective Discovery
Dajos has developed three techniques for making discovery productive for both clients and engineering teams.
- Translate features into stories. “If you can’t describe it in one clear sentence that makes sense to a non-engineer, you don’t understand it well enough,” he says.
- Visualize ideas early. “Even quick wireframes or flow sketches during a Zoom call help. It removes ambiguity. Don’t be afraid to sketch, even badly—it always improves understanding.”
- Reflect and rephrase. Dajos often rephrases client goals in his own words using the simple framework: So what you really want is X because of Y. “That single line prevents weeks of misalignment,” he explains.
Finally, he ensures engineers know not only what to build but why it matters. “When engineers understand the why, they build ten times better solutions. And if they see the impact a feature has for a big client, the motivation is enormous.”
The Role of AI in Discovery’s Future
Artificial intelligence is already changing how discovery sessions unfold. With tools that summarize prior notes, highlight contradictions, and even simulate user flows, teams walk into meetings better prepared than ever. “AI isn’t replacing people, but it’s removing friction,” Dajos explains.
The biggest benefit, he argues, is focus. “The system captures everything, so I can focus on the relationship and the conversation itself. It’s made my work easily ten times faster and cleaner.” Looking ahead, he believes leaders will need to work with AI tools to interpret the underlying meaning of client requests, check for accuracy, and make sure the system really “understands” the intent behind what’s being said.
For Dajos, the ultimate lesson is that technical excellence is only half the story. “As an engineer, you might think your best job is extracting requirements and building the best product possible. But that’s only 50% of success. The other 50% is the relationship with the client.”
Readers can connect with Patrick Dajos on LinkedIn to learn more.
