Founder Networking Worksheet: Relationships and Useful Next Steps
Build a founder networking worksheet around a relationship, a shared business question and a useful next action. Record what each person needs, what you can contribute, the evidence discussed and the agreed follow-up. For a Silicon Valley visit, use the same map to choose meetings before travelling and continue the relationships afterwards.
What this worksheet helps you decide
For each person, record the context in which you met, the business problem they described, a useful contribution you can make and permission for the next contact. Keep a trip meeting brief as one dated interaction within that relationship. A later conversation should build on the previous one instead of repeating a request for access.
Start with a shared question and a useful contribution
Write down why this person is relevant to the question you are working on and what you can contribute to the exchange. A job title or a place on a conference attendee list is context, not evidence of a relationship. Look for something specific you have discussed, reviewed or agreed to do together.
For a Silicon Valley visit, review existing records before requesting meetings. One person may be able to correct your understanding of a workflow; another may want feedback on a problem you have already solved. Choose a request that follows from that context. Record an untested reason for meeting as a hypothesis until the person confirms it.
Record what made the exchange useful
A useful contribution can be a relevant public resource, feedback on a draft or a demonstration that answers a question the person asked. Record what you offered, whether they wanted it and what changed after they received it. Sending a deck alone does not establish that it helped.
Daniel's published Delfast e-bike case describes demonstrations followed by pilots with agreed success criteria, negotiations and delivery. In a relationship record, distinguish the exchange that happened from a later test somebody has only proposed. A demonstration reviewed together is evidence of that interaction; a pilot belongs in the commitment field only when the people involved agree to it.
Prepare a dated meeting brief inside the relationship record
Keep one record per person. Add the following brief as a dated entry in its interaction history when a conversation is confirmed. Daniel's published GTM process describes an account brief before outreach; the meeting entry here captures what this particular person and you intend to discuss.
- Date and shared question: When will you meet, and which open question from the relationship record will you discuss?
- Context and evidence: What did the person previously say or review, and what remains a hypothesis?
- Participants: Who has agreed to join, and why is each person's perspective useful?
- Useful material: Which promised resource, draft or demo will you bring?
- Proposed next request: What limited next interaction might help, subject to the person's agreement?
After the conversation, add what changed to this dated entry. Update the relationship's existing Commitment status with any agreed action, owner and date, and update Permission and next contact with the agreed channel or pause. The brief records the conversation; those relationship fields hold the current follow-up status. Do not maintain a second, competing follow-up list.
Fields for repeated useful interactions
Use one relationship record per person, with a dated interaction log underneath. The blank fields below are an original editorial worksheet for pre-seed and seed founders. Copy them into a document or spreadsheet. Review them before a Silicon Valley trip and after each conversation. The purpose is to choose a useful next interaction and see whether earlier commitments were completed.
| Relationship field | What to record |
|---|---|
| Person and context | Name, role, where you met, and date. Leave unconfirmed responsibilities marked unknown. |
| Shared question | The business question both people agreed was worth discussing. |
| Useful contribution | Something you can offer now: feedback, a relevant public resource, or a promised demo. |
| Interaction history | Date, what was discussed, evidence shared, and what changed since the previous contact. |
| Commitment status | Action, owner, agreed date, and evidence of completion. Distinguish proposed from agreed. |
| Permission and next contact | Preferred channel, agreed follow-up, and any request to pause contact. |
| Relationship evidence | What you have actually done together, such as reviewed a workflow or completed a test. |
A relationship map connects these records around the question you are trying to resolve. Label each connection with its observed context: met through a peer, reviewed a demo together, or introduction requested. Keep a proposed connection visibly pending. Avoid assigning people a trust score based on their job title or the number of messages exchanged.
Fields for relevant introduction context
Add an introduction record only when there is a specific reason for two people to talk. Write down the recipient's relevant role, the shared question, why the timing makes sense, and the limited request. Include the evidence behind that relevance and a short description the connector can forward without rewriting. Record whether the connector has agreed to ask and whether the recipient has accepted. An offer to consider an introduction is still pending.
Ask permission before sharing private notes or contact details. Give the connector an easy way to decline. If the purpose is still vague, return to the account brief instead of asking for access to whoever they know. After an introduction, update the record with the actual response and the next step agreed by the people involved.
A hypothetical filled example: relationship depth
Hypothetical example: Maya is a seed-stage founder planning a Silicon Valley visit to discuss scheduling software. Alex is an operations manager she previously met at a founder event. The people, interactions and dates below are invented. Assume Alex has agreed to discuss a workflow, but purchasing authority and demand remain unconfirmed.
| Field | Filled relationship record |
|---|---|
| Shared question | Can a supervisor review shift changes without copying data between tools? |
| First interaction, October 6 | Alex described a manual handoff. Maya offered a draft workflow diagram based on that description; Alex agreed to receive it. |
| Second interaction, October 9 | Maya sent the draft diagram. Alex corrected the approval step and gave Maya permission to keep that correction in her workflow notes. Maya saved the corrected version with the October 9 entry. |
| Useful next action | Maya will bring a demo of the corrected handoff to an agreed October 20 meeting. Alex will review whether it matches the process. |
| Introduction context | Ask Alex whether the supervisor responsible for approvals would find a review useful. No introduction has been agreed. |
| Unknowns | Budget owner, security requirements, and willingness to run a pilot. |
The next conversation can start with the correction Alex made. That gives Maya a concrete reason to follow up and something useful to bring. The record supports a workflow review; it does not support calling Alex a customer, forecasting a sale, or claiming an investor introduction. If Alex declines the meeting, mark the proposed action closed and keep the earlier learning.
How to use the worksheet without treating assumptions as facts
Label each entry observed, reported by the person, or founder hypothesis. Attach a date and a source note to factual entries. Keep interpretation in a separate field: a person describing a problem does not establish that they control the budget. When a promised action is overdue, record that status without inventing a reason for the silence.
At a weekly review, check which promised contributions you delivered and which shared questions remain open. Continue where both people have a useful reason to meet. Pause where permission is absent or the question has been resolved. These are recommended working rules, not measured predictors of funding or sales. Keep only notes needed for the relationship and restrict access to private information.
Make room to complete your commitments
Before adding another meeting, check the contributions you have already promised. Leave time to revise a draft, send a useful resource or incorporate a correction. After each conversation, record what changed in your understanding. If two people describe different workflows, retain each person's context rather than combining the accounts into one positive story.
Send the promised material and update its completion status. Ask the recipient to confirm any proposed next action. A friendly conversation belongs in the interaction history; an agreed commitment needs a named person and a task. Use that distinction when deciding what follow-up is appropriate.
If YC is part of the plan
Keep application preparation separate from access claims. A mentor can review how clearly you explain the problem, what users do and what you have built. Do not plan a trip on an assumed admission or introduction. Check any current program arrangements directly with the program before booking travel.
Review the next useful interaction
After a trip or a week of conversations, review each relationship record: what did you learn, what did you deliver and what remains open? Carry forward the next contact only where there is permission and a useful shared question. Close completed actions so a later meeting starts from the current context. The worksheet is a recommended working method; the published Delfast case illustrates agreed tests, not a measured relationship score or a promised conversion rate.
Bring the worksheet to US market entry mentorship to review the next decision. Book a free 30-minute strategy session.
Frequently asked questions
What should a network relationship map include?
Record the person, how you met, a shared business question, your useful contribution, dated interactions, completed commitments and permission for the next contact. Mark proposed introductions as pending until the people involved agree.
What evidence should a founder collect for Silicon Valley networking?
Keep dated notes about what the person actually said, materials shared, corrections received and agreed follow-ups. Separate reported facts from your hypotheses about budget, interest or authority.
What are common mistakes in Silicon Valley startup networking?
Counting contacts without recording useful interactions, requesting introductions without a relevant question, and treating a friendly meeting as a commitment. Confirm the next action and its owner before calling it agreed.
Does mentorship include YC admission or investor introductions?
No. Preparation can improve the clarity of the business story and questions. YC admission, investor meetings and introductions are not promised.