I’m a second-time co-founder. My previous company, Ooyala, was in the video production delivery and monetization space. We grew it to just under $80m in annual recurring revenue over 7 years before we sold it to Telstra, one of the largest telecommunications companies in the world. I started my professional journey on the engineering side, and after a few years, I migrated to product, then became Ooyala’s Chief Technical Officer. More recently, I co-founded and am the CEO of Cerby.

A bit about Cerby. Engineers and product people tend to be tinkerers. We’re always trying out new products, but often those applications are not completely secure. As a CTO, I often found myself running teams where I would onboard an application, and my security team would get a request from someone on my team to add them to it. The security team would find out I was running a rogue application and then would shut it down, which frequently became this cat-and-mouse game. It would put my security team in an uncomfortable position because, on the one hand, they need to protect the business, but on the other hand, their colleagues are saying, “We want to use this application.”

Cerby was born as a solution to this problem we continuously found ourselves struggling with. Cerby’s scope is to discover, secure, and accelerate any business automatically, by securing the unmanageable applications used within the company.

We launched our first paid product at the beginning of 2022 and since then we’ve converted most of our design partners to paying customers. Now we’re going through that transition from founder-led sales to a GTM motion powered by a sales team. We know that we have a product that solves a real problem for businesses, so it’s about equipping our salespeople to work independently of founders and get the value that we deliver into the hands of as many customers as possible.

Design partners are a critical part of getting product market fit fast, but there’s not a lot of information about how to make a good design partner program. I talked to a lot of founders to figure out how to build out our design partner program, and I strongly believe that this is a topic that a lot of early-stage founders would benefit from learning about.

You can think of a design partner as a trusted product user and tester, who you engage with on a regular basis. They give you feedback on features, use cases, and how your product is solving their problems. For all intents and purposes, they’re part of the team that’s solving the problem. There’s no pressure like, “am I going to convert them into a deal later on?”. It’s all about building something that’s going to be beneficial to the end user and make their lives easier.

Sometimes design partners are only considered relevant for early-stage companies, but I think that’s a limiting view. You can leverage a design partner any time you’re kicking off something fundamentally new and would benefit from an external or customer perspective.

I’ve only worked with design partners on the software side, but I don’t see a reason why hardware companies wouldn’t also benefit. It’s a way to ensure that you’re building something that people care about and will deliver value. I can’t imagine any companies that wouldn’t like to have a partner that provides value on a regular basis.

In those situations, the design partnership takes a slightly different form. You’re always going to have your power users. In a traditional sales-led motion, those power users will be an enterprise or a team at an enterprise, so it’s a lot easier to think about what a design partner looks like. With a PLG, the power users might be individuals, but you can still benefit from design partners.

When you put your product out there, you see who’s using it. And if you start to see that there’s a particular set of users that are very active you can still engage them and say, “we are working on this new feature and we’d love to get your feedback.” It’s just more individually-oriented, versus team or company-oriented.

Initially, depending on what stage you are at, you may cast a very wide net, approaching people proactively who aren’t users. We scanned channels like Reddit and Twitter looking for people talking about the problem that we’re solving. Then we’d reach out to them and ask, “are you interested in solving this?” What we found out initially was that individuals weren’t interested in being part of our design partner program, which led us to realize that our ideal customer profile (ICP) is typically more of a manager and is enterprise-oriented.

Once you’ve identified what partners are going to make the most sense for the product and problem you’re solving, there are different strategies you can implement. You can look at vendors that you compete with. For instance, we looked at the early customers of our competitors. Not all businesses are early adopters, but our thinking was that if a company was using our competitors’ products early on, they likely had a predisposition toward trying out new technologies in our category. For design partners, you want folks that have a history of trying new technologies.

Another useful strategy is to look at the networks of your investors. Those who join those networks are self-selecting, and they are basically raising their hand saying, “I’m an innovator, I care about new technology. I want to learn about the new technologies out there.”

You are getting paid with learnings. If you start getting a design partner program off the ground and the dynamics of demand shift from you asking design patterns to join your program, to partners asking you if they can be involved, then that’s a sign that you can maybe consider charging. If you have that problem, great, but you are getting paid with learnings so don’t prioritize contract values over education in the earlier stages of your product development.

Early on in the design partner program at Cerby, we only had two or three design partners and the roadmap was getting too strongly influenced by those few design partners, and you need to be careful about that. When you look at the composition of your design partners, you want to make sure that you have some variety, and in fact, some conflict where one set of design partners is telling you something different from the other. Otherwise, you run the risk of too narrowly fulfilling the values of a subset of your ideal customer profile.

We started out heavily skewed toward media and entertainment, which meant that our notion of how to solve the problem was skewed toward how media companies see the world. I think we caught it in time and eventually, we had a really good distribution of design partners across consumer products, technology, and finance. That allowed us to get a well-rounded view of the needs of potential customers, and narrow down the problem that we wanted to solve for them.

There are two things I look at. The first question is if a design partner is telling you they really want a particular set of features, startups should ask if this is something the customer would be willing to pay for. With a design partner, it should become very common to ask them, “how much would you be willing to pay for this feature? If we were in a renewal situation, is this feature something that makes or breaks the renewal?” When you frame it in terms of willingness to pay, and how much a design partner is willing to pay, you get a different level of validation, rather than a partner merely expressing their preference about feature sets. If you’ve built the design partner relationship properly, you should feel very comfortable asking that question and you should get a useful signal from it.

The second element is aggregate revenue. If you have one customer who’s asking for this feature and they’re willing to pay $600,000, and on the other hand two or three other customers that will only pay $60,000 but there are more of them, then you should always see how many of them are out there “in the wild”, in the broader market. If you’re a Seed/Series A company, you’re likely very focused on hitting certain benchmarks around metrics like ARR to get you to the next funding milestone. But you don’t want to over-index on that. If you did go with the design partner who will pay you $600,000 for that feature, but there are only four or five of those potential customers in the market, then you’ve undermined your future growth potential. So, you always want to look at your design partners’ willingness to pay, and the number of companies out there in the market that share that profile.

One reason you want to go into a design partner program and seek variety, is that early on you don’t know what a general design partner looks like versus what a narrowly focused design partner looks like. When we started including design partners from the consumer products space, we realized that a lot of what we thought was very specific to media and entertainment, was actually common to consumer products companies as well. Once you have at least two different design partner types in your program, you can start figuring out the commonalities, differences, and gather the feedback necessary for building a successful product.

Yes – remember that whoever wants to participate in your design partner program is itself a signal. If you are having trouble recruiting design partners, it means that you’re either not effectively communicating the pain point that your product is trying to address, or you’re solving a problem that prospects don’t care about. The earliest signs of product market fit are when you can find someone who shares your passion about the problem you’re solving and is willing to give you their time to help you iterate on your product.