Product Due Diligence

Founders dream the vision.
Product builds the reality.

Let's
talk

For VCs, PEs, and boards. Technical due diligence tells you if the architecture is sound. Product due diligence tells you if the company is building the right thing, and that question does not get asked nearly enough.

Founders present a captivating vision. Without strong product foundations underneath it, that vision becomes inefficient use of capital and lost market opportunity. Product managers are the people who turn a vision into an actionable plan, and their role is routinely underestimated or brought into the conversation too late.

While your CTO advisor looks at the code and the infrastructure, I am looking at the roadmap, the customer understanding, the product strategy, and whether the person leading it can operate at the next stage.

It is not a replacement for technical due diligence. It is what sits alongside it.

The six-lens assessment

Strategy and vision

Whether there is a clear product vision, and whether the roadmap is tied to measurable outcomes rather than to whoever asked loudest.

  • Is there a clear product vision?
  • Is the roadmap tied to measurable outcomes?
  • How easily can the team pivot as the landscape shifts?

Business understanding

Whether product understands the business model and builds to support it, and where the company actually sits in its growth journey.

  • How does product impact key growth metrics?
  • Pre-PMF, scaling, or platform expansion?

Customer understanding

Whether product is genuinely connected to the customer and can speak on their behalf with confidence. I look for evidence, not conviction.

  • How does the team gather insights?
  • Does product have direct customer access?
  • What is the research, test, build, measure cycle?

Team and talent

Who is in charge of product, and whether the behaviors of product management live somewhere even when nobody carries the title.

  • How do product, engineering, and design collaborate?
  • Are PMs empowered to say no and drive outcomes?
  • Who owns the trade-off decisions?

Technology alignment

Whether the stack supports the product strategy or constrains it, and whether engineering and product are speaking the same language.

  • Is the stack scalable against the strategy?
  • Can the team ship consistently and respond to change?
  • Are commitments made together or in silos?

Metrics and results

Whether data drives outcome-oriented behavior, or whether the numbers get reported after the fact and never change a decision.

  • Are engagement, retention, and activation in the decisions?
  • Do tech health metrics factor into build trade-offs?

What I am looking for

Red flags

  • No dedicated PMs. Missed objectives, no clear accountability.
  • PM by committee. Fragmented decisions, opaque prioritization.
  • Founder or sales driven. Direction set by pressure, not customer insight.
  • Disconnected metrics. Numbers that do not track customer behavior.
  • Feature-driven roadmap. Output measured instead of outcomes.
  • Leadership turnover. Broken continuity in product and tech.

Green flags

  • Clear product vision. Guides decisions and resource allocation.
  • Empowered product managers. Discovery and delivery skills, real authority.
  • Collaborative culture. Product, tech, and design working as equals.
  • Leadership values experimentation. Teams can test, learn, and be wrong.
  • Integrated feedback loops. Customer input reaches the roadmap systematically.
  • Measurable success metrics. Meaningful data, not vanity stats.

How it runs

Length depends on the deal. A fast read before an investment committee might take a week. A full assessment on a larger company with real access to the team and customers takes longer. I scope it to your timeline and tell you honestly what I can and cannot get to in the time available.

Whatever the length, the work moves through the same four stages.

One
Intake

Orientation

Review everything available: deck, data room, roadmap documentation, any existing customer research. An independent look at the platform and where the company sits in its competitive landscape. Initial hypotheses formed, interview list and access agreed, structured technology survey sent to the team.

Two
Conversations

Assessment

Interviews with founders, engineers, and whoever else you can facilitate. A targeted customer conversation where access allows, since even one call is useful. What I hear gets cross-referenced against what the materials say, and the hypotheses get sharper.

Three
Synthesis

Pressure testing

Findings tested against the industry backdrop. Red and green flags identified with supporting rationale. Open questions closed out, and the assessment drafted.

Four
Delivery

Assessment and readout

Initial findings can be delivered verbally ahead of your investment committee if the timeline demands it. The written assessment follows, covering product strategy and vision, team capability and fit, technology risk and readiness, and product-market fit signals. Then a readout session to walk through what it means for the investment.

Throughout, I share what I learn as I learn it. No surprises at the end.

Where technology fits

Most of the time my product read runs alongside a dedicated technical due diligence workstream. That is the ideal setup, and I would rather coordinate with a specialist than overlap with them.

Where you do not have one, I can cover light technical due diligence at the same time. Architecture, delivery capability, build versus buy decisions, and key-person concentration. Be aware that this changes the shape of the overall assessment, and depending on the stack we may still need specialist expertise in specific areas. Where I find gaps that need a deeper look, I flag them explicitly rather than paper over them.

Working together

Per assessment

A single deal, scoped and priced on its own. Right when you want a product read on something specific and there is no ongoing need.

On retainer

Available across your pipeline and portfolio. Useful when deals move fast, when you want product perspective before something reaches diligence, or when portfolio companies need a periodic read.

NDA as standard. I will tell you up front if I have a conflict, and I will not take a diligence engagement against a company I have advised.

Why me

25

Years in tech, 22 of them in product. Amazon, Expedia, and two Sequoia-backed startups. I know what good looks like, and what it looks like when a talented team is building in the wrong direction.

Both

Operator and coach. ICF PCC credentialed, so I can read a product organization and read the people running it in the same conversation.

Live

Currently fractional CPTO at a travel startup. Still inside the work, not commenting on it from a distance.

Have a deal in motion?

Tell me the shape of it and the timeline you are working to. If a product read would not change your decision, I will say so.

Book a call →