Kabir Mathur has spent his whole career in business development. He is currently the Head of Product Partnerships at Typeform, a company known for its well-designed and easy to use survey and form tool.

Typeform's integration ecosystem is rapidly growing, with 50 new integrations launched just last year. Kabir shared why his team reports to Product, his advice for SaaS product partnership teams looking to scale, and how he sees the SaaS tech ecosystem evolving in the next 5 years.

How did you get into product partnerships?

I have only worked at startups and in business development. My prior roles were in mobile gaming and advertising but my focus has always been on partnerships and finding mutually beneficial opportunities.

In gaming, I was more focused on distribution through larger publishers. In adtech, partnerships involved working with publishers that could help us publish ads to different audiences and ad exchanges for additional distribution.

In my current role, I am focused on increasing and improving integrations between Typeform and other SaaS products. Our goal as a partnerships team is to make it as easy as possible for our customers to use Typeform with the other tools they are using on a daily basis.

Whom does your team report to? Do you have any advice on the best reporting structure for partnerships?

At Typeform, we report to the Chief Product Officer. In prior partnership roles, I have reported to the Chief Operating Officer or the Chief Revenue Officer.

I don’t think there is one correct answer for whom partnerships should report to. I think it really depends on your program objectives.

You can see significant revenue growth from partnerships as a channel. We are growing very rapidly, and revenue  growth is nice to have. But for product partnerships at Typeform, growth is not our mandate or primary objective.

That is an objective that many SaaS companies set for their product partnerships. They want to leverage the mature marketplaces, like Salesforce or Hubspot’s, to drive new leads. And if they get visibility in those marketplaces, it can be a good road driver.

In the early days of a SaaS company, it makes sense to lean into driving revenue and thus have the team report to revenue. But as you get more mature, it usually makes sense to move product partnerships under Product. You need to be more product focused to successfully scale these types of partnerships.

How would you describe your strategic north star?

The north star for us is retention. All SaaS companies want to improve retention, but due to the nature of our product, improving retention can make an even bigger impact for us.

Many SaaS products have long implementation periods and require significant work to migrate off of, but our product is easy to use on a project basis.

Customers might sign up for a certain time period to complete their particular project and then churn off. So for us, we put a lot of onus on integrations as a retention factor. The more customers integrate our product with their other systems, the less likely they churn.

Even if you don’t have a tool that can be used on a project basis or are facing a churn “problem,” it is worth increasing customer retention and satisfaction with integrations. Your retention numbers can almost always be higher.

What other metrics do you look at to judge the success of your integrations?

Another factor is customer expansion. We look at whether integrations have an impact on customers upgrading to higher plans. Sometimes this impact is easy to measure, sometimes it is not. If integrations are baked into higher plans, sometimes you can directly attribute it as the reason a customer chose a higher plan.

We also look at the quality of integrations, which is important to the user experience and actually having a positive impact. You can judge this by looking at customer satisfaction numbers and surveys, and the amount of integration support tickets you are getting.

You can also track the number of deals that integrations close, either as an influencing factor or a referral from your tech partner.

Related Content: How to Measure ROI on Tech Partnerships

Do you have an integration marketplace where your customers can discover integrations?

Yes, we have an integration directory. But we currently do not have a way to directly monetize these listings. So we are not using the directory as an additional revenue source by charging our partners for leads or new customers.

We are able to track integration usage on our side, though. We can see what the adoption looks like for different integrations. If we see strong adoption, we take that as a sign of momentum and that our customers are seeing value in that app. When we see that, our engagement with that partner increases.

What is your framework for deciding whether you will build an integration or your partner will build it?

In some cases, we have no choice. Like if they are the size of Salesforce, they just aren’t going to build it. If they are significantly bigger, we have to build. And if they are significantly smaller than us, then they have to build.

If they are of a similar size, we will have a conversation with our counterpoints, and see what makes the most sense. Once we come to an agreement, we will prioritize it on the roadmap accordingly.

For context, we launched about 50 integrations in total last year, and we built about 15 of those. The others were built by other SaaS companies of various sizes.

Do you have an approval process for partner integrations you show to your customers?

I oversee that process as well. We don’t have very arduous approval requirements. We support partners from an engineering perspective and make sure we have a mutual understanding of what they are trying to build. From there, we get them listed. We’re planning to launch a more automated integration review and approval process later this year.

