Around 2017, I joined a small network-security startup as VP R&D. The product scanned a customer’s network, detected every connected device, mapped the possible attack paths between them, and produced a prioritized list of what to fix first. It was a good idea and, in a lab, a good product.

This is the story of what happened when I got there, what I tried to do about it, and the year it took me to close the company down.

What Was Being Sold

The demos worked. On a small, well-behaved network, the product did exactly what the pitch said. Every prospect who saw a demo left the meeting excited. The pipeline was strong.

The gap the demos did not show was that every one of those pilots, once it was pointed at a real customer network, needed the product to handle roughly ten times the load it had actually been built for. A demo network is a few hundred devices you control. A pilot network is a real enterprise, with tens of thousands of devices, wildly varied hardware, printers pretending to be servers, IoT things pretending to be nothing, and a security team who wanted a full attack-path map by end of week. The product could not do that. Nobody on the engineering team had signed up for a promise that it could.

Sales kept selling the demo. Every closed pilot came with a delivery commitment that the engineering team knew, on the day it was signed, was not going to be met.

The Kitchen Argument

My clearest memory of the first month is standing in the company kitchen and hearing the VP of Sales, at real volume, telling our architect that he could not accept that the pilot he had just closed was not going to work. The architect was calmly repeating that the pilot he had just closed required the product to do ten times what it could actually do. Neither of them was wrong about their own job. Sales had closed the pilot the company needed to survive that quarter. Engineering could not deliver it in the window sales had committed.

This is the shape of a sales-product gap that has already killed the company. Not the moment it kills the company. The moment you can hear it out loud.

The Hardware Ask Was Killing Pilots Too

The product ran on-prem, on customer hardware, because customers’ security teams did not want a network scanner reporting from someone else’s cloud. That was reasonable. What was not reasonable, from the customer’s side, was the spec sheet the product needed: a very high-capacity server that most enterprises did not already have and did not want to buy in order to run a pilot.

“Buy a large server first” is a hard first ask, especially when the vendor is a small startup. Most customers said no. The pilots that closed were the pilots where sales had reframed the ask in ways engineering could not stand behind.

The Fix I Tried

The technical shape of the fix was clear. Instead of asking every customer to buy a permanent, high-capacity on-prem server, the product should run as a dynamic Docker cluster: on request, spin up containers that could handle the scan for this network right now, run the scan, produce the result, and shut down. On-prem when the customer needed on-prem. Cloud when they were fine with cloud. Ephemeral either way.

This is a solvable engineering problem. It is not a small one. It required rewriting how the scanner claimed resources, how state was carried across the scan lifecycle, how results were persisted after the containers went away, and how the deployment was packaged for customers whose ops teams had never seen anything Docker-shaped before. Months of work.

Most of the customers we lost, we would have kept if we had shipped this. Some of the pilots we blew, we would have saved.

Why It Did Not Ship

The runway did not stretch that far. By the time I understood the shape of the problem well enough to be sure the docker-on-demand approach was right, the finance situation was already tight. By the time I had a working prototype, the finance situation was worse. By the time it was production-ready in my head, we were already past the last month where a rewrite could have saved the company.

I have thought about this piece of the story more than any of the others. Not because I got the technical direction wrong, but because I got the sequencing wrong. If I had spent the first two weeks not on assessing the codebase but on assessing the runway, I would have known earlier that the rewrite could not save us and that the money and attention would have been better spent trying to close the sales-product gap at the pipeline level, not the product level. The pipeline path might not have worked either. But it was faster.

Twenty-Five Conversations

When it was clear the company was not going to survive, I let all twenty-five people go, one at a time. Some of them were engineers I had personally recruited weeks earlier. Some of them had been at the company longer than the leadership. Every one of them had done exactly what they were supposed to do. The company was not failing because of them.

This part of the story is the one I do not have a clean lesson for. The lesson everyone wants you to draw is that you should let people go faster, or slower, or in one meeting, or with more notice, or with less notice. I am skeptical of all of those. What I know is: I did it one person at a time, I said the true thing about why, I did what I could to help every one of them land the next job, and it still felt exactly as bad as it should have.

The 2026 Version of This Pattern

Nine years on, I watch a specific version of this play out at almost every AI-first B2B startup I talk to. The demo works. The prospect is excited. Sales closes the pilot. The pilot requires the model to do X at customer scale, on customer data, with customer edge cases. X was demonstrated exactly once, on curated data, in a script that got told exactly which examples to use. Nobody wrote down that the demo was the ceiling of what X could do, not the floor.

The engineering team knows on signing day that the pilot is not going to work. Nobody says it, because saying it publicly torches the deal, and the deal is what keeps the next fundraising conversation alive. The company optimizes for winning pilots it cannot deliver, right up until the moment the pilots start not renewing.

The specific rule I keep coming back to for AI startups is: the sales spec has to be a subset of eval-tested capability, not a superset. If the model has been evaluated to do X at eighty-percent accuracy on real customer data, then the sales team can sell “does X, roughly eighty percent of the time, on data that looks like yours.” They can sell that all day. What they cannot sell is “does X.” Because “does X” is the demo. And the demo is not the product.

What I Would Do Differently

Three things, in this order.

Assess runway before code. The first week at any senior technical role at an early-stage company is not for reading the codebase. It is for reading the bank account and the pipeline. Everything else is downstream.

Put engineering in the sales cycle earlier. Not to slow deals. To catch the ten-times-capacity commitments before they become pilot commitments. Sales does not have to know what the product cannot do. They just need someone in the loop who does, before the ink is dry.

Build the eval-to-sales-spec discipline explicitly. This one is easy to describe and hard to implement. It means the sales team knows, at any given time, the exact capability envelope the product has been tested inside. It also means engineering knows they owe sales a broader envelope every quarter. Both sides are accountable to the same document. The document is the contract between them.

Let’s Talk

If your team is in the middle of a sales-product gap that is starting to feel structural, and you want a second read on which of the levers above will actually move the number in the runway you have, that is exactly the kind of decision I help work through with founders. Happy to look at your pipeline and your capability envelope and tell you what I would do. No pitch. Reach out.