Running the program — the 10-15 hour rule and the weekly cadence.

What the program actually does

The program is the operational layer that converts the agreement into product signal and conversions. The agreement (Chapter 3) names the exchange; the program is the weekly cadence that executes it. Without the cadence, the agreement is a four-page document that sat in a deal folder while the engagement degenerated into ad-hoc Slack threads.

A well-run program produces, per partner, eighteen to forty-eight discrete pieces of structured feedback over a six-month term, 2–3 documented success criteria tracked weekly, a roadmap-input record that distinguishes requests from commitments, and a 50–70% rate of success-criteria attainment by end-of-term. A poorly run program produces unstructured email threads, no documented criteria, scope creep into partner-specific work, and an end-of-term conversation that proceeds as if the prior six months had not occurred.

The weekly check-in cadence

The cadence for the first 90 days is a 30–45 minute weekly synchronous check-in per partner, calendared in advance, with a fixed agenda. After day 90, it drops to biweekly for the remainder of the term. The drop is deliberate — partner engagement is highest in the first quarter, and forcing weekly time after stabilization produces lower-quality conversations from both sides.

The agenda template is the load-bearing component. Four blocks: (a) usage review drawn from product instrumentation, not memory; (b) feedback capture against the structured channels named in the agreement; (c) success-criteria status; (d) roadmap input, framed as solicited and considered, not committed. The first time the template is abandoned for an unstructured "let's just talk" conversation, the program is two meetings from collapsing into the dormant pattern.

The check-in is run by the founder for the first 90 days. Delegating it to a customer-success hire or founding engineer before day 90 is the most common operational error after the absence of the cadence entirely. The partner signed under the implicit premise of founder access.

Structured feedback capture

Every conversation produces a structured note. Every roadmap discussion produces a documented decision. Every commitment produces a tracked deliverable. The three together are the discipline that distinguishes a design partner program from a customer-management hobby.

The structured note is a per-meeting record containing date, attendees, usage summary, feedback items with severity classification, success-criteria status delta, and commitments by either side. Written within 24 hours and circulated to the partner — documenting the founder's understanding for partner correction and producing an artifact the end-of-term conversation can be grounded against.

The documented decision is the artifact produced when a roadmap discussion reaches a conclusion: committed to a specific release, deferred to the post-design-partner backlog, or declined as out of scope. Recorded with a date and rationale, communicated back to the partner. The pattern that produces false signal is the discussion that ends with implicit founder agreement rather than explicit decision — producing an expectation the founder has no intention of honoring, surfaced at end-of-term.

The tracked deliverable is the line item produced when either side commits to an action. Founder commitments — ship feature X, schedule introduction Y — are tracked alongside partner commitments. The list is reviewed at the start of every check-in. Slipped commitments are explicitly addressed, not silently dropped.

Per-partner success criteria

Each partner has 2–3 specific success criteria, named at signing and tracked weekly, that determine whether the engagement is considered successful by end-of-term. The criteria are measurable in partner-verified language — a specific time-savings number, a specific volume threshold, a specific workflow supported end-to-end without manual intervention. "They're happy with the product" and "they see value" are not criteria; they are wishes.

Criteria are committed to by both parties at signing and reviewed weekly. Even when status has not changed, the criterion, current status, and gap are named. The discipline prevents the failure pattern in which criteria are agreed at signing, never revisited, and surfaced only at end-of-term in a meeting where neither party can recall what was agreed.

Empirically, 50–70% of partners hit their criteria by end-of-term in a well-run program. Variance is driven almost entirely by partner engagement — partners who hit weekly check-ins and provide structured feedback hit at the top of the range; partners who drift to monthly check-ins hit at the bottom. The product is approximately constant across the cohort; the engagement is the variable.

The founder time-allocation rule

The founder commits 10–15 hours per partner per month for the first 90 days, declining to 4–6 hours per partner per month thereafter. At a typical program size of five partners, this is 50–75 hours per month in the first quarter and 20–30 hours thereafter. The numbers are a binding constraint, not an aspiration.

The first-quarter figure decomposes approximately as 2 hours of weekly check-in with prep and notes, 4–6 hours of async feedback handling and roadmap deliberation, 2–3 hours of partner-specific walkthrough and onboarding support, and 2–3 hours of cross-partner synthesis. The second-half decomposes as 1 hour of biweekly check-in, 2–3 hours of async, and 1–2 hours of conversion preparation as end-of-term approaches.

