A design partner is not an early logo

It is tempting to treat a design partner as a company name that makes a young product look credible. That misses the point.

A good design partner is a person or team with a real, recurring problem and enough motivation to work through it with you. They will show you their current workflow, try a rough version, explain where it fails, and tell you when your assumptions are wrong.

That honesty is more valuable than enthusiasm alone.

Start from the problem, not the title

Look for people who are actively dealing with the problem your product addresses. You are not looking for a generic \u201cinnovative company.\u201d You are looking for someone who has enough pain, frequency, or risk in the workflow that a better approach would matter now.

Useful places to begin include:

  • people you have already interviewed about the problem;
  • peers who use a clear but awkward workaround;
  • operators who own the outcome, not just the tool;
  • small teams able to make a practical change without a long procurement cycle.

The Nielsen Norman Group\u2019s user-interview guidance is relevant here: a productive discovery relationship is grounded in real context and behaviour. The more a partner can show you the actual work, the more useful the collaboration becomes.

Make the offer concrete

\u201cHelp us shape the future\u201d sounds flattering but vague. Be specific about what the partner receives and what you need from them.

For example:

  • access to an early workflow built around their use case;
  • direct communication with the product builder;
  • a limited number of structured feedback sessions;
  • a say in the order of problems being solved;
  • clear boundaries about what will and will not be custom-built.

In return, ask for a reasonable commitment: an honest walkthrough, timely feedback after real use, and permission to learn from the workflow. Do not promise a roadmap that one partner can control.

Choose people who can give evidence

The best early partners do not need to be sophisticated product thinkers. They do need to be able to show what happened.

Look for someone who can answer questions like:

  • What did you do before using this?
  • Which part saved time or reduced mistakes?
  • Where did you stop trusting the result?
  • What did you do instead when the product could not help?

Those answers turn feedback into product decisions. A general statement like \u201cI like it\u201d cannot do that.

Work in small, visible loops

Set a narrow first goal with each partner. Rather than trying to transform their entire operation, choose one meaningful workflow: follow-up after a client call, handoff between a sales and delivery team, or preparation for a recurring review.

Then run a simple loop:

  1. watch the current workflow;
  2. agree on the smallest useful change;
  3. let the partner use it in real work;
  4. review the result and decide what to change next.

This keeps the collaboration practical. It also protects both sides from a long project that never reaches a useful moment.

Know when a partnership is not a fit

Not every early user should become a design partner. Be careful when someone wants a fully bespoke solution, cannot make time for feedback, or has a problem too different from the group you hope to serve.

Saying no is part of protecting the product\u2019s focus. The right partners help you learn a pattern. The wrong ones can pull you into a one-off service business before you have a repeatable product.

Good design partners do more than validate a feature. They help a team understand the work worth building for.