— How we work

Design partners for B2B SaaS: a pilot with a decision at the end

Build a B2B SaaS design-partner program with a clear workflow, feedback owner, pilot evidence and exit decision. Avoid an endless custom-project backlog.

3 min readUpdated 2026-10-30By AptixLabs studio
A pilot needs an ending. Diagram: Observe — Current workflow; Agree — Pilot charter; Run — Collect evidence; Decide — Continue or stopAptixLabs · 2026-10-30

Original AptixLabs workflow diagram; a planning model, not measured product results.

A design partner helps you learn whether a product solves a real operating problem. The relationship becomes less useful when every conversation adds features and nobody can say what would make the pilot successful. Begin with a charter that names the workflow, participants, evidence and decision at the end.

Recruit for the problem, not the logo

Look for an organisation that experiences the target problem repeatedly and can give you access to the people doing the work. A well-known company with no available operator may teach you less than a smaller team willing to show its current process. Confirm that the person enthusiastic about the pilot can arrange feedback and discuss a future buying decision.

First Round's interview about Gong's path to product-market fit describes learning through early customer relationships. It is a company-specific account, not a universal formula for how many partners to recruit or whether every pilot should be paid. The transferable question is whether the relationship produces evidence about the product's core job.

Reference: Gong's product-market-fit account at First Round

A practical design-partner charter
DecisionWrite down before starting
ProblemOne recurring workflow and its current friction
ParticipantsOperator, feedback owner and commercial decision-maker
ScopeIncluded journey, explicit exclusions and dependencies
EvidenceBaseline, task outcomes and qualitative feedback
Working rhythmDemonstrations, issue review and response responsibilities
Commercial termsFees, access, ownership and proposed next-step process
End decisionContinue, revise, purchase, pause or stop

Observe the baseline without inventing ROI

Ask the operator to complete the current task and record the relevant steps, delays and failure points. Use the same definition during the pilot. If the task occurs infrequently, say so; a few observations cannot support a precise annual savings claim. Record uncertainty rather than turning every anecdote into a percentage.

Include unsuccessful attempts. A product that saves time when it works but frequently needs manual repair may not improve the overall workflow. Have the partner review the interpretation before using any result publicly, and agree separately on permission to use its name or quotation.

Protect the roadmap from unbounded custom work

Classify feedback into defects, evidence about the core problem and requests specific to one organisation. Decide which category can change the pilot scope and who approves it. A design partner should influence your understanding; it should not accidentally receive an unlimited development contract.

When two partners request incompatible behaviour, investigate the difference in their workflows. It may indicate separate segments or a configuration boundary. Adding both requests immediately can produce a complicated product before you understand why either is needed.

Define the exit while everyone is optimistic

At the closing review, compare the agreed task with the baseline, list remaining blockers and ask for a concrete next decision. State how data is exported or removed if the pilot ends. Do not treat a positive meeting as a purchase commitment or continuing access as permission to publish a customer story.

Related: technical evidence for startup due diligence

A partnership conversation with AptixLabs

For B2B product teams and potential UltraFit360 collaborators, we welcome a specific workflow, audience and proposed contribution. A pilot might explore coach-client coordination or a bounded integration, subject to feasibility and an agreed scope. This is an invitation to discuss a possible arrangement, not a claim that a standard design-partner program or commercial package is already in place.

Bring the problem owner and an example of today's process. The useful first outcome is a small, reviewable charter with a decision date—not a long feature wishlist with no end condition.

What makes a good SaaS design partner?

A good fit has the target problem, available operators, a feedback owner and a path to a commercial decision. The organisation’s brand name alone does not establish that fit.

Should a design-partner pilot be paid?

Agree terms that fit the scope and relationship. State fees, responsibilities, ownership and the next-step decision explicitly; neither free nor paid pilots automatically prove product demand.

Explore a product partnership

Tell us who you serve, the workflow you want to improve and what each side would contribute. We can discuss fit, available capabilities and a bounded pilot.

Discuss a partnership