The dominant failure mode is first-quarter over-allocation — 25–40 hours per partner per month, driven by inexperience, partner enthusiasm, and the instinct to demonstrate value. At five partners, this is 125–200 hours per month, which precludes the other founder responsibilities (recruitment, fundraise, strategic decisions, the next cohort). The over-allocation is rarely corrected mid-engagement; the founder burns out, partners drop to lower cadence, or the rest of the company runs without the founder for two quarters.

Engineering team allocation

The founding engineer's time on partner-specific work is capped at 20–30% of total engineering capacity. At a two-engineer team, this is 0.4–0.6 engineer-equivalents — meaningful but not dominant. The cap exists because the motion's purpose is to produce signal for the core roadmap, not partner-specific deliverables that do not generalize.

The 20–30% covers feedback-driven fixes the cohort surfaces in common, configuration support within the existing surface, instrumentation that produces the usage data for the check-in, and the small fraction of partner-specific work the agreement permits as in-scope. The remaining 70–80% ships the core roadmap. An engineering team with more than 40% of commits on partner-specific work has degenerated into a custom-development shop, and the motion has structurally failed.

Feedback prioritization framework

Partner feedback is an input to the roadmap, not the roadmap itself. A single partner's feedback represents one signal from one buyer in one segment; the roadmap is the synthesis across all partners, the founder's strategic judgment about positioning, and the architectural constraints only the founder and engineering team see.

Every feedback item is logged with partner source, severity, frequency-of-mention-across-cohort, and roadmap-fit assessment. Items mentioned by three or more partners with high severity become roadmap candidates. Items from one partner are partner-specific signal — useful for understanding that segment, not directly actionable. Items mentioned by multiple partners at low severity are bundled into the periodic polish release.

The pattern to avoid: treating partner #1's feedback as the roadmap during weeks 1–4, partner #2's during weeks 5–8, partner #3's during weeks 9–12. The product whiplashes through contradictory directions, none are shipped, partners observe the inconsistency, roadmap credibility erodes. The cross-cohort synthesis — performed by the founder weekly, not the partners — is what prevents this.

The false-positive partner

A subset of partners exhibits a predictable failure pattern: they tell the founder what the founder wants to hear. They report high satisfaction. They affirm the product is on the right track. They request features in a tone that suggests urgency without producing a verifiable use case. They convert at 0–20% rather than the 50–70% cohort rate. The end-of-term conversation surfaces the discovery that the partner has never seriously evaluated the product against an alternative and has been engaging socially rather than commercially.

The pattern is mitigated by structured-question architecture in the check-in. The questions that surface false-positive engagement: what specifically did you stop doing this week because of the product; what would you switch to if this product disappeared tomorrow; what is the budget line item this would draw against at end-of-term; who else in your organization has used the product this week, by name. Vague answers, observed twice in a single partner, are the signal to either re-engage at the decision-maker level or invoke the founder-termination right.

The partner-relationship-drift pattern

A predictable engagement curve characterizes the motion: high engagement in days 1–30, moderate in 30–60, observable drop in 60–90, recovery at 90–120 if the founder intervenes, sustained moderate engagement to end-of-term. The day-60-to-90 drop is the period in which dormant programs collapse. Initial enthusiasm has worn off, the product has not yet produced its strongest results, the check-in has started to feel like an obligation rather than a value exchange.

At day 60, the founder schedules a re-engagement conversation that surfaces what has been valuable, what has not, and what the partner needs to consider the engagement successful. The conversation is explicit about the drop pattern — we typically see engagement soften around this point; what would make the remaining term most valuable — rather than implicit avoidance. Partners who recover at day 60 convert at 50–70%. Partners whose drop is not addressed convert at 10–30%.

The program-level monthly retrospective

The per-partner cadence is the weekly check-in; the program-level cadence is a monthly retrospective. The retrospective is a 60–90 minute internal meeting — founder, founding engineer, any product or operations hires — that reviews the cohort as a unit. Agenda: cross-partner feedback synthesis, success-criteria status across the cohort, engineering capacity against the 20–30% cap, founder time against the 10–15 hour rule, forward-looking decisions for the next month.

Without the retrospective, the founder runs five separate weekly conversations with no enforced synthesis step, and the roadmap drifts toward the loudest single voice. The retrospective is also where over-allocation is detected — the founder spending 25 hours per partner rather than 10–15 is identified at the first or second retrospective, not at the end of the quarter.

