To find design partners for a B2B SaaS, define the workflow you need to learn about, identify organizations that experience it, and ask for a bounded working relationship with an actual user and internal sponsor. Agree what both sides will contribute and when you will review the outcome. A useful partnership produces evidence about repeated use; enthusiasm at a demo is only a starting point.
Choose the relationship you actually need
An organization collaborates with you across product iterations. You agree on a learning question, access to a relevant workflow, and recurring reviews with the people doing the work.
A person tries an early release and reports what happens. Use the beta-users guide when you need a focused usability or onboarding check without a longer organizational commitment.
An organization buys an agreed product or service. A design partner can become a customer, but learning, independent use, and payment belong in separate fields of your record.
Start from a workflow and a reachable organization
- Write one uncertainty: Can an account manager use our handoff checklist during a real client transition without the founder present? This gives the partnership a concrete purpose.
- Identify organizations running that workflow using relevant company pages, public process descriptions, or introductions from people who know the work. Record the source and date; a job title alone does not establish the problem.
- Ask an introducer for the person who performs the workflow. In an initial conversation, have that person describe a recent instance, the existing workaround, and who would need to approve a trial.
- Offer a short scoping conversation before proposing a pilot. Explain what exists today and the support you can provide. Let the organization decline without being pushed into a sales sequence.
Copy the partner qualification worksheet
Create one record per organization. Mark each answer observed, inferred, or unknown, and retain its source/date. An unknown that prevents real use is a question to resolve before inviting the organization into a pilot.
- Organization and segment: [name]; [workflow shared with other possible customers]; [reason this is representative].
- Current work: [most recent instance]; [workaround]; [consequence of leaving it unchanged]; [source/date].
- People: [actual user]; [internal sponsor]; [person who can authorize purchase]; [which roles remain unconfirmed].
- Access: [sample inputs the organization may share]; [environment]; [permission owner]; [blocked prerequisites].
- Commitment: [who will try the workflow]; [review cadence]; [available time]; [next agreed meeting].
- Founder load: [setup effort]; [support limit]; [custom requests that fall outside the product direction].
- Decision: [invite, clarify, or decline]; [strongest contrary evidence]; [unanswered question]; [review date].
Two fictional candidates: enthusiasm is not enough
These are invented teaching examples for a prototype that coordinates client handoffs at small agencies. They are not Soloop customers or measured outcomes.
An account manager can walk through a recent missed handoff and has permission to share a redacted checklist. The operations lead can attend recurring reviews. Their workflow matches the prototype. Purchase authority is still unknown, so the next conversation checks it without treating payment as committed.
An enthusiastic executive wants a custom integration for a workflow the prototype does not support. No account manager can participate and sample inputs are unavailable. The founder records the request but declines: executive interest cannot substitute for a usable collaboration.
Copy a one-page pilot learning brief
Complete this together after qualification. It is an operational planning document, not a contract template. Choose a duration and cadence that both sides can sustain; the example below is a scheduling choice, not a universal benchmark.
- Question and scope: [one assumption]; [one workflow]; [prototype version]; [what is excluded].
- Participants and access: [user and sponsor]; [approved sample inputs]; [access boundaries]; [who resolves a blocked prerequisite].
- Calendar: [start]; [end]; [review dates]; [who observes the first use]. For example, a three-week learning period with one weekly review.
- Contributions: [partner attempts and feedback]; [founder setup and support]; [time limit on custom work].
- Evidence: [task attempted]; [completed independently or with assistance]; [obstacle]; [next attempt]; [notes location].
- Exit review: [evidence needed to offer a paid product]; [uncertainty that warrants a bounded extension]; [condition for ending]; [agreed handling of access and shared materials].
Record learning, then graduate, revise, or end
At each review, ask the user to show the last attempt before discussing feature requests. Record where founder assistance was necessary. A workflow completed only because you manually repaired every handoff does not yet demonstrate independent product value.
Repeated use addresses the intended job and a buyer wants to discuss the product offer. Agree the scope, price and next step separately. Record payment only after it occurs.
One specific unresolved obstacle prevents another meaningful attempt. Extend only with an agreed change, observation and end date; avoid an indefinite free custom-development arrangement.
Cedar completes the learning period and the account manager runs a handoff unaided. The buyer then explains that the team rarely changes account ownership and will keep its existing checklist. Record learning completed, no purchase, and insufficient recurring need. End the pilot and investigate organizations with more frequent handoffs.
Source and next research step
Bring your provisional partner profile and the open question to Soloop to discuss a supported, bounded research task. Review its action card before proceeding. A research report can inform your shortlist; you still conduct the conversations and manage the partnership.
a16z evaluates design partners through urgency, capacity and representativeness, and treats the learning relationship separately from eventual payment. The worksheets and fictional scenarios above are Soloop editorial examples.
a16z: A Framework for Finding a Design Partner