Founder Dive Template
Founder Dive Template gives founders a reusable note for definitions, boundaries and examples. Use it when people use the same words while meaning different levels of founder involvement.
Keep the method small: one signal, one owner, one move and one review point.
Summary
Founder Dive Template is a small operating artifact for turning founder context into a clear written note.
Use it when the team needs repeatable language for definitions, boundaries and examples. The template should capture the signal, owner, decision and review date without turning the work into paperwork.
A useful template gets reused because it is short. If people avoid filling it in, the format is too heavy or the owner is unclear.
What this founder deep work template is for
Founder Dive Template is a small written tool. It helps the founder turn private context into a usable operating note.
The template should not become documentation theater. If it does not change a decision, handoff or review, it is too detached from the work.
Use it when people use the same words while meaning different levels of founder involvement.
The working shape
Signal: what evidence deserves attention?
Owner: who carries the work after the founder input?
Founder level: observe, question, recommend or decide?
Review: when will the result be checked?
What does the founder know that the owner may not see yet?
Who should carry the work after the founder input?
What action changes the situation before the next review?
What evidence will prove whether the move helped?
How to fill it in
Use plain language. If the note sounds like a policy document, people will avoid it during real work.
Name the tradeoff. Founder context is most useful when it explains why one reasonable option loses to another.
Keep the review point close enough that the lesson is still fresh.
- Write the signal in one sentence.
- Name the owner and the decision level.
- Add the constraint: time, cash, customer risk or standard.
- Write the next move in active language.
- Set the review date before the note is shared.
- After the review, keep the reusable rule and delete the noise.
Filled-in example
A founder joins a customer review and hears the same objection twice. The weak move is to rewrite the plan in the meeting. The stronger move is to capture the objection, ask what evidence would change the next release and set a review after two more calls.
A team lead asks for help because delivery is strained. The founder notices that the issue is not capacity yet; it is unclear ownership. A one-week ownership map protects the standard better than a rushed hire.
A pricing decision stalls because everyone wants more data. The founder names the real risk: a low price may teach the wrong customer behavior and make the later correction harder. In that case, a direct decision may be cleaner than another discussion.
The quality bar
A good template makes the next similar decision easier.
A weak template preserves the founder’s opinion without making the operating rule clear.
The difference is ownership. If no owner changes behavior after the note, rewrite it.
Source context
The outside references are useful, but the work has to land inside a normal week. Paul Graham’s original essay, Y Combinator’s essential startup advice and Y Combinator’s Do Things That Don’t Scale all point toward one practical idea: founders need to stay close enough to learn without making every important decision dependent on founder mood.
The sources are useful because they point back to behavior: talk to users, stay close to the work and avoid premature process.
The template is the bridge between that advice and the next operating week.
Where to use it next
Pair the template with Startup Execution Checklist.
Then compare Founder Involvement Ladder, Founder Mode for Customer Discovery and Startup Priority Review for the next practical artifact or guide.
The Starter Kit can hold the reusable version once the team has tested it.
How to read the founder deep work signal
Start by separating a signal from a mood. A signal has evidence: a customer sentence, a stalled owner, a cash constraint, a repeated quality issue or a decision that keeps returning. A mood may still matter, but it should not be treated as proof until the founder can name what changed in the work.
The founder should ask: what did I see that the owner may not see yet? That question keeps the conversation grounded. It also prevents the founder from turning a private discomfort into a public emergency.
For dive Template, the signal should be specific enough that a teammate can repeat it without adding interpretation. If the signal gets softer each time someone repeats it, the founder has not translated it well enough.
A strong signal also has a shelf life. If the team waits too long, the evidence goes stale and the discussion becomes opinion. Write it down while the context is still fresh.
The ownership boundary
The owner is not the person who speaks most in the meeting. The owner is the person who carries the next move after the founder leaves. That distinction matters because founder mode often fails at the handoff point, not at the insight point.
Before the founder gives input, name who owns the decision after the input. If the founder is only observing or questioning, the owner should still be able to choose. If the founder is deciding, the owner should know what part of the work remains theirs.
The boundary should be visible in the language. Use sentences like “you own the next move” or “I am deciding this part because the risk is hard to reverse.” Clear language reduces politics.
Do not use founder involvement to create two owners. Shared ownership sounds collaborative, but in a tense week it often means nobody knows whose standard wins.
What evidence makes this worth founder attention?
What breaks if the founder stays out?
Who owns the next move after the discussion?
When will the result be checked?
Founder deep work edge cases
Edge case one: the owner is capable, but the decision touches founder-only context. In that case, the founder should share the context first and decide only if the tradeoff still requires it.
Edge case two: the founder is right, but the timing is wrong. A correction delivered after the team has already committed can create rework that costs more than the original issue. Review timing before stepping in.
Edge case three: the team asks for a founder decision because it feels safer. That is a dependency signal. The founder can answer, but should also ask what evidence would let the owner make the call next time.
Edge case four: the decision is reversible, but the learning value is high. Let the owner act, then review the result. That is often better than protecting the team from every imperfect call.
What a strong review note looks like
A useful review note is short: signal, founder level, owner, move, result and lesson. Anything longer risks becoming archive material instead of operating memory.
The result should describe what changed in the work, not how everyone felt about the conversation. Did the owner move? Did the customer signal sharpen? Did the team need less founder translation afterward?
The lesson should be portable. If it only explains one special case, it may be worth keeping, but it is not yet a rule. A rule helps a teammate handle the next similar moment with less founder input.
The review note also protects the founder. It makes the cost of involvement visible. If every week has too many founder notes, the system is asking the founder to compensate for missing ownership or unclear standards.
Did the work move faster without hiding the tradeoff?
Did the decision protect customers, standards or cash?
Did the owner leave with more authority?
Can the team reuse the rule next time?
The working standard
The standard is not perfection. The standard is a clear enough next move that the team can act, learn and adjust without waiting for another founder interpretation.
Use Startup Execution Checklist when the team needs the broader operating frame. Compare Founder Involvement Ladder, Founder Mode for Customer Discovery and Startup Priority Review when the next issue sits beside this one and needs a connected guide.
If the article creates a useful rule, store it in the Starter Kit so the team can reuse it during the next operating review.
- Start with the decision or handoff being reviewed.
- Write what the founder did: observed, questioned, recommended or decided.
- Check whether the owner moved with more clarity afterward.
- Compare expected evidence with actual evidence.
- Keep one lesson for the next similar decision.
- Remove any habit that created delay without learning.
FAQ
What is Founder Dive Template?
Founder Dive Template is a practical BuildMode guide for operating language. It helps founders name the signal, choose the right involvement level, protect ownership and review what changed.
When should a founder use it?
Use it when people use the same words while meaning different levels of founder involvement. It works best when there is a real decision, handoff, customer signal or operating risk that needs a clearer next move.
Who should own the work afterward?
The owner should usually be the person closest to the work. The founder should keep ownership only when the decision is hard to reverse or tied to founder-only context.
What should be written down?
Write the signal, the owner, the founder level, the next move and the review point. A short note is enough when it changes behavior.
How does it avoid micromanagement?
It names ownership before the founder steps in. Micromanagement removes ownership; this method should make ownership easier to see.
What is the first step?
Pick one live decision or handoff. Do not start with a broad operating cleanup.
How often should it be reviewed?
Review it at the next weekly operating review or sooner if customers, cash, hiring standards or hard-to-reverse choices are affected.
What evidence should count?
Use customer behavior, sales objections, support patterns, product quality, delivery risk, cash timing and team ownership signals.
What if the founder already knows the answer?
Then the founder should say the decision directly and explain the tradeoff. Questions are useful only when the owner can still choose.
What if the team disagrees?
Bring the disagreement back to evidence and ownership. If the disagreement is about preference, the founder should name the standard being protected.
Can solo founders use it?
Yes. A solo founder can use it as a self-review by naming which operating hat owns the next move.
Can teams with managers use it?
Yes. The founder should become more precise as the team gets stronger: fewer overrides, better questions and clearer standards.
What is the biggest risk?
a useful idea becomes a slogan
How does it help speed?
It reduces guessing. People see the signal, the founder level, the owner and the next action in one place.
How does it help quality?
It keeps founder standards visible at the point where they matter instead of turning them into late corrections.
What should be avoided?
Avoid broad critiques, surprise reversals, oversized artifacts and vague urgency. Each note should carry one decision or one handoff.
How do you know it worked?
It worked if the owner moved, the decision got clearer and the next similar situation needed less founder translation.
What does the founder do next?
Set the owner, name the signal and agree on the next review point.
What should the team keep?
Keep the rule that helped the decision. Delete any ritual that did not change ownership, speed, quality or learning.
Where should this connect?
Connect it to the relevant BuildMode guide and the Starter Kit so the operating rule can be reused.