TL;DR
A design partner is an early customer who agrees to use an unfinished product and shape it with you, in exchange for influence over what gets built and usually a discount on what it will cost later.
They are how a B2B startup gets from “we built a thing” to “people use the thing” without pretending the thing is finished. Three to five of them, chosen carefully, are worth more than a hundred sign-ups.
The agreement is short and mostly about expectations, not law. Whether to charge them is a real decision with a right answer for your stage. And the program is only working if you can point to metrics that say so, which most founders cannot.
Where design partners sit in the journey
A proof of concept tells you it can be built. A prototype tells you someone would use it. Neither tells you what a real company will do with it on a Tuesday afternoon when the person who championed it is on holiday.
Design partners do. They are the first people to run your unfinished product inside their actual work, and the product that comes out the other side is shaped by that rather than by what you imagined in a planning session.
We covered the stages either side in PoC vs pilot and the broader question of validating a B2B MVP. This post is the step in between.
What a design partner actually is
The phrase gets used for everything from a friendly logo on a slide to a paying customer with a contract. Here is the version that means something.
The definition that holds up
A design partner is a customer who agrees to three things: to use the product in their real work while it is unfinished, to give you structured feedback on a regular cadence, and to let you make decisions based on that feedback that may not go their way.
In return they get influence over the roadmap, early access to whatever you build, and usually a discount or free period once the product is real.
What a design partner is not
Not a beta tester. Beta testers hunt bugs in something you have already decided to ship. Design partners help you decide what to ship.
Not a friendly advisor. Advisors give opinions. Design partners give behaviour: they either use the thing or they do not, and that is the data.
Not a customer yet. If they are already paying full price for a finished product, they are a customer, and the relationship is different. The whole value of a design partner is that the product is not finished.
| Design partner | Beta tester | Pilot customer | |
|---|---|---|---|
| When | Product unfinished | Product decided, being polished | Product finished, unproven in ops |
| How many | 3 to 5 | Dozens to hundreds | 1 to 3 |
| Their job | Shape what gets built | Find what is broken | Prove it works at scale |
| What they get | Roadmap influence, discount | Early access | A working system |
| Cadence | Fortnightly call | Bug reports | Weekly ops review |
| Ends with | Conversion offer, reference | Launch | Rollout decision |
How many you need
Three to five. Fewer than three and one loud voice becomes your roadmap. More than five and you cannot give each one the attention that makes the arrangement work.
Founders who recruit twenty design partners have recruited twenty beta testers and called them something else.
Design partner program benefits
Why bother, when you could just launch and see who signs up?
You build for a real use case instead of an imagined one
Every founder has a picture of how the product will be used. Every one of those pictures is wrong in ways that only show up when somebody with a real job tries to do it. Design partners surface those gaps in week two instead of month six.
You get evidence, not opinions
“I would definitely use this” is worth nothing. A design partner who logs in three times a week without being reminded is worth a great deal. That is the difference between the signal you get from user feedback on an MVP and the signal you get from watching someone depend on it.
You have a story for investors
Three named companies using an unfinished product is a stronger slide than a thousand sign-ups from a landing page. It says the problem is real enough that people will tolerate rough edges to solve it. We wrote about how investors evaluate an MVP; design partners are the part of that evaluation founders most often cannot answer.
You get your first references
When the product is real, the design partners are the people who can say they used it and it worked. Every enterprise sale you make for the next two years starts with someone asking who else is using this.
You find out early if nobody cares
The most valuable outcome of a design partner program is sometimes discovering that people who said they wanted the product will not actually use it when it exists. Learning that with three companies costs a quarter. Learning it after launch costs the company.
How to find design partners
The a16z framework for this is widely cited and mostly right: look for companies that have the problem acutely, have someone internally who owns it, and are small enough to move quickly. Here is the practical version.
Start with the people who already told you about the problem
If you did any customer discovery before building, you have a list. The people who described the problem most vividly, who had a workaround, who asked when it would be ready: they are the first calls.
If you did not do discovery, that is the first gap. Our idea validation engagement exists to produce exactly this list.
Look for the internal champion, not the company
A design partnership is not with a company. It is with one person inside the company who has the problem, has the authority to try a solution, and has enough standing to survive being wrong.
Without that person the partnership dies the first time something breaks. With them it survives three months of rough product.
Prefer companies that look like your future customers
The obvious trap is design partners who are easy to get: friends, other startups, a company where you used to work. Easy to recruit and wrong for the product, because they do not resemble the customer you will need to sell to later.
Pick painful and representative over convenient.
Size matters, in both directions
Too small and they do not have the problem at the scale that makes it worth solving. Too large and the procurement process outlasts your runway. The sweet spot for most B2B products is a company big enough to feel the pain and small enough that one person can say yes.
The ask
Short, specific, honest. The product is unfinished. You want them to use it for real. You want thirty minutes every two weeks. In exchange they shape it and get it cheap or free when it is done.
Founders who dress this up as a finished product offer get a different kind of customer and a worse partnership.
The design partner agreement
This is where founders either overthink it into a forty page contract or underthink it into a handshake. Neither works.
What the agreement is for
Expectations, not enforcement. Nobody is going to sue a design partner. The document exists so both sides know what they said yes to, and so that six weeks in, when the champion’s manager asks what this is, there is a page to show them.
What goes in it
- What each side does. They use the product for real and give feedback on a cadence. You build, listen, and share the roadmap.
- How long. A fixed term, usually three to six months, with a defined end. Open-ended partnerships drift.
- What they get. The discount, the free period, the early access, spelled out. “Preferential pricing” is not spelled out.
- What you can do with their feedback. You need to be able to act on it without asking permission each time.
- Confidentiality, both directions. You are showing them unfinished work. They are showing you their operation.
- Data. Whose it is, where it lives, what happens to it at the end.
- Logo and reference rights. Whether you can name them, and when.
- How it ends. Either side, notice period, what happens to their access.
The standard that exists
Common Paper publishes an open design partner agreement that most early-stage B2B companies can use with minor changes. It is free, it is what a lot of investors expect to see, and it saves you paying a lawyer to reinvent it.
Use it as the starting point. Adjust the commercial terms. Do not add twenty pages of protection for a relationship that runs on goodwill.
Where the LOI fits
A letter of intent is a different document with a different job. It says a company intends to buy when the product exists. A design partner agreement says a company will help you build it.
Some design partnerships produce an LOI at the end, which is useful for fundraising. Whether that counts as revenue is a question we answered in pre-sales MVP. For the partnership itself, the LOI is an outcome, not the starting document.
Paid design partner program or free?
The most argued question in this space, and the answer depends on one thing.
The case for free
Easier to recruit. A bigger pool to choose from. No procurement, no invoice, no finance department asking what this is.
It is the right call when you genuinely do not know yet whether the problem is real, and you need volume of conversation more than depth of commitment.
The case for paid
A partner who pays, even a heavily discounted amount, has told you the problem is worth money to them. That is the single most important thing an early-stage founder can learn, and a free program cannot teach it.
Paid partners also behave differently. They show up to the fortnightly call. They report the bug instead of quietly stopping. They convert to full price at a rate free partners never approach, because they were already paying.
The rule
Charge when the thing you need to learn is whether people will pay. Run it free when the thing you need to learn is whether the problem exists.
For most B2B startups past a working prototype, that means charge. A nominal amount, a heavy discount, a fee that converts to credit against the real price, any of those. The number matters less than the fact of it.
What “paid” looks like in practice
Common structures for an early-stage program:
- A flat monthly fee at 20 to 50 percent of intended pricing, locked for a year after launch
- A one-time setup fee with the product free for the partnership term
- Free for the term, then a discount that only applies if they convert within thirty days of launch
- A fee that accrues as credit against the first year of a full contract
The last one is the cleanest. They pay, the money is real, and it comes back to them as a discount if the partnership works out.
Design partner program success metrics
This is where most programs fail quietly. The partners are recruited, the calls happen, everyone feels good, and nobody can say whether it is working.
For an early-stage B2B SaaS company the success metrics below are the difference between a program that produces evidence and one that produces goodwill. Here is how to know.
Unprompted usage
Are they logging in without being nudged? Two or more sessions a week per partner is the floor for a product meant to be used regularly. Below that, they are being polite.
This is the single most honest metric, because it cannot be faked in a fortnightly call.
Feedback velocity
How many specific, actionable pieces of feedback per partner per fortnight? Three or more means they are actually using it and hitting real edges. Zero means they stopped and did not tell you.
Vague feedback (“it’s great, maybe make it faster”) counts as zero.
Workflow depth
Has the partner moved a real process into the product, or are they running it alongside their old tool and comparing? Moving a workflow in is the strongest single signal in the whole program, because it means they would notice if the product disappeared.
One real workflow per partner. It does not need to be the biggest one.
Conversion intent
Have they said, in writing, that they intend to buy at full price when it launches? Half your partners by the end of the term is a healthy number. Fewer than that and either the product or the partner selection is wrong.
This is where the LOI comes in, if you want one.
Reference willingness
Will they take a call from a prospect? This is the outcome the whole program exists to produce, and it is binary. Ask directly, near the end of the term.
The threshold
Three of the five, on most of your partners, means the program is working. Those are the success metrics an early-stage startup can actually collect without a data team, which is why they are the ones that matter. Hitting none of them, or being unable to measure them, means you have a set of friendly conversations and no evidence.
Design partner program implementation: how to actually run it
Before you recruit
Have a working product. Not a finished one, a working one. If a partner cannot do at least one real thing with it in the first session, they are not a design partner, they are a discovery interview. The rapid MVP path exists to get founders to that bar quickly.
Decide the term, the cadence, the price, and the metrics before the first call. Changing these mid-program feels like moving the goalposts, because it is.
The cadence
Thirty minutes every two weeks per partner, on the calendar, non-negotiable. Plus a shared channel for the in-between.
Weekly is too often for the partner and burns your time. Monthly is too rare to catch problems while they are cheap.
Onboarding
Do it live, with them, in their environment. Watch them set up. Everything they get stuck on in the first hour is a product finding, and it is the highest-density feedback you will get in the whole term.
Running the feedback loop
Every call: what did you use it for, what worked, what did not, what did you do instead. Log every specific item. Tell them on the next call what you did with what they said, including when the answer was nothing and why.
Partners who see their feedback turn into product stay engaged. Partners who feel ignored go quiet and then leave.
Saying no
The failure mode of design partner programs is building three different products for three different partners. Their feedback shapes the roadmap. It does not own it.
When two partners want opposite things, that is a finding about your market, not a feature request. Decide, tell both, and hold. The MVP validation discipline applies: you are testing a hypothesis, not taking orders.
The end of the term
A conversation, not a cliff. Show what was built because of them. Make the conversion offer. Ask for the reference. Ask what would have made it better.
Then either convert them or thank them. Do not let a design partnership drift into an indefinite free account.
Where this fits with pilots and pre-sales
Three related things that get confused.
A design partner helps you finish the product. A pilot proves a finished product works in one customer’s real operation. A pre-sale is money for a product that does not exist yet.
They can chain: design partner becomes pilot becomes paying customer. They can also each stand alone. What they cannot do is substitute for each other. A pilot with an unfinished product is a design partnership with worse expectations, and a pre-sale without a design partner is money from someone who has never used the thing.
We laid out the pilot side in MVP vs pilot and the money side in pre-sales MVP.
Three real situations
The SaaS tool that charged from day one
A workflow product for accounting firms. Four design partners, each paying a flat fee at a third of intended pricing, locked for a year after launch.
Two dropped out in the first month. Both, it turned out, had signed up because the champion was enthusiastic and nobody else in the firm was. The two that stayed moved their real month-end process into the product by week six, generated most of the roadmap, and converted at full price. One of them took reference calls for the next two years.
Charging cost the founders half their partners and gave them the only two that mattered.
The marketplace that ran it free and learned nothing
A B2B marketplace, eleven design partners, all free, all enthusiastic on the calls. Usage was near zero by week four. Feedback was warm and vague. At the end of the term, one converted.
The free program had recruited people who liked the founder, not people who had the problem. The metrics would have shown that in week three if anyone had been measuring them.
The product that found its market by being told no
An analytics tool built for marketing teams. Three design partners, all marketing. All three said the same thing in different words: interesting, but not urgent.
One of them mentioned their finance team kept asking for the same numbers. The founders asked to meet that finance team. Six weeks later the product had a different buyer, a different price, and a design partner who logged in every morning.
That is what the program is for. The no was the finding.
The mistakes that cost the most
Recruiting for convenience. Friends and other startups are easy to get and wrong for the product.
Twenty partners. You have twenty beta testers and no relationship with any of them.
No metrics. Six months of friendly calls and no evidence. This is the most common failure and the quietest.
Letting the program run the roadmap. Three partners, three products, none finished.
Free when you needed to learn about money. The one question you most needed answered, designed out of the program.
Forty pages of contract. For a relationship that runs on goodwill, over a product that is not finished, with a partner who could stop tomorrow. Use the open standard and move on.
Conclusion
Design partners are the step between having something that works and having something people pay for. Three to five customers who use the unfinished product in their real work, on a cadence, under a short agreement that sets expectations rather than enforcing them.
Charge them if what you need to learn is whether people will pay. Measure usage, feedback, workflow depth, conversion intent and reference willingness, and be honest about what the numbers say. The program that tells you nobody cares has done its job as well as the one that hands you your first three logos.
If you have a prototype and are working out how to get it into real hands, that is a conversation we have most weeks as an MVP development company whose clients are usually at exactly this step. Start it here.
What the advice on design partner programs actually specifies
This is the most-asked question about design partner programs and the one with the least evidence behind it. So on 23 September 2026 we read the articles ranking for “design partner program success metrics” and counted what each one actually commits to: how many partners to recruit, how long the program should run, and what share of partners should end up paying.
Across 10 articles advising founders how to run a design partner program, MVP Development found 3 state how many partners to recruit and 4 state a program length. Read 23 September 2026.
The three that give a number do not agree, and it matters who says what. Glow says 3 to 7 partners. a16z says 5 to 10. Bessemer says 5 to 12. Bessemer’s is the most useful of the three because it says where the number comes from — in May 2026 Bessemer Venture Partners wrote that most practitioners recommend between five and 12. All three overlap between five and seven, so if you want the number nobody argues with, that is it.
The four that give a length disagree more: six weeks, 60 to 90 days, three months, and “one, three, or six months”. That is an eightfold spread on the single decision that determines whether the program ends.
Nobody tells you what counts as success
Of 10 articles on design partner program success metrics, MVP Development found 0 state what share of partners should convert to paid. Read 23 September 2026.
Not one. The query that brings people to this page is asking for a success threshold, and the pages answering it name metrics without ever saying what a passing score looks like. You are told to track conversion and not told what good conversion is.
Two articles in the ten carry a conversion figure of any kind, and both are worth having for different reasons. Bessemer reports that Strella ran its program to a hard deadline — go paid or don’t — and all 12 partners converted, reaching $1.6M ARR in its first year of monetisation. That is one company, not a benchmark, and Bessemer does not present it as one.
The other is a ratio rather than a rate: Heavybit’s research, cited by Glow, finds that time-boxed pilots convert to paying customers at three times the rate of open-ended ones. It tells you the time box matters without telling you what either rate is.
What they do agree on
Counting which metrics each article names, across the same 10: a case study or reference customer appears in 6, a weekly feedback loop in 4, willingness to pay in 4, and retention or NDR in 4. Conversion to paid is named in 2, and a signed letter of intent in 2.
Which is the odd part. The outcome the whole exercise exists to produce — a partner who pays — is named by fewer articles than the case study you get to write afterwards.
How we counted, and what we threw out
Eleven articles were attempted and 10 read; Horizon Capital returned 403 and is counted as unreachable rather than dropped. Channel and reseller partner program articles were excluded by name, because a channel partner is not a design partner and including them would have measured a different industry.
Two extractions were wrong and reading caught both. One article’s “12 months” turned out to be a discounted monthly fee offered as an incentive, not a program length, and was removed. Bessemer’s “12 design partners” was the Strella case study rather than its recommendation, which is five to 12, and was corrected rather than dropped.
One limit worth stating: 10 is a small sample, and it is small because the field is small. There is no benchmark report for design partner programs the way there is for trial conversion, which is the reason this section exists.
The data, and how to cite it
The full dataset is published as JSON, with every figure, the sentence it came from, and the reason for each correction: design-partner-metrics-2026-09-23.json.
To cite this study: MVP Development, “What the advice on design partner programs actually specifies”, 23 September 2026, https://mvpdevelopment.company/blog/design-partners.
What to change in a design partner agreement before you sign
Most founders start from a template, and the two everyone starts from are Common Paper’s standard and the framework a16z published. Both are good. Neither knows anything about your situation, and the gaps below are where the template stops and the negotiation starts.
Across 10 articles giving design partner advice, MVP Development found 3 state how many partners to recruit and 4 state how long the programme should run. Read 23 September 2026.
The end date. This is the clause that decides whether the programme works. Of the four sources that give a length, tracsio says six weeks, Glow says 60 to 90 days, PartnerStack says three months. Glow is blunt about why it matters: open-ended pilots drag on forever. Put a date in the agreement, not a phase.
What happens on that date. Only one source in the sample states a conversion target at all, and it is a single case rather than a benchmark: Bessemer describes Strella ending its programme with a hard deadline, go paid or do not, and all 12 partners converting. One company is not a benchmark. It is a good clause.
What you owe them, in writing. The obligation runs both ways and the template usually only covers yours. Weekly feedback was the most named commitment in the sample, appearing in 4 of the 10, alongside willingness to pay in 4 and a case study or reference in 6. If you want the logo at the end, ask for it at the start.
Price, even when it is zero. Free is a decision, not a default. A partner paying nothing has nothing at stake, and the strongest signal in the sample is the one that costs them something: willingness to pay appeared as a named metric in 4 of the 10 articles.
Who owns what you build for them. The template will assign the work product somewhere. Read that clause before anything else if the thing you are building is the product rather than a customisation of it.
The full dataset, with the verbatim quote behind every figure, is at design-partner-metrics-2026-09-23.json.
Frequently Asked Questions
What is a design partner in a startup?
An early customer who agrees to use an unfinished product in their real work, give structured feedback on a regular cadence, and accept that decisions may not go their way, in exchange for influence over the roadmap and usually a discount once the product launches. Three to five is the right number for an early-stage B2B startup.
What is the difference between a design partner and a beta tester?
Beta testers find bugs in a product you have already decided to ship. Design partners help you decide what to ship. A design partnership happens earlier, involves fewer people, and shapes the product rather than polishing it.
Should design partners pay?
Charge them if the thing you need to learn is whether people will pay to solve the problem. Run it free if the thing you need to learn is whether the problem exists at all. For most B2B startups past a working prototype, that means charge something, usually a heavy discount that locks in for a period after launch.
What should a design partner agreement include?
What each side does, a fixed term of three to six months, what the partner gets, your right to act on their feedback, confidentiality in both directions, data ownership, logo and reference rights, and how either side can end it. Common Paper publishes an open standard that covers all of this and is a better starting point than drafting from scratch.
How do you measure whether a design partner program is working?
Five signals: unprompted usage of at least two sessions a week, three or more specific feedback items per fortnight, at least one real workflow moved into the product, half of partners stating in writing they intend to buy, and willingness to take a reference call. Three of five on most partners means it is working.
How many design partners does an early-stage startup need?
Three to five. Fewer than three and one voice dominates the roadmap. More than five and you cannot give each one the attention the arrangement depends on. Founders who recruit twenty have recruited beta testers.
How long should a design partnership last?
Three to six months, with a defined end date in the agreement. Open-ended partnerships drift into indefinite free accounts. The end of the term is when you make the conversion offer and ask for the reference.
When should you walk away from a design partner?
When the end date arrives and they will not convert, and when the weekly feedback stops. Across 10 articles giving design partner advice, MVP Development found weekly feedback loops were the most commonly named commitment, in 4 of the 10. A partner who stops showing up has already given you the answer.
Is a design partner the same as a pilot customer?
No. A design partner helps you finish the product. A pilot customer proves a finished product works in their real operation at limited scale. A design partnership often leads to a pilot, but running a pilot with an unfinished product is a design partnership with the wrong expectations.
Does a design partner need to sign a letter of intent?
Not to start. An LOI says a company intends to buy when the product exists; a design partner agreement says they will help build it. Some partnerships produce an LOI at the end, which is useful for fundraising, but it is an outcome of the relationship rather than the document that begins it.
What do design partners get in return?
Influence over what gets built, early access to everything, and usually a discount or free period once the product is real. The best programs also give partners visible evidence that their feedback turned into product, which is what keeps them engaged for the full term.