Do you have any way to control the user experience of partner-built integrations?

We are working on building a framework where users don’t have to leave our app. But right now we don’t have much control over the user experience when they leave our app to install and manage a partner-built integration.

We don’t hear about our users having a bad user experience with these integrations, but we would still like to see the adoption and usage more granularly and control the experience more.

In terms of visibility, we have a developer advocate on our team and he runs reports to see the API usage, and sometimes there are nice surprises and we see a lot of adoption with a particular app.

But we are building a framework that would enable our partners to build on top of us and keep our users inside our app. This will give us more control over the user experience and also give users a better experience. It would enable us to prevent breaking changes, and route customer support tickets so customers get the help that they need when they need it.

Overall, user experience is the primary driver for building this new framework. It is a big engineering project. We hope to have some version later this year, and invite a handful of partners to build on top of it, and then open it up from there.

Once this is available, it will be a game changer for us and our partners, and the joint power of the applications and their extensibility.

Related Content: Building a Support Strategy for Your B2B SaaS Integrations: Key Considerations for Product and Partner Managers

Do you have advice for SaaS companies looking to scale their technology partnerships?

Start thinking about it early in the evolution of your company. Companies should establish a framework to prioritize partnerships when they are early stage. This doesn't necessarily have to be marketed to external partners in the form of a partner program. It could simply be used internally to help the partnership team understand how to prioritize their time and resources.

If a company then decides that building an external facing partner program is important to their goals, they should work on a compelling incentive structure to attract partners to their program. If you do this in a haphazard way and try to be opportunistic, then organizing it into optimized tiers later is going to be tough. Think about incentive structure and what your partners’ goals are as early as you can, even before it is formalized.

Identify the different categories of partners you will have and build your programs and incentives around those categories. Make it clear how partners can advance to higher tiers and the incentives associated with each of those tiers.

If your organization is focused on revenue goals, then you can incentivize partners to drive more referrals and influence deals. Commission structure can overlap with your resellers. If you are more focused on retention, then reward integration adoption and partners’ impact on customer satisfaction.

You always want to give your partners a reason to grow in your ecosystem. Think through what you can offer them as an organization. There are standard marketing and engineering benefits to offer, but you may have particular strengths that partners in your ecosystem really value.

For us, for example, partners see a lot of value in getting in front of our large audience. We highlight how customers are using different integrations on our website. This puts our partners in front of a huge amount of people. We also announce new partnerships in emails, and partners get visibility by being in our integration directory.

Do you use any partner-specific tech to manage your partnerships?

We have scaled up so fast that all processes are not as tight as they could be. We still use Hubspot as our primary system. You can create deals for partners and you can customize the deal stages to match exactly what your partner journey is. And your emails are all in one place.

We also use PartnerStack, but that is more focused on reseller partnerships. Our team uses it but to a much lesser extent. It makes it easier to track revenue generating activities with your partners. A PRM is certainly worth investing in if you are revenue focused.

We have a developer newsletter to announce changes to our product and API, but one-to-one emails either go to our support or partner team.

Related Content: What is a Unified API? And How to Evaluate One for Product Integrations

Do you have any advice for getting enough engineering resources as a product partnerships leader?

Getting enough engineering resources was a problem when we weren’t under Product. At Typeform, we are very data driven. You always have to find the middle ground as a startup on a foundation of data. If you have data backing up what you need and showing the value it will have, this helps.

There is always a question as to whether you should focus your engineering resources on building out the core product versus extensibility. But if you can measure and show the impact of integrations on retention and conversions, it will be easier to justify spending more resources.

How do you see the technology partnership landscape evolving the next 5 years?

As businesses, we are all only increasing the number of SaaS tools we are using. There are tools for everything now. Because of the SaaS expansion, a lot of partnership teams need to figure out how to scale. You are going to want to figure out how to be a truly integrated product.

I am surprised how many companies still don’t have open APIs and that those barriers to entry exist. That should continue to erode in the coming years.

There are a lot of iPaaS platforms, like Zapier, Tray and Workato, and these companies excel at connecting the dots. More companies will use these tools, and companies will also build more native integrations.

At Typeform, we also fully support workflow automation platforms like Zapier, for example. Zapier connects with 2k apps, and they may cover a long tail of apps and use cases that we may never natively support. Those types of tools are complementary to building and offering native integrations that you do control.