The Questions Should Change as the Company Does
A stage-aware field guide to product and technology diligence — from Pre-Seed through Series B+.

I've spent more than two decades building technology products, and I've also advised VC and PE firms on product and technical diligence. The questions I ask have changed over time—not because I found a better checklist, but because I've lived what happens after the answer.
Prototype → production → integration → security review → procurement → deployment → adoption → scale → technical debt → organizational change → upgrade → failure → remediation. And then you do the whole damn thing again.You start to see how decisions travel.
A rational shortcut today can become an expensive constraint later. A technically elegant product can still fail at deployment or adoption. A risk that barely matters at Pre-Seed can become a hard gate at Series A.
Which led me to a simple principle:
The questions should change as the company does.
Pre-Seed: What are we trying to learn?
Seed: What are we trying to prove?
Series A: What must become repeatable?
Series B+: What has to scale without breaking?
Take technical debt.
At Pre-Seed: does the shortcut help us learn faster?
At Seed: is it interfering with real deployment?
At Series A: is it constraining repeatability or enterprise readiness?
At growth stage: does it threaten scale, security or economics?
Same issue. Different stage. Different consequence.
Good diligence isn't about pretending we have every answer.
It's understanding:
What do we know?
What do we believe?
What are we testing?
What don't we know yet?
What risk have we consciously chosen to accept?
And then asking: If we're wrong, where does the consequence show up next?
I've used versions of these questions on both sides of the table—including on my own company.
They're not definitive. They evolve with the company.
Some came from experience. Some came from mistakes. Some came from operators-turned-investors who were generous enough to share how they think.
The best investors I've worked with don't use diligence to prove that founders lack answers.
They use it to understand the gaps, clarify which ones matter, and decide whether they want to keep leaning in.
Those are the partners worth having beside you when the work gets hard.
I pulled the framework into a short field guide:
A Stage-Aware Field Guide to Product + Technology Diligence.
For founders, operators and investors trying to distinguish normal uncertainty from the gaps that are becoming consequential.
Because the objective isn't to ask the hardest-sounding question.
It's to ask the right question for the company in front of you.
I've shared versions of this with fellow founders and VCs I've advised, and I thought I'd put it here for anyone raising right now.
I don't particularly want to add to the noise. I'd rather add to the hard signals — the questions and frameworks that help us make better decisions when the answers aren't obvious.


