Design-Partner Pitch

Know What the Partnership Must Discover

A design partner is useful when interviews are no longer enough, but the product is not yet stable enough for a conventional pilot. You have a credible thesis about a narrow workflow and need sustained access to real work to resolve a specific uncertainty: which inputs vary, where judgment enters, what makes an output trustworthy, or what prevents repeated use.

That makes the arrangement different from its neighbors. A beta user tries a product slice that already exists. A pilot evaluates a defined outcome under agreed terms. A design partner helps the product become fit for a workflow through repeated use of successive versions. If you cannot name the uncertainty the relationship will resolve, invite a beta user or propose a pilot instead.

Before making the pitch, write one sentence:

We need to learn [product uncertainty] by observing [named user] perform [specific workflow] across [real cases or natural cycles].

The sentence protects both sides. It keeps the founder from collecting an impressive logo with no learning access, and it keeps the customer from entering a vague co-creation exercise with no plausible route to value.

Define the Exchange Before the Call

Choose a workflow slice narrow enough for one founder to support. Know what working result the partner should receive, which people and artifacts you need access to, how often you need to observe use, and what you can change during the partner period. Set a start, a review point, and an end.

Also decide what the relationship does not grant. Partner input is evidence, not control of the roadmap. The founder should not promise exclusivity, every requested feature, production maturity, or unlimited support. The partner should not be expected to reveal unrestricted data, lend its name, or donate open-ended staff time. Any reference, case study, or use of anonymized learning needs separate, explicit permission.

Commercial terms should match the exchange. A partner who receives useful work and intensive founder attention may pay. A short collaboration may instead trade a limited concession for unusually valuable access. Either choice should be visible and time-bounded; “design partner” must not become a way to postpone the pricing conversation indefinitely.

Make the Pitch

Lead with the workflow you understand and the uncertainty that remains. This gives the prospect something concrete to correct before either side discusses status, access, or influence.

You showed me how [named user] currently handles [specific workflow], especially
[consequential friction or exception]. I am building a narrow product around
[workflow slice and value outcome].

One important question is still unresolved: [product uncertainty]. I cannot
answer it responsibly from demos or occasional feedback. I need to see how the
workflow behaves across [cases/cycles], including where the product is wrong or
incomplete.

I would like to propose a [duration] design partnership.

During that period, I would provide:
- [usable capability or founder-assisted result]
- [iteration cadence] focused on the agreed workflow
- support through [channel and response boundary]
- [price, credit, or other commercial term]

I would ask your team to provide:
- a named user and a buyer or decision owner
- [representative artifacts, cases, or controlled access]
- real use during [natural events or cadence]
- a [length] review every [cadence], including failed or abandoned cases

The partnership would cover [included workflow]. It would not include
[custom work, adjacent workflow, integration, or support exclusion]. Your team
would retain [human review, approval, or fallback], and we would work within
[data, confidentiality, and security boundary].

At [date or milestone], we would decide whether to move to a pilot or normal
customer agreement, revise the scope once, or stop. Your feedback would shape
my decisions, but it would not reserve features or transfer roadmap control.

If that exchange seems useful, the next step is a working session with [named
user] and [decision owner] using [one representative case]. After that I can
send a short written proposal with the scope and terms.

The pitch asks for a representative case before asking for a ceremonial yes. That case tests whether the customer can provide the access the partnership depends on and whether the founder understands the workflow well enough to begin.

See the Exchange in a Real Proposal

Suppose a founder is building an evidence-request tracker for small software vendors preparing for customer security reviews. Discovery has established the recurring pain: evidence lives across inboxes, shared drives, and several internal owners. The unresolved question is whether requests vary enough across customers that a fixed evidence library will fail.

The founder could say:

You showed me how your operations lead reconstructs evidence for each customer
security review, even when the underlying policy or report has already been
approved. I am building a narrow tracker that connects an incoming request to
existing evidence, its owner, and its approval state.

I still do not know which request differences require a genuinely new response
and which can be handled by a reusable evidence record. I would like to learn
that across your next three customer reviews rather than encode the wrong model
from a single questionnaire.

For a six-week design partnership, I would set up the tracker for one operations
lead, import an agreed set of non-sensitive evidence records, and revise the
matching and approval flow once a week. I would provide weekday email support
and a fixed founder-plan price for the period.

I would need the operations lead to use the tracker for the three reviews, mark
incorrect matches, and meet with me for 25 minutes each Friday. We would review
redacted request wording; credentials, customer-confidential attachments, and
final approval decisions would remain in your existing systems and with your
team.

The work would not include writing policies, completing questionnaires for
you, or building customer-specific integrations. At the end of six weeks, we
would decide whether the workflow is stable enough for a paid pilot, needs one
narrower test, or should stop.

If that is worth exploring, let us use one redacted request set with your
operations lead and budget owner next Tuesday. I will turn what we agree into a
short written proposal before any data is shared.

The founder offers a working system and focused iteration, but does not offer compliance consulting. The partner supplies variation, use, and correction, but does not surrender unrestricted information. Most importantly, the six weeks exists to answer a product question whose answer changes what gets built.

Read the Response as Evidence

A promising response names the user, the approaching work, the access that can safely be provided, and the person who can make the continuation decision. Questions about confidentiality, data handling, ownership, support, and price are signs that the prospect is evaluating a real operating relationship. Resolve those points in a written agreement appropriate to the risk before accepting access or beginning work; the pitch itself is not that agreement.

Narrow the proposal when the workflow fits but the access, cadence, or founder workload does not. Decline it when the prospect mainly wants bespoke delivery, exclusivity, a guaranteed roadmap, production assurances the product cannot meet, or meetings without real use. A recognizable customer is still a poor design partner if the work would pull the product away from its intended segment.

The founder can be the mismatch too. If you need the partner to discover the problem for you, have no usable slice to offer, or cannot support the promised cadence, return to discovery. The title of the relationship does not make the product ready for it.

End the Partnership on Purpose

At the review point, return to the uncertainty named at the start. Continue into a pilot or ordinary customer relationship when repeated use has made the workflow and value legible enough to test under stable terms. Run one narrower extension only when a specific remaining question justifies it. Stop when the partner cannot use the product, the segment requires a different product, or the support and customization burden would consume the founder.

A good design partnership does not continue because both sides enjoy collaborating. It ends because the product question was answered and each side can now make a clearer commitment—or a clean exit.