TLDR: We just launched the standard Design Partner Agreement to help founders ground relationships with their earliest users and customers on solid footing. It’s free to download or use in our app.
In the earliest days of a startup, you don’t have much. Customer development helps you to validate the problem you’re solving and understand what has been tried in the past. You have a finite amount of runway and you need to build something that people want as quickly as possible.
One approach is to build your product and then find customers to sell to. This is risky – even if you diagnosed the problem correctly, customers may not be able to implement the solution you built or derive the benefit you expected.
The better approach is to work with design partners. There’s a lot of talk in startup circles about this concept, but what does a design partnership actually entail? And how do you actually structure the relationship? Should you charge them? What about Letters of Intent? We cover all of this and more below.
In addition to the committee of 30+ attorneys that creates all of our agreements, for the Design Partner Agreement we also sought out feedback from early-stage investors, founders, and operators. Special thanks to Adam Nelson at First Mark, Alex Bard and Patrick Chase at Redpoint, Andy McLoughlin at Uncork, Ed Sim at Boldstart, Ethan Schechter at Snyk, Justin Dignelli and Peter Zawistowicz at Pace, Liam Mulcahy at Kleiner Perkins, Mark Munro at First Round, Martin Gontovnikas at Hypergrowth Partners, and Shanea Leven at Codesee.
What is a design partnership?
Design partners are early believers in your vision. They have an urgent problem to solve, and they are willing to take a risk on your startup, which does not yet have product market fit. In exchange for that buy-in, you tailor the early product closely to the design partner’s needs, provide extra services, and/or give the design partner access on much more favorable terms than future customers. You get frequent, invaluable feedback and the design partner gets a highly discounted product that (hopefully) solves their specific problem in a new or novel way.
The philosophy that underpins a design partnership should be about co-creation. It has to be about more than a simple transaction or an exchange of goods.
Mark Munro, GM of Angel Track at First Round Capital
It’s worth clarifying that design partnerships are different from pilots or betas, although they sometimes get confused. All three have a level of uncertainty, but design partnerships describe a different kind of relationship that typically happens at the very earliest stages of a company.
Pilots (or trials, proofs of concept, etc.) are when a customer tries out a product that you’ve already built for a limited time period. Expectations are usually clear – if the product solves their problem, the end of the pilot results in a longer-term deal. Feedback from customers on pilots is helpful, but it’s not the main goal. Rather, the purpose of the pilot is to see if the product as it exists now solves the customer’s problem.
Beta features are new, usually unpolished additions to, or versions of, an existing product that are ready for user testing and feedback. You expect that beta users will report bugs and share suggestions, but these people are typically also using the rest of your more fully-baked product.
Design partnerships are about answering fundamental questions about product-market fit. They are high-touch and in-depth. Most startups start with five or fewer design partners, a number that allows you as a founder to own and cultivate these high-value relationships. So who are they?
Your design partners should be the customers you actually want, not the first leads you got through product signups or early access forms.
Martin Gontonivkas, Co-founder of Hypergrowth Partners and former SVP of Growth and Marketing at Auth0
Your design partners help to shape your product and strategy, and they serve as valuable social proof for investors and future customers. Think hard about your ideal customer profile and whose input will be most helpful.
This raises a question: if design partnerships are so important, should you formalize them with a contract?
Contracts with design partners
The idea of putting a contract in place with your design partners can be fraught. As a founder, design partnerships can feel precious and fragile, resulting in hesitance to strain the relationship or slow things down.
These concerns are legitimate, but miss some of the bigger picture. Your design partnership should be an actual partnership – with the terms of the relationship clearly understood and committed from both sides.
A contract with your design partner accomplishes two key things. First, the act of signing an agreement creates buy-in (or surfaces the fact that the buy-in you were counting on isn’t there). Second, it prevents conflict and disappointment by providing a place to set clear expectations for both sides.
In setting clear expectations, it’s often the feedback that matters most.
I would ask your design partner to agree to a meeting cadence (biweekly, monthly, etc.) to ensure you get the feedback you need. It also creates a reason to keep meeting with them, because at some point you want to sell to them.
Ethan Schecter, VP of Sales and first sales leader at Snyk
The Common Paper Design Partner Agreement helps you navigate this conversation by providing a simple structure for your and your design partner’s commitments: feedback sessions, private/public references, roadmap influence, discounts, services, and more.
This contract also allows either party to terminate the agreement at any time, for any reason. So much is uncertain at the earliest stage of a startup, and it would be unrealistic to try to lock in either side to a long-term relationship. This is one of many differences between contracts at the design partner stage versus what you would use when selling a production-ready application, like the Cloud Service Agreement. It’s also why the Design Partner Agreement is much shorter.
Design partners and letters of intent
An early termination option means that either side can get out whenever they want, so what’s the difference between the Design Partner Agreement and a non-binding Letter of Intent (LOI)? LOIs have some appealing characteristics – they’re typically short, flexible, and lightweight.
The most important reason not to use an LOI is because of problems with intellectual property (IP) ownership. At some point, your startup will need to make assurances that it owns and/or has valid licenses to the IP in your product. In the course of due diligence for fundraising, acquisitions, or your IPO, you will be asked to state in writing (and potentially provide evidence) that anyone who contributed IP to your product has signed an agreement assigning ownership of that IP to your company.
Remember that Mark at First Round said “The philosophy that underpins a design partnership should be about co-creation.“ Consider what happens when the only agreement that your co-creators have signed is an LOI, which, by definition, has no legal impact on IP ownership (or anything else for that matter). If your IP ownership is ambiguous, this raises a red flag in diligence, when you least want to create problems. You’ll be scrambling to track down the design partner and trying to get them to sign an IP assignment contract before you can close on your deal. If your point of contact from years before has left the company or just isn’t responsive, that nuisance can become a nightmare.
That’s why we struck a balance between clear IP ownership and an easy exit path if things aren’t working out. Importantly, the IP ownership section of the contract survives even if the agreement is terminated, preventing future diligence hiccups.
Charging design partners
Beyond the contract, the other most common design partnership question is about charging. You may not be immediately focused on revenue, but a pricing discussion with your design partners should be a part of the relationship.
Successful design partnerships lay the foundation for customer relationships. Charging upfront can be a part of that, but more importantly, having a clear set of goals and an agreement on what pricing will look like in the future and the process for them to become regular customers.
Ed Sim, Founder and Managing Partner at Boldstart Ventures
Your design partners have a burning problem that you intend to solve. If you do it well, there should be an expectation that they become full-fledged customers. The best way to make this transition smooth is to have the conversation early. This can be as simple as identifying a milestone, like the public availability of your product, at which point your design partner becomes a regular customer.
Working this expectation into your design partnerships becomes easier in a contract like our Design Partner Agreement, which is set up to handle the expectation of future discounts. Laying out financial expectations on both sides of the partnership makes it easier for your partner to say “yes” and more likely that you’ll convert them into a paying customer once the partnership ends.
If you’re building a company and ready to start working closely with your first few early believers, the Design Partner Agreement has everything you need. You can download it for free or use Common Paper to build, send, and sign your contract in a single workflow, in minutes.