Kenny Browne was an engineer before he became a product manager leading tech partnership programs, first at G2 Crowd and now at Daxko. He shared the KPIs for product teams, his strategic advice on scaling, and the technical considerations that go into creating a successful tech partnership program.

As someone who has created and launched a technology partnership program, what would you say the fundamental KPIs should be for a SaaS tech partnership program?

There are a number of common ones, like the number of partners, customer attachment, and the amount of revenue if you are charging fees. But to really get to a successful partnership program you have to first decide what you are trying to solve and what you are trying to create.

For us, we are trying to benefit our company, our customers, our partners, and our customers’ customers. This process starts with identifying the needs of our customers, and if there are good product offerings that meet those needs, it’s a win across the board to partner instead of building the solution from scratch.

How do you determine what your customers need?

We have a ton of experience in our space. Our product leaders are very knowledgeable of our customer base, and we leverage that insight. We also have roundtables with customers, and ask our partners.

Talking with partners can also lead to new partners, as they pass on their own partners that are benefiting our shared customers.

The sales team brings me companies that prospects are asking for, and I track that feedback. In addition, we get a lot of inbound from potential partners as our customers ask them for integrations to our product.

How do you judge the success of your partnerships?

One of the main things we track is how many customers latch onto that partner. The key metric is customer usage. In some instances, we launch and find out that 20-30 of our customers are already using the partner’s product.

How old is your tech partnership program?

Our current program is relatively immature. I joined less than a year ago to help mature it into a scalable program. We now have 4-5 times the number of partners we had over the last 10 years.

You are a product manager overseeing the tech partnership program - what are the KPIs of your role in particular?

I can fail at everything else, but if we get partners, then we can be successful. My role initially was to come up with the program and get early adopters.

Now, I am shifting to how do we make this more automated and more seamless? How do we make sure the partnerships are working?

I am moving from early adoption to stabilizing the program. Expansion is the next phase, focusing on how we expand out to new types of partnerships and different types of programs. We are investigating content or distribution partners. A lot of our customers are gym facilities, for example, and they need towels, and badges, and we could move to offering through some of those distribution channels.

As we expand the program, my goal is to get 5-10 new partners onboarded a month.

What are the biggest challenges in creating a tech partnership program? And how do you tackle them?

The challenges that we face - and this is common to any product - is we have to make sure we're solving the right thing, and providing the right value. We got it wrong a lot before we started to get it right.

Once you get it right, your program starts to grow. But you can't get on 10 calls per partner with 30 different potential partners. We spend 30-40 hours to get one partner onboarded even when they are building the integration, so we have to make choices.

‍

Another challenge is educating people internally on what the program is. Sometimes people just think the program is the API, and that we can integrate with anything out there.

‍

The sales team does not necessarily like handing prospects off to partners as that is not a motion they are used to. With our program we don’t do direct partner sales so sales has to refer prospects, or set up a joint meeting with the partners.

We have to communicate to sales and customer support what this is, and how it works. We have seen some success here by giving internal webinars to explain the program and partners.

What should someone think of when deciding how to monetize tech partnerships?

There’s a lot that goes into how or whether you monetize. There are some companies that think, “I am a big fish so you have to pay me.” I don’t think that’s the right way to look at it.

You should start with market research, asking, “What are your competitors doing? What are they charging? What are your partners doing?” Once you see what the market looks like, you can decide what you are going to offer partners.

Are you going to offer co-marketing, training, or just the API? You look at what you are offering, what the technical costs are, and what you need to make off of it. You can’t expect to recoup your costs simply by monetizing from partners, a successful program requires both parties to be invested.

I’ve seen a lot of partnership programs fail to launch until they started charging partners money. Once they started charging, potential partners perceived there must be more value to it. Of course, it’s not enough to get partners, you then have to deliver on that value.

Even though your program is young, you already have more inbound partner requests than you can accommodate. How did you attract so much demand already?

Part of that is because our program is not automated yet. We have to educate each partner at this point, and there are only so many hours in the day.

But most of our inbound is coming from our customers requesting the integration to these third parties. The more value you are providing to your customers, the more they are going to be driving referrals.

In my experience, you can market to attract inbound partners, but ultimately if you have happy customers and a happy ecosystem, you will keep getting inbound demand.

We’re in the process of creating marketing collateral for our program but we are not ready for the increased inbound that could drive.

Who in your organization owns the partnership program?

