A design partner program is a small, time-boxed group of target customers, usually three to five companies, who agree to use your early B2B product and give you structured feedback while you build it. In return they get influence over what you build, a lot of founder attention, and usually better terms when the product is ready. It is not a beta, not free consulting and not an investor relationship. Run it well and you finish with a product shaped by real buyers, a few people willing to pay, and proof that the problem is worth solving. Run it badly and you end up building custom software for one loud company.
The startup in the worked example below is made up.
What is a design partner, and what is it not?
A design partner is a company that has your problem badly enough to spend real time helping you solve it before the product is finished. They use rough versions, tell you what breaks in their actual workflow, and get a say in the product in return.
The investors at Andreessen Horowitz put the boundary well in their framework for finding a design partner: "Design partners are not cheerleaders or lighthouse customers." Their job is honest critique, not applause or a logo for your homepage.
It helps to be clear about what a design partner is not:
Not a beta tester. Beta users try a mostly built product and report bugs. Design partners help decide what gets built in the first place. Common Paper, which publishes a standard design partner agreement, makes the same point in its guide to working with design partners: design partnerships are different from pilots or betas, and they happen at the very earliest stage.
Not a free customer. If someone wants your product for free and gives nothing back, that is a free user. A design partner gives time, access to their workflow and honest feedback on a schedule.
Not an investor. They are not buying shares and they do not get a vote on company decisions. They influence the product, not the company.
When does a design partner program make sense?
Design partners come after you know the problem is real. If you are still asking whether anyone cares, start with plain conversations. Our sister site has a good walkthrough on validating an idea with five conversations before you build. Design partners are the next step.
A program tends to fit when:
You sell to businesses, and the product has to fit into an existing workflow, tool or data source that you cannot fake from the outside.
The buyer and the daily user are different people, so you need both voices.
You can show something within a few weeks: a clickable prototype, a spreadsheet version, or a manual service behind a simple screen.
It rarely fits a cheap self-serve consumer app, where a few hundred signups teach you more than five companies.
You do not need a finished product to start. The a16z piece notes that what you put in front of partners can be a mock or a prototype and can be manual on the backend, as long as you can show the idea and collect feedback.
Who makes a good design partner?
The a16z framework judges partners on three things: how well they represent the broader market, how urgent their need is, and whether they have the capacity to actually work with you. In practice that turns into a short checklist.
Signs of a good fit
Real, current pain. They have already tried a spreadsheet, a competitor or an internal script.
They look like your target segment. Similar size, similar tools, similar buyer. If they are an outlier, their feedback will pull you somewhere your next 50 customers are not.
Access to whoever owns the budget. You need either the person who signs, or a champion who can get you in front of them before the program ends.
A real user who will give time. Someone who will join a call every two weeks and actually use the thing in between. a16z specifically warns that an excited CEO is not the same as a user, and suggests having both the buyer and the actual user involved.
Who to skip, even if they say yes
One giant logo that would dwarf everyone else. Their security reviews, integrations and politics can eat your roadmap. If you take one, balance them with companies that look like your real market.
Friends being polite. They will tell you it is great and never use it.
People who want custom work. If the first thing they ask is whether you can build a specific report only they would use, that is a services deal.
How many to sign
Three to five is a common starting point for a small founding team, because every partner needs regular founder time. Common Paper says most startups start with five or fewer design partners. a16z recommends starting with five to 10 and warns against signing up more than 20 just because inbound interest is high. If you are two people, start at the small end. Fewer partners you actually serve beats a crowd you ignore.
How do you find design partners and ask them?
Start with people you know have the problem: your best validation calls, former colleagues in the target role, and people who replied to a post describing the pain. a16z says warm connections work best, and that public posts and targeted outreach can also work because anyone who responds to a design partner call likely has a burning need. Common Paper quotes Martin Gontovnikas: "Your design partners should be the customers you actually want, not the first leads you got through product signups or early access forms."
Make the ask specific. Say what you are building, what you need from them, what they get, and when it ends. Here is an example message, adapted to whoever you are writing to:
Subject: Help shape a tool for dock scheduling (8 weeks, 2 calls a month)
Hi Dana, last month you said your team still books carrier slots by phone and a shared spreadsheet, and double bookings cause late trucks every week. We are building a scheduling tool for exactly that and want four design partners for eight weeks: a 30-minute call every two weeks, and your dock lead using an early version on real bookings. You get direct input on what we build, setup done by us, and a discounted price if you keep it afterwards. Open to a 20-minute call next week to see if it fits?
Compared with a typical first draft:
Weak ask | Better ask |
|---|---|
"Would you like to try our new platform?" | Names the specific problem they told you about, in their words. |
"We'd love your feedback sometime." | States the commitment: how many calls, how long, who uses it. |
No end date. | Says eight weeks, so they know it is not forever. |
Free access as the whole pitch. | Influence on the product, hands-on setup and better terms later. |
What goes in a design partner agreement?
Put the relationship on one page and get it signed. Signing tests whether the buy-in is real, and it settles awkward questions early, especially who owns ideas that came from the partner. Common Paper explains why a non-binding letter of intent is not enough for that last point: it does not settle intellectual property ownership, which investors and acquirers may later ask you to prove. Their template also lets either side end the agreement at any time.
This is not legal advice. Use a standard template or have a lawyer review yours. In plain words, the agreement should cover:
Section | What it says in plain words |
|---|---|
Purpose | We are building a product for this problem and you are helping shape it. |
Time commitment | One kickoff, a 30-minute session every two weeks, and real use between sessions by a named person. |
Feedback cadence | How feedback gets shared: the sessions plus a shared log both sides can see. |
Confidentiality | Both sides keep each other's non-public information private. Some teams use a mutual NDA here. |
Feedback and ideas | You can use their suggestions in the product, and the product stays yours. |
Logo and quote | Whether you may name them or quote them publicly, and only with their approval of the wording. |
What they get | Early access, influence on the roadmap, setup help and any agreed future discount. |
Term and ending | Start date, end date, and that either side can stop early. |
After the program | What happens on the end date: a paid plan at the agreed terms, or a clean handover of their data. |
Free, paid pilot or future discount?
Keep it simple and decide before the first call. The usual options are free during the program, a small paid pilot, or free now with a written discounted price after launch. a16z argues that early on, feedback matters more than contract size, while Common Paper suggests agreeing early on what future pricing looks like and when the partner becomes a regular customer. Either way, write the after-program price into the agreement. If you want a deeper look at paid pilots, Aura++ covers them in getting your first 10 paying customers without a launch day.
How do you run the program week to week?
The program lives or dies on rhythm. A cadence that suits a small team:
Kickoff (60 minutes). Watch their current workflow on screen and agree one or two outcomes that would make the product worth paying for.
A session every two weeks (30 minutes). a16z gives biweekly check-ins as an example cadence. Show what changed, watch them use it, ask what got in the way.
A shared feedback log. One sheet both sides can see. Every request gets a line, a status and a reason.
Show work early. A screen they hate in week two is cheap. In week ten it is not.
Apply the "would three of you need this?" rule. Before building a request, check whether at least three partners, or three companies in your target market, would use it. If only one would, log it as "not now" and say why.
A simple feedback log looks like this:
Date | Partner | Request or problem, in their words | How many partners hit it | Status | Reason given to partner |
|---|---|---|---|---|---|
Week 2 | Partner A | "Carriers can't see open slots without calling us." | 4 of 4 | Building | Everyone has it. Shipping a carrier booking link next. |
Week 3 | Partner B | "Need it to sync with our in-house system." | 1 of 4 | Not now | Only one partner uses that system. CSV export instead. |
Week 4 | Partner C | "Dock lead keeps forgetting to mark trucks as arrived." | 3 of 4 | Testing | Trying a one-tap arrival button on mobile. |
When the program ends, that log becomes the honest starting point for your roadmap. EarlyHunt has a separate guide on turning early feedback into a public roadmap people trust.
How do you know the design partner program is working?
Ignore what partners say about it. Watch what they do:
They use it every week without being reminded. If the only usage happens just before your session, the product is not in their workflow yet.
They complain fast when it breaks. A partner who messages you within an hour of an outage depends on it.
They will pay at the end. Ask directly in the second half: "At the price in our agreement, would you keep it?" A hesitant yes is useful. So is a no.
Quieter signals count too: a second teammate joining, or real data replacing test data.
How do you convert design partners into paying customers, or end it well?
Start the conversion conversation two to three weeks before the end date. Show where the kickoff outcomes landed, then offer the terms already in the agreement, honoured exactly.
Some partners will not convert, and that is fine. a16z says it is perfectly fine to wrap up a design partnership without a signed sales contract. Thank them, export their data, and ask what would have made them stay. A partner who leaves on good terms may come back later or send someone who will.
If none will pay, the problem is not painful enough, the segment is wrong, or the product is not there yet. Your feedback log should tell you which.
A worked example: a made-up dock scheduling startup
Everything in this section is invented to show the process. Thandiwe and Soren are building Dockbell, a made-up dock appointment tool for small regional warehouses that still schedule carrier pickups by phone and spreadsheet.
Recruiting the partners
From 14 validation calls, they shortlisted six warehouses with the same double-booking pain. They dropped one whose dock lead could not commit to sessions, and a national logistics brand that wanted a custom integration before starting. That left four companies of similar size, each with a named dock lead as the daily user and an operations manager as the budget owner. All four signed a one-page agreement: eight weeks, a session every two weeks, logo use only with approval, free during the program, and an agreed discount for the first year if they stayed.
What happened over eight weeks
The first prototype was a booking page Soren updated by hand each morning. In week two, all four partners said the real problem was carriers calling about open slots, so the team built a carrier booking link and shelved its planned analytics dashboard. One partner's request for an integration with its own system went into the log as "not now", with a CSV export instead. By week six, three partners were using Dockbell daily. One had stopped logging in, and the exit call showed their volume was too low to feel the pain. At the end, three converted at the agreed price and the fourth agreed to talk again in six months.
Which design partner traps should you avoid?
One partner dominating. The loudest or biggest partner sets the roadmap and the product only fits them. Use the three-partner rule and keep the log visible.
Building custom consulting. a16z describes a trap that catches technical founders in particular: the partner values the founder's expertise more than the product and pays to keep that expertise. Useful for learning early, but it does not scale and hides what the product is missing.
Friends being polite. Kind feedback that never turns into usage. Pick partners who would tell a stranger the truth.
No end date. The program drifts into free support and nobody has the pricing conversation.
No exec sponsor. The user loves it but nobody with budget has seen it. Get the budget owner into the kickoff and final review.
A 30-day plan to start a design partner program
Days | What to do | Done when |
|---|---|---|
1 to 3 | Write down the problem, target segment and the two outcomes a partner should see. | One page you could read aloud to a prospect. |
4 to 7 | Shortlist eight to ten companies from past interviews and your network that fit the checklist. | A list with a named user and budget owner for each. |
8 to 10 | Draft the one-page agreement from a standard template and decide the commercial terms. | Agreement ready to send, after-program price written in. |
11 to 17 | Send specific asks and run 20-minute fit calls. | Three to five signed partners. |
18 to 21 | Set up the shared feedback log and book the biweekly sessions for the full term. | Every session on both calendars. |
22 to 26 | Run kickoffs and watch each partner's current workflow on screen. | Agreed outcomes recorded for each partner. |
27 to 30 | Put the first rough version in front of every partner and log every reaction. | First log entries with status and reasons. |
Design partner FAQ
Should design partners pay?
Not necessarily during the program, but agree the after-program price in writing from the start. A small paid pilot is a stronger signal if your buyer can approve it quickly.
How is a design partner different from a beta tester?
A beta tester reports bugs in a mostly finished product. A design partner helps decide what the product should be and commits to regular sessions over a fixed period.
How many design partners do I need?
Three to five suits most small teams. Sign only as many as you can meet every two weeks.
What if a design partner wants a feature nobody else needs?
Log it, ask what problem it solves, and check whether two others share it. If not, say "not now" with a reason and a workaround. If that is a dealbreaker, they may be the wrong partner.
When your product is ready for early users who like trying new things, you can launch it on EarlyHunt.