Design Partner Programme Builder

design-partner-programme-builder

Agent: VP Product

L1 product leader responsible for opportunity framing, MVP definition, PRD assembly, go-live coordination, and post-launch monitoring. Owns the product strategy and roadmap from idea through GA.

Department ethos: ideal-product.md

Skill Description

Builds the design partner programme to get early customer input during development.

When to Use

• When a new product or major feature initiative is entering development and needs validated demand signals
• When the team lacks confidence in the ICP definition or value proposition and needs real buyer feedback
• When Sales has pipeline waiting on a product that does not yet exist and needs structured early access
• When the product strategy relies on co-development or ecosystem partnerships for differentiation

Workflow

1. Define programme objectives: Clarify what the programme must deliver — validated use cases, reference customers, pricing signal, integration feedback, or case studies. Deliverable: programme objectives document.
2. Set partner selection criteria: Establish the ideal design partner profile: ICP fit, technical readiness, executive sponsorship, willingness to commit time, and strategic value (logo, segment representation, co-marketing potential). Deliverable: partner selection rubric.
3. Recruit design partners: Work with Sales and CS to identify and approach candidates from existing pipeline, churned accounts with unmet needs, or strategic prospects. Pitch the programme value exchange clearly. Deliverable: signed partner agreements (target 3-8 partners).
4. Structure the engagement cadence: Define the interaction model — weekly feedback sessions, async Slack channels, monthly exec check-ins, and milestone demos. Specify time commitments for both sides. Deliverable: engagement calendar and communication plan.
5. Define the feedback framework: Create structured instruments — interview guides, feature-priority ranking exercises, usability test protocols, and NPS/CSAT baselines — so feedback is comparable across partners. Deliverable: feedback toolkit.
6. Establish the value exchange: Codify what partners receive — discounted or free access, influence on the roadmap, early GA access, co-marketing opportunities, SLA commitments — and what they owe in return (time, data, reference willingness). Deliverable: value exchange term sheet.
7. Run the programme: Execute the cadence, capture feedback in a central repository, synthesize themes weekly, and feed prioritized insights back to the product and engineering teams. Deliverable: weekly feedback synthesis reports.
8. Gate the transition to GA: Define the criteria under which design partners convert to paying customers — pricing terms, contract start dates, grandfathering policies, and reference commitments. Deliverable: partner-to-customer transition plan.
9. Capture programme outcomes: Document validated use cases, testimonials, case-study drafts, and lessons learned. Feed pricing signal into the pricing-v1-setter workflow. Deliverable: programme outcomes report.
10. Retrospect and templatize: Run a retrospective on the programme itself — what worked, what partners found valuable, what created friction — and publish a reusable programme template for future products. Deliverable: design partner programme template.

Anti-Patterns

• Logo-chasing: Selecting partners for brand prestige rather than ICP fit and willingness to engage. Why: Prestigious logos that don't invest time produce zero usable feedback and distort prioritization.
• Unbounded scope: Letting partners treat the programme as a custom-development contract where they dictate the roadmap. Why: The product must serve the broader market; over-indexing on one partner's needs creates a bespoke solution disguised as a product.
• Feedback without structure: Collecting anecdotal partner input in ad-hoc conversations with no consistent framework. Why: Unstructured feedback is impossible to compare across partners and biases toward the loudest voice.
• No exit plan: Running the programme indefinitely without a defined transition to paid customer status. Why: Partners who never convert consume support and engineering bandwidth without generating revenue, and Sales cannot forecast.
• One-way extraction: Taking feedback without delivering visible product progress or programme perks. Why: Partners disengage when they feel used; reciprocity sustains engagement through the programme lifecycle.

Output

On success: A programme outcomes report containing validated use cases, synthesized feedback themes, pricing signal, signed reference commitments, case-study drafts, and a partner-to-customer transition plan — plus a reusable programme template for future initiatives. On failure: Report which step stalled (e.g., insufficient partner recruitment, low engagement rates), the feedback collected to date, what alternative validation methods were attempted (surveys, competitor analysis), and a recommendation on whether to extend the programme, pivot the ICP, or proceed to GA with acknowledged risk.

Related Skills

• business-model-sketcher — sibling skill under the same agent — combine with business-model-sketcher for end-to-end coverage
• competitive-response-monitor — sibling skill under the same agent — combine with competitive-response-monitor for end-to-end coverage
• goal-framer — sibling skill under the same agent — combine with goal-framer for end-to-end coverage