How to Prepare Portfolio Founders for Investor Introductions

Prepare a portfolio founder for an investor introduction by checking the story, fit evidence, requested next step and sharing permissions before using anyone's network. Access is not readiness. A concise approved packet should make it easy for a relationship owner to decide whether a request is appropriate.

This lesson ends at readiness. Use the established warm-introduction guide for request wording and the request-tracking guide for follow-through. Do not create a competing template or mistake preparation for an introduction already made.

1. Separate a plausible target from a ready request

A target may appear relevant while the founder is not ready to explain the business or share evidence. Conversely, a well-prepared founder may be pursuing an unsuitable investor. Review these questions separately rather than allowing a strong relationship to override the fit check.

Ask what conversation the founder wants and why it could be useful now. Do not write a reason based only on the investor's fame. Check the current mandate, relevant person and any known exclusions through appropriate research. Unknowns should remain visible.

Preparation does not grant permission. Fred Wilson's double-opt-in introduction principle asks for both parties' agreement before connecting them. The relationship owner, connector and recipient still retain their own choices after the packet is ready.

2. Build the smallest useful packet

Founder introduction-readiness packet

Element	Ready state	Repair before proceeding
Company explanation	Reader understands user, problem and solution	Jargon conceals the business
Relevant evidence	Material claims have definitions and dates	Numbers or customer claims are unverified
Target rationale	Current evidence connects investor mandate to company context	Only “they invest in startups”
Specific ask	Clear conversation or next step	Vague access request or implied funding promise
Approved materials	Current version and sharing boundary recorded	Private draft or sensitive data shared by default
Follow-through owner	Founder can respond and prepare if someone opts in	No one available to act

Do not attach a full data room when a short approved explanation is enough. Confirm whether the founder permits a deck to be forwarded or wants a first permission check without it. Keep sensitive details out of a broadly shared operator queue.

3. Review with the founder, not around the founder

1. Ask for a two-minute explanation. Note what remains unclear without rewriting their company for them.
2. Inspect a small set of claims. Choose those that drive the request. Verify their sources and definitions.
3. Challenge the target rationale. Ask what supports fit and what could make the request inappropriate.
4. Confirm the exact approved packet. Record materials, version and sharing limits.
5. Choose ready, repair or hold. Give a specific reason and the next input, not an ambiguous “needs work.”

A readiness review is not an investment recommendation, endorsement or assurance of a response. The company and prospective investor make their own decisions.

4. Worked example: the right first return is preparation, not access

Illustrative example: Harbor Sensor asks a platform lead for an introduction to an industrial-software investor. Its draft packet says it serves “enterprise customers,” but the evidence includes paid small manufacturers and unpaid evaluations. The proposed deck also contains an unapproved partner logo.

The platform lead marks the packet repair, not ready. The founder supplies a current customer-definition note, separates paid users from trials and removes the logo until permission is confirmed. The investor rationale is narrowed to documented sector and stage relevance.

Completed readiness record

Company: Harbor Sensor, fictional.
Desired conversation: First discussion with a stage-relevant industrial investor.
Initial state: Repair; unclear customer definition and unapproved logo.
Correction: Approved segment description, dated paid-customer evidence.
Materials: Deck v 8, permitted for a named relationship-owner review only.
Target rationale: Documented sector/stage relevance; interest unknown.
Founder owner: Available to respond and prepare.
Readiness decision: Packet ready for relationship-owner consideration.
Introduction status: Not requested, accepted or sent by this review.

The record deliberately stops before the introduction lifecycle. The next person must still decide whether to ask and whether the request is welcome. This keeps readiness from being misreported as pipeline progress.

5. Copy the readiness checklist

Founder and company:
Desired conversation:
Clear user / problem / solution:
Approved evidence / period / definitions:
Target / relevant person / mandate evidence:
Known exclusions and open fit questions:
Specific ask:
Materials / version / forwarding permission:
Founder response owner and availability:
Ready / repair / hold:
Required correction / owner / review:
Who decides the next permission step:
Actual introduction state:

Common mistakes

• Using the strongest contact before the story is clear: Repair the packet first.
• Editing positioning without founder approval: Return the proposed wording for confirmation.
• Confusing support with endorsement: State what the operator reviewed and what they did not decide.
• Counting a packet as an introduction: Track readiness and actual relationship actions separately.

Completion check: The founder owns an accurate, usable packet and the next permission decision is explicit. Nobody's relationship has been committed by a checklist.