What is a design-partner pilot?
A design-partner pilot is a bounded collaboration with an early target customer to test whether a product solves a meaningful problem in real use. The customer contributes access, feedback, and an agreed commitment; the startup contributes a defined solution and a learning process. The result should inform a buying decision and the product, not just produce enthusiastic meetings.
The term does not mean the customer is a designer. It describes participation in shaping an early product. It also does not automatically mean free access, unlimited customization, or a promise to build everything the customer requests.
Choose the question before the partner
Write the riskiest assumption in operational terms. “Will people like it?” is too broad. “Can the operations lead complete the weekly handoff with fewer manual reconciliations?” identifies a workflow you can observe and evaluate.
Choose participants whose situation matches the customer you intend to serve. A prestigious company with a completely different workflow may teach you little about the market you are building for. A friendly contact without access to users or buying authority may offer encouragement without enabling a meaningful test.
Ask for a recent example of the problem, the current workaround, who experiences the consequences, and what competing priorities could prevent participation. The answers help distinguish a genuine operating problem from interest in a new tool.
Agree a small, explicit commitment
The customer commitment might include regular access to a named user, agreed test cases, a review meeting, and discussion of a paid next step. Payment can provide useful evidence of willingness to pay, but it does not prove sustained product value. A free pilot can still teach something if you understand which commercial question it leaves unanswered.
Be clear about what is ready and what is experimental. Discuss data use, access, ownership, support, and deletion or export expectations with appropriate reviewers. The checklist below is an operating brief, not a substitute for a contract suited to the work.
Use a one-page pilot charter
| Charter field | What to write |
|---|---|
| Customer and workflow | The people, task, environment, and boundaries |
| Learning question | The uncertainty the pilot should reduce |
| Baseline | How the task works today and what evidence exists |
| Included work | Deliverables, integrations, and supported cases |
| Excluded work | Requests that need a separate decision or scope |
| Participation | User access, feedback cadence, and decision owner |
| Evaluation | Useful outcomes, guardrails, and evidence collection |
| End decision | Paid continuation, one defined extension, or stop |
Add a start date and review date. An extension should answer a remaining question, not simply postpone a difficult conversation.
Label customer-specific work honestly
During the pilot, maintain a request log with the request, the underlying problem, affected users, evidence, effort, and reuse potential. Classify the response as standard product behavior, configuration, a documented manual step, a separate service, or a declined request.
Illustrative example: one customer wants a report with its internal department names. Configurable labels may serve many customers. A bespoke approval process tied to that company's unique hierarchy may require a separate scope. The distinction depends on evidence from the market, not merely on how quickly AI can generate the code.
Track founder and team time. A pilot that looks profitable when only hosting costs are counted may depend on substantial unpriced service work. That is useful information for pricing and product decisions.
Observe behavior, not only feedback meetings
Ask participants to walk through real recent tasks within the agreed data boundaries. Watch where they leave the product, ask another person, or repeat work. Record problems and successful cases, including the context that makes them different.
Positive feedback is useful, but stronger evidence includes repeated use for the intended task, a meaningful improvement the customer can describe, and a credible path to payment. Do not turn a small pilot into a population-wide success claim. Explain who participated, what happened, and what remains unknown.
This focus on direct customer learning is consistent with Y Combinator’s discussion of learning from early customers. The charter and classification method here are our practical recommendations.
Make the end decision explicit
At the review, compare the evidence with the original question. If the outcome is useful and the commercial terms fit, define a paid continuation with clear ownership. If one specific uncertainty remains, agree a bounded extension. If the problem or fit is weak, stop and document the lesson.
A polite ending is a valid outcome. It can prevent months of building for a customer who will never buy the intended product. Avoid calling every continued conversation a successful pilot.
If delivery requires sustained customer-side design or engineering, use the forward deployed hiring guide to decide how to support it. Keep acquisition separate from delivery capacity with the first-ten-customers plan.
Your next useful step
Draft the charter for one potential partner. Highlight every field that is currently an assumption. Use a conversation to resolve those fields before building another feature. Bring the charter back to the customer and ask them to explain the pilot in their own words; mismatches are cheaper to resolve now.
Common questions
How many design partners should we have?
Use the number your team can support while learning from relevant differences. There is no universal target. A small set with real participation can be more informative than a long list of inactive logos.
Should we promise roadmap influence?
You can promise that feedback will be heard and considered. Be precise about who makes product decisions. Influence should not quietly become a guarantee that every request will ship.
Is a signed letter of intent validation?
It is one kind of commitment to interpret in context. It does not replace evidence of use, willingness to pay under real terms, or the startup's ability to deliver economically.
The customer conversation kit
Get the worksheet now, plus the occasional practical next step by email. No spam, unsubscribe any time.
Need a little help applying this? Explore coaching and implementation.