Silicon Valley jargon lessons of the day:
- Design partners - companies (or specifically people in those companies) you get to design your product with; this could involve a payout at the end of the relationship or time spent on feedback to make the product better
- Letters of intent or LOIs - non-binding agreements you get design partners to sign to enter such design partnerships
I’ve entered in a couple design partnerships for idea exploration. Below are tactical lessons I’ve learned and some experiments I might try in ongoing design partner relationships.
- Get a solid setup. Have a handful enough that you get a variety of perspectives but not too much that quality of conversations and meeting with partners gets too unwieldy. Our sweet spot was about 5-10.
- Acknowledge you’ll be an “agency” to start. Your goal is to get your design partners to find value in your product. This might mean that, at the beginning, you build a rather frankenstenian product piecemeal to get those requirements fulfilled. At the same time, collect these signals to then figure out what a holistic version of the product will look like to then make the switch.
- Have a mix of sync and async channels. We meet with partners biweekly-monthly and have Slack connect channels for adhoc feedback.
- Phase your partnership meetings. I’m learning that design partnerships come in a couple phases:
- Exploratory/Discovery - understand their needs, core problems, use cases; Mom Test it out)
- Workflow and Design Clarification - clarify if you captured their end to end needs correctly with flowcharts and pie in the sky wireframes of their ideal product)
- MVP - align on the core MVP requirements that will immediately start solving their problem. To make this clear, ask something to the tune of: “If we built this MVP, would you pay us $XXX?” (see next point on getting a strong commitment!)
- Pilot - get the sign-offs and integrate into their systems; get as much feedback as humanly possible
- Get strong end commitment. What they say ≠ what they do or commit to. Ultimately, design partnerships help you understand if you’re providing enough value to your audience. End goal is to get strong commitment as a sign of value — ideally this money paid or a contract signed. Otherwise, they can talk on and on about how “XYZ feature” would be great or “ABC interface” could be better without putting money where their mouth is.
- Outcomes take longer than expected. As with any good software, building product will always take longer than expected, especially when additional requirements get padded along the way. Set expectations with your partners upfront. For us, we got LOIs signed but also had to fundraise, build out the team, balance a bunch of other partners and more! We made sure we established this upfront.
- Give regular updates on progress. About how the product is evolving, or otherwise. Our preferred cadence: biweekly. Don’t leave them in the dark.
- Build a relationship. Your partners are more than just corporate faces that give you feedback. They’re people shaping the early days and core outcomes of the company. Treat them well.
- Be open to scrapping some partners. If you’re not getting the right level of enthusiasm, they may not actually need your product and are less likely chance of becoming a loyal user. Or perhaps you learn they aren’t the right target market you want to go after to start. It’s ok to pause the design partnerships. The right ones will surface themselves to you along the way.
At this point, assuming you’re aligned on all things MVP, you can pause sync meetings until the pilot is ready.
Draft out a rough plan or timeline based off of your core phases and share your goals so they can be invested in the process too. This is something we only learned over time and will now be more upfront about!
Any lessons you’ve learned on your design partnership journeys?