Multi-partner conflict

Partners want different things. Partner A wants the product optimized for their use case. Partner B wants the opposite. Partner C wants a feature that conflicts with both. The conflict is structural and predictable; the operational resolution is disclosure of constraint and alignment of expectations.

When two partners' roadmap requests are in tension, the founder names the tension to both explicitly — another partner has requested X, which is in tension with your request for Y; the criterion for which we ship is which produces broader cohort signal. The naming is uncomfortable in the short term and structurally productive in the long term: partners observe that they are operating in a cohort, not as the single voice driving the product. The avoidance pattern — private implicit commitments to both partners that cannot be simultaneously honored — produces the worst end-of-term outcome, in which both observe broken commitments and neither converts.

Partner-to-partner introductions

Partners benefit from introductions to each other — often operating in similar segments, facing similar problems, and benefiting from peer dialogue the founder cannot substitute for. The introduction is a low-cost concession with high partner value, and well-run programs facilitate it actively.

At the day-60 mark, the founder identifies the two or three pairs with highest mutual relevance and offers introductions explicitly, with partner consent on both sides, framed as peer dialogue rather than referral activity. Partners introduced to peers within the cohort convert at the top of the range, and the post-conversion reference activity (Chapter 6) becomes substantially easier because the partners are already operating as a community.

Common operator failures observed in production

• No weekly cadence. The program runs on ad-hoc Slack threads and monthly catch-ups. Feedback is not captured, criteria are not tracked, the engagement drifts. Observed in roughly half of YC B2B teams in their first cohort.
• No structured feedback capture. Conversations happen, but no notes are written. End-of-term arrives with no record, no documented decisions, no anchor. The partner's recollection becomes the authoritative record by default.
• No per-partner success criteria. The agreement specifies an exchange but not a measurable outcome. End-of-term devolves into a subjective evaluation of partner happiness, biased toward neither conversion nor termination.
• Founder time over-allocation. The founder spends 25–40 hours per partner per month, the company runs without the founder, the next cohort is never recruited. The most consequential time-allocation error in pre-PMF B2B.
• Treating one partner's voice as the roadmap. The founder ships the most recent conversation's requests rather than the cohort synthesis. The product whiplashes, partners observe the inconsistency, roadmap credibility erodes.
• Delegating the check-in before day 90. The founder hands the weekly meeting to a customer-success hire too early. The partner observes the substitution as a relationship downgrade.
• Ignoring the day-60 engagement drop. The founder attributes silence to a busy quarter and does not intervene. The engagement is dormant by day 90.
• Engineering capacity unbounded. The 20–30% cap is treated as a guideline rather than a constraint. Partner-specific work consumes 50%+ of capacity, the core roadmap stalls, the motion has degenerated into custom development.

Pre-program checklist

• Weekly 30–45 minute check-in calendared on day one for the first 90 days, biweekly pre-scheduled thereafter
• Per-meeting agenda template defined: usage review, feedback capture, success-criteria status, roadmap input
• 2–3 measurable, partner-verified success criteria per partner named at signing and circulated in the kickoff document
• Structured-note template defined, with 24-hour write-up commitment and partner-circulation step
• Feedback-tracking system in place with severity and frequency-of-mention fields
• Roadmap-decision artifact format with the three outcomes named (committed, deferred, declined)
• Founder time-allocation budget at 10–15 hours per partner per month for first 90 days, tracked weekly
• Engineering capacity at 20–30% on partner-specific work, tracked in commit history
• Monthly program-level retrospective calendared internally for the duration of the engagement
• Day-60 re-engagement conversation pre-scheduled with each partner
• Structured-question architecture for false-positive detection drafted into the check-in template

Where this fits

The program is the operational system that runs inside the agreement (Chapter 3) and produces the conditions for the conversion moment (Chapter 5). The conversion conversation occurs against the structured-feedback record, the documented success-criteria status, and the cohort synthesis the program has produced.

The function of the program is to remove discretion from the day-to-day operation of the engagement. The cadence is fixed. The agenda is fixed. The feedback capture is structured. The success criteria are tracked. The time-allocation rule is binding. The discipline produces the 50–70% success-criteria attainment and 30–60% paid conversion rates observed in well-run programs. Without it, the cohort exits at end-of-term as neither paid customers nor referenceable logos.