How Do You Run a Design Partner Program Before Launch?

How do you run a design partner program before launch?

You pick a small number of companies with a real problem, charge them something meaningful, agree a fixed window, and build with them rather than for them. The programs that fail are the ones where nobody paid, nobody committed a date, and everybody was too polite to say the product was not working.

I get asked about this by founders who have a prototype and a list of friendly contacts. The friendly contacts are usually the problem, and the fix is uncomfortable but simple.

Here is how I would structure the program, and what the best documented version of it actually looked like.

What is a design partner, and what is it not?

A design partner is an early customer who gets influence over what you build in exchange for real commitment. It is not a free trial, it is not a beta list, and it is not a friend agreeing to look at your demo. Those things produce encouragement. A design partner produces requirements.

The distinction matters because the two arrangements feel identical in the first meeting and diverge completely by week three. A beta user drifts away when they get busy. A partner who has signed something and paid something turns up, because their own team is now depending on the outcome.

First Round Review published a detailed account of how Sierra ran its design partner program, and one line in it sets the standard clearly. The agreements looked like paid enterprise sales contracts rather than early stage pilots. That is the bar.

How do you choose who to invite?

Sierra's program used four criteria, and they are worth stealing outright. Horizontal appeal, so the company went to people in healthcare, consumer goods, media, retail and tech without yet knowing which would resonate. Large scale, real problems, and deliberately not too many friendlies.

That last criterion is the one founders resist and the one that matters most. The reasoning quoted in the piece is that the views of strangers are not clouded by your existing relationship. A friend will tell you the product is promising. A stranger who paid will tell you it is slow.

The real problems criterion has a specific phrasing worth keeping. The aim was customers who wanted to solve a real problem that meaningfully impacted their business. Not a problem they found interesting. A problem with a budget line and someone whose year is worse because of it.

Should design partners pay, and how much?

Yes, and the number in that account is more useful than any general advice. The guidance given was that 10 to 20 percent of your total contract value feels right, and that anything less than that is not a real commitment. It is a discount for the risk they are taking, not a giveaway.

The payment is doing a job that has nothing to do with revenue. It creates an internal owner. Somebody at the partner company had to justify the spend, which means somebody now has to show a result, which means your calls get attended and your questions get answered.

If you cannot get anyone to pay anything, you have learned something valuable early rather than expensively. That is a finding, not a failure. It usually means the problem is real but not urgent, which changes your launch plan rather than ending it. I wrote about that scenario in the launch plan for a product nobody is waiting for.

How long should the program run?

Long enough to build and short enough to force decisions. The window suggested in the Sierra account is a good default: under two months is probably too short, and over six months is probably too long. Pick a date, write it in the agreement, and treat it as real.

A fixed end date is what turns a partnership into a decision. Without one, a design partner program quietly becomes a permanent discount, and the conversation about converting to a normal contract never happens because nobody wants to bring it up.

The end date also protects your roadmap. Six months of building for five specific companies is enough to learn what generalises. Twelve months of it is how you end up with a consultancy that thinks it is a product company.

How many partners should you take on?

Fewer than you want, and expect that number to creep. Sierra aimed for four design partners and ended up with six, which is a very normal outcome and a useful warning. Every additional partner is another roadmap with a claim on your week.

The right number depends on how different the partners are from each other. If they are all solving the same shaped problem, three teaches you almost everything. If you are deliberately testing whether the product is horizontal, you need enough variety to see a pattern, which pushes you toward five or six.

What you should not do is take a seventh because they seemed keen. A design partner you cannot give real attention to becomes a reference customer who quietly tells people it did not work.

What do you owe the partner in return?

Access, speed, and honesty about what you will not build. Access means they can reach a founder, not a support queue. Speed means their reported problem gets a response within days. Honesty means you tell them plainly when a request is not going into the product.

The third one is where most programs go wrong. It is tempting to say yes to everything a paying early customer asks for, and six months later you have built five different products badly. Saying no is the thing that keeps the program a product exercise rather than a custom build.

Give them something to show internally too, because your champion inside that company has their own reputation attached to this. A monthly written update they can forward is worth more than a slide deck they cannot.

What if you are not a venture backed software startup?

The structure transfers, with smaller numbers. I run a services practice from Bengaluru, mostly fixed fee projects between one thousand and ten thousand dollars, and I have used the same shape for new service offerings more than once. Two or three clients, a real fee, a defined window, and an explicit agreement that the process is being figured out.

The one thing I would not transfer is the assumption that partners convert. The Sierra account reports that 100 percent of its design partners converted to customers, and that is their reported outcome, not a benchmark you should plan around. Plan for conversion, but price the program as if it might be the only money you see from it.

Getting the pricing of that first paid engagement right is its own problem, and it is the difference between a pilot that becomes a contract and one that becomes a case study nobody paid for. I set out how I approach it in how to price a pilot so it becomes a contract.

How do you know the program is working?

Watch what the partner does, not what they say. Are they using it without being prompted, are they asking for changes rather than offering compliments, and have they told a colleague about it. Those three signals are worth more than any satisfaction score you could collect.

The clearest warning sign is a partner who is still enthusiastic and still not using it. That combination means the problem you are solving is not the problem they wake up with, and no amount of product work fixes it. Better to find out in month two.

Write down what you expect each partner to be doing by the midpoint of the window, and check it on that date. If you do not write it down in advance, you will grade generously, because by then you will be attached to them.

What should you do next?

Make a list of ten companies with the problem you think you solve, and cross off everyone you already have a warm relationship with. What is left is your real prospect list for this, and if the list is now empty, that is the finding to act on this week.

Then write a one page agreement that names the fee, the window, the cadence of contact, and what happens at the end. It does not need a lawyer to draft the first version. It needs to exist so that the awkward conversation happens before the work starts rather than after.

Over six years and more than seventy projects, the engagements that went well almost always had that page and the ones that went badly almost never did. If you are putting a program like this together and want a second opinion on the structure or the pricing, reach out and let's chat. If the product is genuinely still in beta, it is also worth thinking about how the website should say so, which I covered in designing a page for a product still in beta.