The pitch for a design partner usually goes: we're building something for people like you, want early access and a say in how it turns out. It's an easy pitch to say yes to, which is exactly the problem. Free early access to something that might help costs the other person nothing to agree to, and an agreement that costs nothing tells you nothing. Most design-partner programs fail quietly, not because nobody said yes, but because everybody said yes and none of them meant it the way the founder needed them to.
The question everyone asks is the one that produces nothing useful
"Would you use this?" is the single most common design-partner question and the least reliable one. It's hypothetical, it costs the answerer nothing, and people are broadly agreeable when the cost of agreeing is zero. You'll get a room full of yeses and build against them, and three months in you'll have a product shaped by people who were being polite to someone building something ambitious, not by people with a live, urgent version of the problem you're solving.
The question that actually filters is one with a cost attached. Not "would you use this" but "will you give me ninety minutes this month to walk through how you currently do this, and forty-five more in six weeks to react to what we've built." Some of the enthusiastic yeses evaporate at that question. That's the point. The people left are the ones actually willing to spend something, and spending something is the only signal a design partner can give you before the product exists to prove itself.
What actually qualifies someone as a design partner
Two things, and market size is not one of them. First, they have to have the problem right now, badly enough that they're already spending time or money on a worse version of the fix. A partner who finds the problem mildly interesting in theory will give you mild, theoretical feedback, which is worse than no feedback because it looks like signal. Second, they have to be willing to give you something real: time, access to how they actually work today, or a name you can eventually use in public. If a candidate can't offer any of the three, they're not a design partner. They're a prospect you're talking to early, which is a fine thing to be, but don't build your roadmap around their opinions as if they'd made a commitment they never made.
The trade you should actually be offering
The instinct is to trade free access for feedback, which undervalues both sides of the deal. Free access is worth very little before the product works; feedback from someone half-engaged is worth less. Trade instead for structured time on a schedule you set, candor even when it's unflattering, and permission to use their name and their result once there's a result worth naming. In exchange they get a product shaped partly around their situation, a discount that holds once you start charging everyone else, and, if you're honest about it up front, the chance to influence something before it's set in stone. That last part is real and you should say it plainly instead of treating it as a consolation prize. It's the one advantage a partner gets that no later customer ever will.
Limit the number on purpose
Founders tend to want as many design partners as they can recruit, on the theory that more input de-risks the build. Past four or five, it does the opposite. Each partner has a slightly different version of the problem, and a product trying to satisfy all of them at once ends up satisfying none of them well, which is how you get a first release with eleven half-features instead of one thing that works. Pick a small number who look enough alike that solving for one of them mostly solves for the rest, and let the ones who don't fit go be someone else's early customer later.
Finding them is the same problem as finding any first buyer
The hard part of a design-partner program usually isn't structuring the trade. It's finding five people who actually match the profile above, out of everyone you could plausibly ask. This is the same search problem as finding a first customer, just with a different ask at the end of it, and it's worth treating it that way instead of relying entirely on your existing network, which will hand you the people closest to you rather than the people closest to the problem. Describe, in your own words, who you think has this problem, and Rocketship will find the actual people who match, showing you a first batch of real names at no cost, so you can tell whether the pool you'd be recruiting from holds five good partners or five people who'll be gracious and unavailable.
From there the same system writes the first message from your own inbox, and once someone agrees to the ninety minutes, that conversation, and every one after it, sits in one place instead of scattered across a personal inbox and a notes app you'll lose track of by partner three.
Ending it on time, one way or the other
Design-partner relationships that never end are a common way to avoid finding out whether the product works. Set a date at the start, not after: by this point we'll have shipped what we discussed, and we'll get on a call to decide whether this becomes a paid relationship or we part on good terms. Both outcomes are fine. What isn't fine is a partnership that drifts for a year, because a founder who's afraid to ask "does this convert to paid" has usually also stopped believing it will, and is using the partner as a reason not to find out.
What the whole exercise is actually for
A good design partner isn't a discount customer or an unpaid beta tester. They're the only source you have, before you have any customers, of a real answer to whether the thing you're building solves a problem someone will eventually pay to have solved. That answer is worth a genuine trade, made to a small number of people who have the problem badly enough to give you something back. Everyone else who says a cheerful yes to "would you use this" can wait until there's something real to show them.