How to Use Design Partners to Prove Early Product Value

You are the only product manager at a small startup, staring at a brand-new product with no standard, no comparable example, and no baseline to measure against. A landing page will not save you here, because you cannot fake real value for complex users with an ad campaign and an intent test. This is the corner design partners are built to get you out of, and how you recruit and run them decides whether a first product finds real value or dies in a jungle of possible features.

I talked with the first and only product manager at an MLOps and data-science-tooling startup, tasked with growing engaged users and closing deals by building a new product from zero. Her market had no standards to lean on and nothing to copy: founders pulled one way, the community another, competitors a third. Her answer was to stop guessing and let a small set of real users co-build the product.

The Lead PM I spoke with grew engaged users by about 20% in a single quarter while building for five design partners, and closed deals off the back of that work.

Why design partners beat a landing page for complex products

When a product is new, complex, and has nothing comparable to copy, you cannot simulate real value with a landing page and an intent test. You need real users co-building the exact flow, which is what design partners are for.

Think about a consumer app: you can put it in a store, run a campaign, and read early intent within a day. A technical product for technical users gives you none of that. Every user wires up their own scripts and runs their own flow, so whether you have built real value for people that complex is almost impossible to learn by shipping to the wind and hoping a launch brings users. Design partners are how you find out whether the value is actually there, one user at a time.

Match the validation method to the product's complexity. Intent tests earn their keep on simple products and mislead you on hard ones.

How do you find the right design partners?

Focus before you reach out. Narrow to a segment that already feels the problem but has not solved it, then go where those users gather and message them directly.

Focus has two axes. The first is the slice of the problem you can serve best: her product spanned several data types, so the team picked the two they could build for fastest and treated it as an educated guess. The second is company stage. Very large companies had already built their own tools and would never pay; very small ones did not yet know what they needed. The sweet spot was mid-size companies that felt the pain, had not built their own tooling, and lacked the capacity to. That is the profile you want: people who have met the problem but not the solution.

Then find where they already gather. These users lived in their own communities, forums, and groups, visible through the tools and languages they used. The team tracked those places and simply sent messages. Her most practical advice was to drop the shame and send the note: "Hi, I'm in product, this is what I'm doing, want to talk?" Many ignored it, which is fine; enough replied when she sent enough.

How do you get busy experts to say yes?

Show up as a product person who is there to learn, not to sell. Then bring a working mockup to the call so they can see and react to the actual flow instead of reacting to an abstract pitch.

The frame does most of the work. A busy expert can smell a sales pitch and will not give up an hour of a packed day for one. The message that lands is honest and small: I am building something new, I do not know what it should look like yet, you know this domain, help me learn how you work so I can shape it. That posture pulls a high response rate. I see the same in my own products: a quick personal reply to anyone who leaves feedback, plus a scheduling link, converts far better than any campaign, because people are surprised anyone read what they wrote.

The mockup is the second unlock. A call that starts as a normal user interview will hand you a pile of feature requests. Arriving with a ready mockup you can demo changes that: the person sees the flow as a flow, cannot tell whether it is built yet, and starts picturing themselves using it, which is what turns an interviewee into a partner. Open with "describe what you see," and their answer tells you whether you are even in the right area.

How do you turn feedback into a real design-partner relationship?

Bring them to wanting to partner before any contract enters the room. Then anchor it: they get the product, you get regular feedback as the agreed payment, written in as a mutual KPI.

The order matters. She never opens with "want to be a design partner?" She shows the mock, they talk, the feedback deepens, and the call runs long, itself an early signal you are on the right track. Only then does she explain why she needs a partner and why this person fits, and only then does she ask. Sales and contracts stay out of the room until the person already wants in.

Once they say yes, name the exchange plainly. They get the product for free, and the payment, in her word, is regular feedback. After an early partner fell through having given no feedback despite heavy investment, the team learned to anchor it in writing, with delivery milestones and a mutual KPI: you need to get value out of this, and so do we. If the partner gets nothing, the product has no value yet, and no engagement or deal will follow. Writing that into the contract keeps both sides honest.

This is exactly the muscle I coach founders and early PMs through in RE.FOCUS mentoring: turning interested users into committed partners who owe you feedback and get real value back.

What does running design partners actually cost?

Running design partners costs real capacity, so cap the number and budget for the trade-offs. Sometimes you fix a partner's bug before your own roadmap, and you keep an ear on the wider market so a handful of voices do not bias you.

Partners are not free feedback. You have to show up, give support, keep engineers on their issues, and invest real time. Her team worked with five and stopped adding once two things were true: they had enough representation of the users they cared about, and the team had hit its capacity ceiling. The sharpest trade-off is support: when a partner hits a bug, engineers go fix it even though the roadmap says otherwise, because the relationship is the priority. Over-communicate, and send the next mock before it is even finished, because a neglected partner is a lost partner.

Guard against the obvious bias, too. Five relevant customers are a strong signal, but they are also just the ones who answered. Two habits keep it honest: understand what each partner needs, not only what they say, and centralize everything so you can cluster five voices into the one flow that unifies them. Keep an ear on what competitors ship and what the communities discuss, so design partners sharpen your judgment without becoming the only thing you hear.

Key takeaways

• A landing page cannot validate a complex, no-baseline product. Use design partners to co-build and prove real value with real users.
• Focus before you reach out. Target a segment that feels the problem but has not solved it, and find them in their own communities.
• Recruit as product, not sales, and bring a mockup. "I am here to learn" plus something real to react to converts busy experts into partners.
• Name the exchange and put it in writing. They get the product, you get regular feedback, anchored as a mutual KPI in a contract.
• Budget the cost and guard against bias. Cap the partner count, prioritize the relationship over the roadmap when a bug hits, and keep listening to the market outside your five.

Design partners will not pick your market, and they are not your only feedback tool. What they give you is a bank of scheduled, high-trust feedback where surveys and cold emails go unanswered, the hardest thing to get when you are proving value from zero. If that is where you are now, book a call through RE.FOCUS mentoring to pressure-test whether design partners fit your stage and how to structure your first one, and browse the RE.FOCUS resources for more on early product validation.