How to use a design partner to validate before you build

A founder I spoke with recently had no backend, no funding, and no developers — but he had something most early-stage founders don't: a domain expert who had spent hours with him explaining exactly how the work breaks down, where the bottlenecks are, what he does manually that takes eight hours and could theoretically be automated. That expert had validated the founder's front-end prototype against his real workflow and pointed out where it got things wrong.

That relationship — a design partnership — was the most valuable thing the founder had built. More valuable than the prototype. More valuable than the investor conversations.

Most founders skip this step or do a weaker version of it.

What a design partner actually is

A design partner is not a beta user. A beta user shows up after you've built something and tells you whether they like it. A design partner shows up before you've built anything and tells you whether you're solving the right problem.

The distinction matters because most of the expensive mistakes in product development happen before a line of code is written. You build the wrong thing. You solve a real problem but for the wrong user. You build the right thing for the right user but in a way that doesn't fit how they actually work. A design partner who knows the domain deeply can surface all of that before it costs you six months of development.

In the case I described, the founder's design partner was Europe's leading expert in his field. He shared his exact workflow — every tool he uses, every platform he logs into manually, every step he performs to trace a transaction, the reports he has to produce, the jurisdictions he has to account for. That operational detail became the product specification. Not a guess at what users might want. An accurate map of what a specific expert actually does.

What you get that you can't get elsewhere

Customer interviews are useful but limited. When you ask someone "what would help you work faster?", they tell you what they can imagine. They don't tell you about the workaround they've been doing for three years that they've stopped noticing. They don't tell you about the report format required by a specific jurisdiction they deal with. They don't tell you that the last tool they tried failed because it couldn't handle a particular edge case that comes up every week.

A design partner who trusts you enough to work through problems with you will show you all of that. Not because you asked the right questions — because the relationship is deep enough that they're thinking out loud rather than answering a survey.

I built FutureAngel with a collaborator by working closely with design partners who knew fund management from the inside. The LP onboarding flows, the KYC/AML requirements, the deal tracking structure — all of it came from those conversations, not from researching what fund management software usually does. What we built matched how they actually worked because we learned how they actually worked before we started.

How to find one and what to offer

You usually don't find a design partner by announcing that you're looking for one. The best ones are already visible in the domain — they speak at the niche conferences, they answer questions in the industry forums, they're the person others in the field cite. You approach them not as a vendor but as someone genuinely trying to understand the problem, leading with curiosity about their work rather than a pitch for yours. Experts give time to people who are interested in what they do; they tune out people selling to them.

The right design partner is someone who has the problem you're solving, has it badly, and is interested enough in the solution to invest time in helping you understand it. They are not a customer — you are not charging them yet. They are not an advisor — you are not paying them equity for their name. They are a collaborator.

What you offer: early access to the product as it's built, genuine input into the decisions (they can see the prototype evolve and push back on what doesn't match reality), and eventually a pricing arrangement that reflects their role in shaping it.

What you ask for: time. Specifically, sessions where they walk you through how they currently do the work — not what they wish they could do, but what they actually do today. Screen recordings of their workflow. Examples of the reports they produce. The tools they have open at the same time. The steps they do in sequence.

That is what becomes your spec. It is worth more than any market research report.

The thing most founders get wrong

They treat the design partner relationship as validation — as evidence the idea is good. "We have a design partner" in a pitch deck usually means "one person said this sounds interesting."

That's not what makes it valuable. What makes it valuable is the operational knowledge transfer. The design partner needs to have shared enough about how the problem actually works that you could describe their workflow in detail, including the parts that don't fit neatly into your product concept.

If your design partner has seen your prototype but you couldn't describe their current workflow in detail — the sequence of steps, the tools involved, where things break, what the output looks like — the relationship hasn't produced what it should yet.

The founder I spoke with had done it properly. He could describe exactly what his design partner does, in what order, using which tools, to produce which outputs. He could name the specific bottleneck — eight hours of manual work to trace a single transaction — and explain why it was slow. That's the level of understanding that leads to a product that actually fits the work.

Getting there before you build is the whole point.