It’s owned by product and right now that means me, and a partner manager who is in a bdr/customer success role. In my experience, partnership programs start out in product-sales co-ownership and move to product-marketing-customer success co-ownership. And of course, none of this is possible without engineering.

How is your engineering team structured?

We have an entire team of 12 dedicated to building the APIs and the platform our partners are using. Partnerships don't just mean APIs. We’ve created multiple avenues for data sharing that our customers and partners have access to. We also have had our engineering team build more API endpoints.

In some cases, a partner will sign the contract but it might be 3-6 months before we have everything ready and the integration is built. Even when there is a technical holdup, our partners understand it’s a short term issue and we are focusing on getting everything ready for them.

Any particularly effective GTM tactics for APIs and tech partnerships particularly?

I have a role in the GTM, and we are still defining what we want to do. We are starting to move from being able to launch and announce every partnership to having it be more focused and choosy. I’m working hand and hand with marketing to be able to scale this.

I don’t know if I can say I have found best practices but I have found major pitfalls. Don't focus on technical features, don’t focus it around yourself and don’t expect people to get it the first time. Treat it like any other go to market because you are not promoting to the developers, you are promoting to the market. I was a developer in a past life and sadly I did not get to choose which integrations we built based on how stunning their API was.

Does your whole organization support your program?

Our CEO, VP of Product, and CTO are all really pushing this program, and having that alignment is making a huge difference to its success.

I think our leadership understands that when you look at companies who have become major leaders in their space or have even gone beyond their space, like Salesforce, they all created these tech partnership programs and created them at the right time.

‍

In our case, customers weren’t asking about this as much two years ago. But now every time I shadow a sales call, people are asking about integrations.

‍

In general, five years from now, if you’re in a software business that sells to businesses, if you don't have a partnership program, you are going to be behind the times.  

Our customers are non-technical. Using standard email or an online calendar is what they are used to. They want to just click a button and have everything work seamlessly. We are going to see that shift across the board in the next few years.

You were an engineer before moving to product. What are some of the technical considerations around scaling a tech partnership program?

I will put my product person hat on first. You need to focus on what you are building and trying to accomplish, not how. The how might be the API, or it might be database access, but you should always keep the business goals you are trying to accomplish in mind to guide those decisions.

On the technical side, the most common issue is not building the solution based on the right need. You need to figure out what customers and partners will actually use. You create the systems and architecture so that you’re providing a solution that aligns with their needs instead of how your database is set up.

One thing to keep in mind is your user is a developer but you’re still selling to the business person. You have to build the API so that you can sell it to the business persona.

When I was an engineer, I wanted to fire some partners because the APIs were so bad, but I couldn’t because it still came down to business needs.

From the technical side, you should follow best practices for building the API, make sure the database can handle what you’re doing, and that you have tracking, analytics and error messages in the right place.

Once you get past general best practices, you have to make sure what you’re building meets the vernacular of the market that you are in. You cannot call something a user when it is a prospect, for example.

The API has to be built so that it makes sense to the decision makers. Otherwise, you just create a frustrating experience. Your API has to speak to the developers and the business side.

Are there other technical concerns in scaling?

One of the most important things to think about is security. The data belongs to your customers, and security has to go end to end, and through how you manage your APIs. It has to flow through any provisioning processes you have. It also has to flow into your partners’ development plans. Make sure they are following best practices.

You also have to make sure that you have the infrastructure to support whatever you are building. At a prior company, we built an API and that had a few use cases, and a customer started using it in an expected way that the API wasn’t designed for, and they broke the whole infrastructure. We had to rebuild it from scratch.

Make sure whatever you’re building does not fall over in 3-6 months. There are many ways to do that if you are thinking ahead.

Any strategic advice for other companies who are creating tech partnership programs?

I think one important piece to keep in mind is you don’t have to monetize them.

‍

You are providing a service, and you want to benefit your company, your partners, joint customers, and your customers’ customers. If you are not creating something that is thinking about all of those parties effectively, you will fail.

‍

Our messaging has been that as a company, we do a lot of things really well. We are the best at some, but we can’t be best at all of them. And we have identified the vendors in our markets who are providing the best solutions that we want to be able to offer our customers.

It is the vendors who show the passion for what we do and for what our customers do - that's who we want to partner with. Once you understand that is the goal - to provide your customers with the best across the board - that will drive your program, your GTM, and your monetization strategy. You have to understand the fundamental goal and build from that.

And it's okay to get it wrong. You can always fix it later.