Product diligence is not a feature review. It is reading the distance between what a company claims it's building and what the team in front of you can actually ship — and figuring out what that distance costs. One hour is usually enough.
There’s a specific kind of silence that happens on a VC diligence call right after you say something the partners weren’t expecting. I got used to that silence.
I work as a freelance product consultant through AlphaSense — the kind of arrangement where a firm brings me in late in the diligence process, after the financials are done, after the references have been checked, after the market map is built and the narrative makes sense on paper. They’ve done everything right. What they haven’t done is spend real time with the product. So they get me on a call for an hour, usually with the founders on the other side, and they listen while I ask questions that aren’t in any diligence template I’ve ever seen.
The thing that surprised me most, honestly, wasn’t what I found in the products. It was how rarely anyone had asked these questions before I showed up. Firms would be forty days into a process, within handshake distance of a term sheet, and no one had sat with the PM and asked: so walk me through what happens when this breaks. Nobody had asked: who actually uses this at 9am on a Tuesday when there’s no demo happening? The financial model had assumptions baked in about product capability, about roadmap delivery timelines, about where the TAM expanded to — and those assumptions were just floating there, unexamined, because reading a product is a different skill than reading a business.
The Series B that didn’t close
There was one deal in particular that I think about sometimes.
Series B, B2B workflow software, $42M pre-money on the table. The deck was genuinely good — 3x revenue growth, real enterprise names, and an AI story that the lead partner told me was the most differentiated he’d seen in the category. The founders were sharp. The pitch was clean. I remember getting on the call thinking this one probably holds up.
I asked the CTO to walk me through the routing logic. Not the demo — I’d seen the demo, it looked great. I wanted to understand the actual decision model. How does the system decide where to route? What are the inputs, what are the weights, what happens when two rules conflict at the edge?
What he described was a rules engine. A good one — well-maintained, thoughtfully built — with a machine learning model trained on historical decisions sitting on top of it to handle the cases the rules didn’t cover cleanly. I want to be precise here: there was nothing dishonest about it. But a rules engine with an ML wrapper is not the same thing as an AI-native routing system, and at a 12x revenue multiple with the AI capability priced in, that gap is material.
Then I asked about multi-tenancy. It was on the roadmap for Q3, five months out, and the whole enterprise expansion story depended on it — two of the logos on the deck couldn’t grow beyond their pilot contracts without it. The founders were confident. The engineers had scoped it. Five months.
I’d watched a few companies try to bolt on production-grade multi-tenancy at this stage, with a team this size, on a codebase that wasn’t designed for it from the start. Across those examples the average time to actually ship it — not demo it, ship it — was closer to fourteen months. The TAM model was priced for Q3. The architectural reality was somewhere in early the following year, at best, and that’s if nothing else got in the way.
The partners went quiet for a moment after I laid that out. That was the silence I mentioned.
They didn’t write the check.
What product diligence actually is
I’m not telling that story to make a point about being right. I’m telling it because it illustrates the specific thing that product diligence actually is, which is different from what most people assume it is. It’s not a feature review. It’s not a UX critique. It’s reading the distance between what a company claims it’s building and what the team in front of you is actually capable of shipping, and then figuring out what that distance costs.
Every product has a version of this gap. The question is whether it’s priced in.
The questions that surface signal
When I think about the questions that consistently surfaced real signal in those calls, they weren’t exotic.
Where exactly does a competitor stop making progress against you — not conceptually, architecturally?
What’s the hardest thing on your roadmap in the next six months, and what’s the evidence that your team has shipped something of equivalent complexity before?
If I looked at your system’s failure states right now, the places where something goes wrong and the product has to recover — what do those look like and who owns them?
The technical questions weren’t about catching anyone out. They were just about finding out if the people building the product had actually run it under pressure, or only under ideal conditions.
The investment memo is a story about a business. The product is the part of that story that either holds the weight or it doesn’t. That’s the thing you can’t see from the cap table.
One hour was usually enough to find out which one you were looking at.