We ran our Founder Studio - an accelerator for early-stage learning and work founders - for the first time from April to June. During the programme, we ran many sessions with founders, senior operators and corporates. This is the first of many articles we will publish built on the back of these sessions.
-----
A big logo reaches out wanting to "explore working together." For an early-stage founder, this is close to the best email you can receive. It's also, according to a GTM workshop we ran with Meg Porter and Sophia Ahrel as part of our Founder Studio, one of the moments founders are most likely to make a costly mistake. Why? Because excitement about the partner logo tends to override discipline about what the relationship is actually for. Please note that the following summary is based on our views rather than perfectly reflecting the points made in the session.
The core principle: design the partnership before you sign the partner
Most customers, including sophisticated ones, don't actually know what a design partnership is. They've heard the term; they assume it means something like "early access" or "we'll give you feedback occasionally." Founders who don't spell out the difference between a design partnership and a normal vendor relationship are setting up a misunderstanding that surfaces months later, usually at the worst possible time.
The fix is definitional: state explicitly what it is, how it differs from being a customer, what each side gives, what each side gets, and how success will be measured - before any work begins, not after the relationship has already drifted.
The binary: business design vs. product feedback
The single most useful reframe from the session is that a design partnership is not primarily a product exercise and is rather a business design. Many founders default to thinking of it as "they'll tell us what features to build," but the more valuable use of a design partnership is testing the entire go-to-market motion: pricing, positioning, onboarding, the sales process itself, the demo flow, the implementation model. Product feedback is one input among several.
That reframing changes what you want to learn from the partnership. Before starting any partnership, it's important to be precise about the actual questions you're trying to answer: Is this problem painful enough? For whom, exactly? Who buys this versus who uses it? What implementation friction exists? What pricing model could work? What proof points do you need for your next fundraise or your next ten customers? The structure of the partnership should serve those questions - not the other way around.
Let fundraising strategy drive the partnership, not the reverse
One counterintuitive piece of advice shared by Sophia and Meg: they argued that investors are often equally persuaded by one deep, well-evidenced design partnership as by several scattered paying customers (we'd largely agree with this but it's all relative). A single partnership, run well, can prove customer pain, ICP fit, and real commercial intent all at once - which means the decision of how many partnerships to run should follow from what you're trying to prove for your next raise, not from an instinct to look busy by juggling five relationships that overwhelm a small team.
Paid beats unpaid, almost every time
The session's clearest recommendation: lean toward paid; even a token amount changes the psychology of the relationship. Payment creates mutual commitment. It keeps the exchange balanced instead of one-sided. It measurably increases the odds the relationship converts into a real customer later, because both sides now have something at stake.
If payment genuinely isn't possible, the exchange still has to feel fair and meaningful on both sides - access, intros, a testimonial, something concrete. And there's a labelling discipline worth holding onto here: if what you're actually running is a discounted pilot, bespoke development work, or a large customer project, call it that. Mislabeling a large customer engagement as a "design partnership" was flagged as a specific failure mode later in the session, and it causes real confusion both internally and with the partner.
Who actually needs to be in the room
A design partnership qualified only through an executive sponsor is a partnership that will generate usage signal without ever generating buying signal. You need three things: an exec sponsor who can decide, at least one internal champion who's motivated day-to-day, and genuine access to end users. This matters most in B2B2C, enterprise, and marketplace models, where the person who says yes and the people who actually experience the product are rarely the same person.
Starting top-down is normal - sponsors are usually who takes the first meeting. But stopping there is the mistake. A second relationship, closer to the actual workflow, is what connects you to users, operationalises the engagement day to day, and plays value back upstream to the sponsor when it's time to renew or expand.
A repeatable lifecycle, not a one-off improvisation
The session offered a simple five-stage structure worth adopting wholesale rather than reinventing each time:
1. Find and qualify candidates against your ICP and learning goals
2. Align and charter the goals and value exchange explicitly
3. Collaborate through structured discovery and testing
4. Validate usage, outcomes, and willingness to pay
5. Convert and keep moving the relationship into a standard customer arrangement and, ideally, an active advocate.
Documenting this once and reusing it matters more than it sounds like it should. Ask after every partnership what should stay the same, what should change, what can be templated. Otherwise every team, every time, is rebuilding the qualification criteria, the stakeholder map, and the feedback structure from scratch - which is an avoidable time-suck for a small team.
The warning sign: when a partner starts running your roadmap
The session's sharpest diagnostic question: if you wouldn't want to market what you're building for this partner to anyone else, it's probably not strategic. Other tells that a partnership has quietly become roadmap capture rather than validation include: the partner dominates prioritisation conversations, bespoke requests keep appearing and your team starts reacting to their asks instead of learning from the engagement.
The fix, when this starts happening, is a change control process: re-anchor on your own product and GTM strategy, pressure-test their requests against other partners and your actual ICP, and give yourself three honest answers to any out-of-scope ask - yes, if it's genuinely strategic; later, if it's not yet important; or priced separately, as paid custom work, if they specifically want it now regardless.
The cautionary case study: when the logo becomes the priority
The session's central example was a large enterprise engagement where a very large brand name generated enough internal excitement to override the team's usual discipline. The relationship was innovation-led rather than tied to the actual buying committee, ran more like a statement of work than a balanced exchange and had misaligned commercials from the outset. Roadmap pressure followed almost immediately.
The retrospective lesson wasn't "don't work with big companies." It was that this was, in substance, a large customer engagement mislabeled as a design partnership and the mislabeling itself is what created the confusion, both for the internal team trying to manage expectations and for the partner, who never had a clear picture of what kind of relationship they'd actually signed up for.
The steelman: this framework assumes you have leverage to spend
It's worth being honest that "lean toward paid" and "protect your roadmap" are easier to say than to do when you're three people, pre-revenue, and a large brand has just expressed interest. Early on, especially while still discovering your ICP, it can be reasonable to run several looser, unpaid engagements simultaneously specifically to learn who converts fastest and where the pain is sharpest, with the explicit understanding that you'll narrow deliberately once the pattern is clear, rather than let five shallow partnerships become five permanent obligations. The discipline this session describes is the target state, not necessarily the starting state for every founder in every negotiating position.
For founders about to say yes to a design partner
Before you sign anything: write down the three to five things you actually need to learn. Build a simple scorecard for what a good design partner looks like against your ICP, and use it honestly even on exciting logos. Decide the minimum value exchange you need - payment, access, feedback, advocacy - and put a change-control mechanism in place before the first out-of-scope request arrives, not after.
And if you're currently calling something a design partnership that's really just a big, unpaid customer project: it's worth renaming it, if only so your own team stops being confused about what you're actually optimising for.
If you're building a GTM motion around design partnerships and want to think it through, we'd welcome the conversation.
