#116: Deal Gap
March 8, 2026 – DevTools Brew #116
I’m Morgan Perry, co-founder of Qovery. Every week, I share the raw, often uncomfortable lessons from building and scaling a tech startup from 0 to 1 and beyond.
This edition is about the moment you realize that building a product and winning deals are two very different crafts.
The Deal Gap
Where most technical companies actually lose deals.
For a long time at Qovery, sales happened the way it often happens in companies building technical products. The product naturally sits at the center of everything. When you spend years building something complex, refining every detail, talking constantly to users, you start believing that if the product is good enough, the rest will follow naturally.
In the early days that belief even looks true. You explain what you built, developers immediately understand the value, and the conversation moves forward almost by itself. It doesn’t really feel like selling. It feels like talking about product with people who share the same context.
That’s more or less how things started for us. Inbound started growing. A few outbound experiments. Partners brought some opportunities. Deals entered the pipeline and the company moved forward.
Then something subtle started to feel off. Deals were entering the pipeline but too many of them were not closing. The conversations were good, the demos were appreciated, people clearly liked the product, yet deals kept drifting. Nothing was obviously broken, but the system didn’t feel stable.
The explanation we told ourselves at first was simple: we needed more pipeline. More leads, more SDR activity, more deals entering the funnel. That’s a very natural conclusion when you think like a product builder. If something doesn’t convert, you assume the problem is volume.
So we pushed harder on top of the funnel. We increased outbound activity, we hired, we generated more pipeline. But when we started looking closely at the deals we were losing, something interesting appeared. A large number of them were marked as “not the right timing”. At first that sounds reasonable but once you dig into it, “timing” often means something else.
In most of those deals people actually liked the product. Developers understood it very quickly. The issue was somewhere else. The organization around them didn’t know where the product really belonged. They didn’t know where it fit in their roadmap, what concrete outcome it unlocked, or who inside the company should actually own the decision. And that’s when you realize something about technical products: they rarely live inside a single persona. They sit across teams. Developers see the value first, but platform teams, infrastructure leadership, security, sometimes even finance eventually become part of the conversation.
At that point the deal stops being about the product itself. It becomes about alignment inside the organization. Who benefits first? Who takes the risk of change? What happens if nothing changes?
Those questions rarely emerge naturally when you approach sales like a product conversation. They require discovery. I mean real discovery. Understanding the operational pain behind the technical problem, the incentives inside the organization, and the cost of inaction.
This is where our mistake became clear. We didn’t have a top-of-funnel problem but instead had a middle-of-the-funnel problem. We weren’t losing deals because we lacked activity but instead were losing them because the deals themselves were not structured well enough.
Discovery wasn’t deep enough. The demos were technically strong but not always connected to business outcomes. Internally we also created a lot of noise. Conversations about deals were happening everywhere, Slack threads multiplied, people jumped in to help, ideas were flying around. But no one clearly owned the progression of the deal. When no one owns the next step, deals drift.
That’s the part I underestimated the most. And it’s my responsibility. I was running sales as a founder. I hired our first sales people and I was involved in most deals. But being good at explaining a product you deeply believe in is not the same thing as building a sales system that consistently wins. Coaching sales teams, structuring deal strategy, preparing discovery, creating repeatable processes…. that’s a different craft entirely.
The click and shift happened while bringing in an experienced Head of Sales. This made that obvious very quickly. What you really gain is pattern recognition. Someone who has seen these situations many times before and can immediately see where deals are actually won and where energy is wasted.
The interesting thing is that the improvement we’re seeing now doesn’t come from suddenly generating more pipeline. The pipeline was never the real issue. What changed is the quality of the deals themselves. Discovery is deeper, deals are prepared more carefully, and the team understands much earlier why we can win a deal or why we probably won’t.
If I could go back, there are a few things I would do differently. I would bring experienced sales leadership earlier, probably just before our Series A when inbound traction started bringing larger organizations into our pipeline. Even if that meant making mistakes earlier. Even if it meant adjusting the structure along the way. I would spend less time trying to increase activity and more time improving the quality of deal preparation. And I would accept earlier that selling a technical product into complex organizations is not just about explaining the product well.
The biggest accelerators in a company are rarely dramatic product pivots. More often, they are the people who change how the system operates. That took me longer to understand than I expected but it’s one of the most valuable lessons I’ve learned so far.
That’s it for me today and thanks for reading :)
— Morgan
You can reach out to me on LinkedIn.
Ps: Five months already. Turns out a few simple things compound well: long walks, deep talks, good laughs, shared coffee… and perfect scallops. Five months in and it still feels pretty special (L.R.P).