Between Product and Partnerships is a podcast brought to you by our group the SaaS Ecosystem Alliance and it’s focused on bringing together product, partnerships and engineering leaders to discuss how to build support and scale SaaS ecosystems. If you're interested in watching or listening in on this conversation, you can access the video here and links to our podcast platforms here.
Our former Director of Marketing, Kelly Sarabyn, Interviewed Francois Grenier, the Head of Technology Partnerships at Sendoso and former Head of Platform Partnerships at Typeform about the importance of product thinking for partnerships, building integrations for customer retention vs acquisition, advice for gathering information on ICP tech stack and customer feedback, and more.
Intro
Francois: My name is Francois, I used to run the partnerships team at Sendoso, but I recently refocused my responsibilities on building out the platform and integrations ecosystem at Sendoso, so I joined the product team as of a week ago. Before that, I grew the platform and partnerships ecosystem at Typeform.
Before that, I was working on more go-to-market partnerships, but my favorite part of partnerships is definitely the product side.
Kelly: At Typeform, doesn't tech partnerships report to product as well?
Francois: As of today, I don’t think they do anymore. When I joined back in 2018, we reported to the Chief Platform Officer that eventually became CTO. Then a couple of months after I joined, there was a change in leadership, and we hired a COO who wanted to own partnerships. He really saw partnerships mostly as a go-to-market and customer acquisition play, even though we were building this whole thing mostly for improving the customer experience with the product.
It was more of a product play, and he realized that a few months after joining. Then, partnerships moved back under the product organization. I think from what I heard, they may be back into the business operation side of things, but I'm not too sure about that.
Kelly: I wanted to dig into that a little bit more, because I think especially mid-market companies who are growing really struggle with the reporting structure. Having been through this at different companies, do you have any thoughts on how to frame that decision?
I don't think there's a one size fits all answer as to where tech partnerships should be reporting in an organization, but what's your advice to companies who are making this decision?
Francois: I really believe it depends on the context of your organization. If I take the example of Typeform, for instance, we didn't have an acquisition problem, we had a retention problem. So integrations were seen as the biggest lever to tackle that churn problem. Because we didn't have an acquisition problem, it was not really top of mind, at least in the early days.
So being part of the product organization made our lives a little easier, because we removed the pipeline and co-selling distractions from our work, we were there to build a retention engine, and we were able to focus on just doing that.
That also meant more time to explore potential integrations and/or partnerships. Those are not necessarily always tied with each other. Some good partnerships may not really have an integration involved and vice versa. But to continue, we were not chasing or making decisions on integrations to build based on the acquisition potential, the level of engagement from sales, or execs on either side of the aisle.
We were able to focus on what really adds value for customers, and what really makes their lives as a user of Typeform better. Surprisingly enough, we build those integrations, and some of them turned out to be fantastic growth channels as well. This however was a byproduct of the work we were doing, and our focus was really on the user experience.
This work also happened to turn into really cool channels. If you've ever had HubSpot or Zapier blog about you, you know that you get a ton of traffic from those because they're really good at SEO and driving traffic to their partners.
At Sendoso the play was slightly different, and there was more of a cultural approach to partnerships, because we were founded by salespeople, or people with a sales background. The main tag on partnerships was go-to-market motions including co-selling, co-marketing, and building out the ecosystem. We were moving partnerships as a whole into more of a central go-to-market function in the company.
So partnerships, marketing, and all of the sales functions and customer experience functions will report to one person, which I think is going to be a better position for partnerships to have an impact on the organization.
We have been for the last six months, part of the marketing organization, which in my opinion, is the worst place to be because you become obsessed with pipeline numbers, and your CMO is obsessed with pipeline numbers. So if you ask for resources to do anything else, it's a really hard conversation to have. Being more central means you can really focus on building out a partnership function. For that matter, technology and agency partnerships probably have more in common than we give them credit.
Agencies should absolutely have an impact on retention, because a customer using an agency should have a better experience with the product, become an expert faster, activate more, get more value, etc. So it's no different from technology partners. Essentially, being able to have a more central function gives us more buy-in internally and customer support, customer onboarding, education, and marketing and sales will naturally be inclined to work with partnerships.
The only exception to this at Sendoso is me. I'm really inside the product organization, and I'm there for one good reason. We have excellent coverage, and really smart people that are focusing on the go-to-market side of things, and so my role is really about growing the ecosystem and making Sendoso as valuable as possible for our customers. I'm back to this customer first mindset now.
Kelly: How do you envision that collaboration playing out? Since you're in the product org now, are tech partners interacting with the partnerships people on the more go-to-market activities, and also collaborating with you on the product integrations and product roadmaps staying aligned?
Francois: Yeah, that's a good question. I think that’s one thing that we definitely need to work on at Sendoso, which is being better as a product organization when it comes to figuring out what problems we could solve for customers that we are not solving yet. A large chunk of the product organization, as with every organization, is focused on undeniably prioritized issues like smoother user experience, less bugs, and higher reliability and things like that. These are not necessarily acquisition driven, but are more problems that you would experience with a product once you're already a customer.
On the other side of this we need to be more mindful about how we can better serve our ICP and how we can build a product that feels more enticing. As much as getting integrations adopted correlates with retention, there's also an acquisition mindset to be had around building the product so that it caters better to needs of the customers that you cannot really please today with your narrative.
If you're very biased towards a set of platforms that you integrate well with, but there are competitors of those platforms that you don't for instance, then you will isolate yourself from that potential market share, as well as, customers using those CRMs, marketing automation platforms, etc. We need to be a little bit more mindful about that.
Integrations are very different from other features in that they tend to disqualify you way sooner than features that you will find you should have had to close a deal later on in the sales cycle. You will find that to be true if you're not doing certain reporting things or other functions once you're really mature with your demo cycles; However, if you don't have integrations with the platform that the customer needs, the customer is going to kill that opportunity at stage one. So, the role of integrations are very different from any other features in that respect, with more dimensioning for how the pipeline will be able to move along.
Related Content: Designing and Scoping Multi-Purpose SaaS Integrations with ShipBob
Kelly: Yeah, and one thing I've observed the last few years is that customers are becoming more savvy in terms of realizing that not every integration is built the same. Maybe three to five years ago, a lot of companies could just say “oh, okay, you're integrated to Salesforce, great, check the box, sign the deal.” Then, maybe six months later, they might find out it doesn't quite meet their needs. This is somewhat anecdotal, but I do hear more people asking ahead of time to scope integrations out in a more detailed way to make sure it meets their needs, especially with more complex integrations. Is that aligned with what you're seeing? Or do you feel like customers still are just looking to ensure that the box is checked and that you have a connection?
Francois: You're spot on there. It actually almost can be brought down to two problems that you're trying to solve. One of them is you need deep integrations to actually provide that extreme value around the product by providing a very tight integration that does everything that customers needs. That's the retention side of things.
Then, there's an undeniable fact in marketing SaaS right now. A couple of years ago Scott Brinker posted a study on the Chief Martec blog that said that the level of integration was the main deciding factor for buying a SaaS marketing product. That really has almost nothing to do with how good the integrations are, and has more to do with customers being confident with going with certain platforms because they have all the logos they need to see on their integrations page.
Whatever usefulness they’ll get out of those integrations is almost irrelevant at that point. It becomes a problem once they joined, and it turns out the integration kind of sucks. So it's our job to make it as balanced as possible between the vertical integration and horizontal breadth of integrations to advertise the product and make it more appealing to a buyer. It's not an easy task, you need to really understand your ICP there.
You need to know which ones are peripheral that you can just fluff out to make it part of the conversation, versus which ones are going to be at the center of your products experience.
Kelly: Do you have any advice on gathering that information? There's some tools out there like Clearbit that marketing departments can use in terms of figuring out the customer tech stack. For example, they’ll show you a certain number of technology that even your prospects are using. That's one way to start gathering the information and profiles. Then obviously, talking to customers and partners. This also ties into prioritizing integrations, right? Do you have any other tricks or advice for this?
Francois: I would categorize three different things here. You mentioned Clearbit, and their tech tags are useful. Similarly, Zoominfo can provide some level of insight with this. If you really have nothing to deal with, you can always do a builtwith.com search. Either of those options are a decent level of information, but not that reliable down the road.
Platforms like Crossbeam, are basically a source of truth. If you see that prospect A is also a customer of Zendesk, Salesforce, and Marketo, then you've got a good sense of what their tech stack looks like. It doesn't necessarily mean that the buyer that you're talking to is an active user or has an interest at all in integrating with this. This does, however, give you conversation prompts that you can start using to qualify and better understand whether you need to talk to that particular buyer about one of the integrations that you support and think they would care about.
There's another reason to warrant a little bit of caution with these tools, but it really doesn't happen that much with those platforms. It’s when you're looking at potential partners or existing partners of yours that have a strong self-serve model. You will see some times that they have customers that really look more like they should be their direct competitor, and so, you know that they're not using it.
So HubSpot could come up with Klayvio and Sendinblue being customers of HubSpot. That sounds like they're more trying to scope competition rather than actually actively using. So, you need to be able to identify those, but thats very easy to spot. The third idea is to run a good old technographic survey with both your customers and your prospective market to understand what they are using for different things.
Some products do this really well at the onboarding stage. I used to share and beg all of my product colleagues at Typeform to go through the ClickUp onboarding experience. I don't know if you've ever done that, but they are actually really good at asking you through their self serve onboarding experience what you use for CRM, for internal communications, etc. They also actually prompt you throughout the first couple of weeks of your customer experience to integrate with products you mentioned in onboarding.
If you said you use Microsoft Teams, then it would prompt you to integrate with teams. So those survey’s are not only good sources of information, they are also good reminders for customers that they should activate the integrations, become a better customer, and get more value out of the platform as a user. It’s actually the same thing down the road. You become a better customer, because you get more value out of it.
So, with this example you can have hacks around the product to collect the information without making it overwhelming. A technographic survey can be a little intimidating, and you need to have a budget to incentivize responses. Whereas throughout onboarding, you can be very targeted, and it doesn’t feel so intrusive and can maximize response rate. I recommend collecting this information with a blend of technology tools, onboarding questioning and technographic surveys.
The other benefit of technographic surveys is that you can follow up and ask qualifying questions. For example, if a a prospect is using Salesforce, how do they expect to use it together with your product? What should the experience be? What do they need to do with Salesforce that we may be able to help with that we’re not supporting today? Then, you can start looking at the roadmap, developing new user stories, and working to make the integration better. This gives you contacts as well to people that you've basically paid to answer your survey, so you are entitled to actually reach out to them and follow up and run an interview program with them to better understand what you need to be building to make the integrations more useful.
Kelly: How important do you think it is that the questions of integrations get in on customer satisfaction surveys, both for this kind of actionable information, but also as a way for the tech partnerships team to show that there's an impact?
Francois: Vital. Customer satisfaction (CSAT) for integrations has been part of my playbook since Typeform. In the early days, we had our leadership questioning the quality of integrations. We were looking at tickets, and if you experience a bug with an integration, you'll open a ticket and thesupport team will know about it. Some customers can be very loud and very vocal about their level of happiness or unhappiness about an integration though. You will tend to see that as a stronger signal than it really is, because it could be a very low value customer, for instance, or customer that is asking for something or complaining about something you shouldn't be doing.
You need to respect also your company's strategic alignment there. Nothing beats asking customers how they feel about it, and making that as many data points as possible. At Typeform we launched a CSAT integration that was popping up for customers that had been using an integration for more than a month. We were asking them the same questions six months later, because sentiment will evolve even if the integration hasn't. You might find it barely useful at first, but then realize that six months down the road, it actually helped you or vice versa.
This is also useful because is it helps you make sense of external noise as well. You might have a couple of bad reviews on the Salesforce AppExchange, or on the HubSpot Marketplace that will make a bad impression with your execs. Sometimes if you look at the comments, they may actually be pretty irrelevant. They may be judging your platform, not the integration. So asking straight up questions about the experience around the integration to your customers directly and regularly helps you keep your finger on the pulse of the experience with each and every individual integration.
We also rolled that out at Sendoso as well a few months ago, just to make sure that I was joining the product team with at least some data to start working with. We're already learning a ton from that. We had never really done that before. Our preferred way of collecting data for the longest time had been through account managers and CSMs actually talking to customers. That's really hard to reconcile, because customers will talk about a bunch of issues and a bunch of things that they like and dislike. This makes it really hard to make sense of it from an analytical perspective. Having the CSAT survey removes that conversation from the equation, and also helps you organize that a little better. In my opinion, I cannot advocate more for CSAT surveys for individual integrations, it's a really good hack.
Kelly: What about the quantitative side of this? I think that qualitative side is so important, because when we're doing this tracking the best case is we're getting these amazing correlations, right? The person who's using five integrations they’re retained 500% more for example. You can get pushback, though, where people can say that person was just always going to be a super user of the product.
I think that's where the qualitative data helps to back it up. In terms of the quantitative side, though, is this something you think mid-market SaaS companies struggle with to actually get partnerships to be able to access that data in terms of defining the customers using specific integrations? Or do you think that's pretty much a straightforward process and you just need your product and engineering team to set it up essentially?
Francois: Good question. Again, very different experiences at Sendoso and Typeform, I think at Typeform, people were a little more prone to churn because of an integration than at Sendoso. We might see an integration having more tickets or more bugs being reported than others, but they don't necessarily link to churn because they are still too much of a peripheral part of the product. It's a luxury for us to be able to address those issues before we actually make them more of a central part of the product outside of certain integrations that are really deep into the product. At Typeform, because we were a self serve product, it was easier to churn as well. A lot of our customers were month to month, and may still be for that matter. I'm just not there anymore. Assume that my statements about Typeform stop a year ago.
It was easier for people to churn, and in the churn survey they could just complain about lack of functionality for integrations and so on. This also happened to be excellent feedback both quantitatively and qualitatively. I don't think we can get away with not deep diving into the qualitative side of things, especially with unhappy customers. It's probably actually a good way of filtering out the the power users and champions of your product, because the ones that are pissed very unlikely are one of your champions, and they are the best source of information for you to improve your product and your integrations as a product for that matter.
Kelly: And what do you think about mid-market companies who have their own in-app marketplace adding reviews? I think you're alluding to reviews, in general, as a self selecting group. A mid-market company may not have the volume that Salesforce or HubSpot has, for example, but is that still valuable to other customers, and valuable to the SaaS company as another source of information?
Francois: This is an ambiguous topic, because if you're on top of your G2 play, you should have good reviews. This is more of a marketing performance issue than a product performance issue.
Kelly: I mean reviews about the integrations though.
Francois: We've never had that at Typeform, and we don't have that at Sendoso. What I'm seeing a lot though is app directories integrating with G2 reviews and Trustpilot, which end up being about your product, and not the integration.
Kelly: Right, because you can have a great product that people love, but you could have a crappy integration. So, it is somewhat misleading.
Francois: Exactly. The place where I've seen to your point, the most relevant feedback about integrations would be the HubSpot Marketplace and the Salesforce App Exchange, because that's where people tend to be a little bit more vocal about integrations. This is probably because reviewers understand the purpose of the marketplace itself, versus pulling reviews about your product from G2. Even then you might still get reviews about your product being a great product or a bad product. So, you cannot treat that as purely qualitative data, you need to get into the content of the reviews to really get a sense of what's going on.
Kelly: Yeah, that makes sense. So, as a more product focused partnerships person, do you have advice for partnerships people who are stuck in organizations where they really are strapped for product and engineering resources, and they have to sort of use the force of their personality and persuasion to get more resources that they need to meet their objectives? What can they do if the product team is not being told from high up that they need to give resources? Is there a way for partnership people to talk to product people under maybe terms or value propositions that are going to make a partnership person more successful when advocating for resources and buy in for assistance on integrations?
Francois: We the partnership people are always a little salesy. A lot of us actually have a sales background. So, we need to use that to our advantage, while being smooth as well and not too pushy. I think the conversation needs to start upstairs at the exec level to reveal the impact of integrations on the SaaS products. This is because even if your company doesn't really know what the play is for them, it's true for a lot of organizations. I've never talked to a SaaS company - and I've talked to many - that has done the homework and didn't find correlation between integrations and retention. Never.
We all have different flavors of it. I remember talking to some of our partners that were obsessed with driving adoption of integration as early as the first month of the customer journey. For that reason, they actually only cared about that timeframe. I've talked to companies that were measuring that through impact on the LTV and through impact on on retention. Whatever component of LTV. My preference is looking at active usage, because I really truly believe that the power of integrations is not so much in making a statement to the market that you integrate, but actually make it useful for your customers.
My advice would be to advocate against measuring setup, but instead measuring usage. Also, if you can get a friend on the data team to run the analysis, then it’s really easy because it should look good and it should look like you have an impact. Take it upstairs to your Chief Product Officer or CTO. Usually CTOs are friendly to APIs and ecosystem conversations like this. They may not necessarily have the resources to support, but they will advocate for it. Chief Product officers more and more come from companies that have had a strong ecosystem culture, so they will understand.
It's mostly the business people that need to understand this. For this reason you should not make it just a product conversation, and you should advocate that it's going to be good for retention. Customer experience people will be interested in that, because your sales and account managers lives and performance will be improved. With strong integrations, it will make for good selling points as well. So the sales team should be interested in that. It makes for excellent co-marketing conversations, so the marketing team should be happy to have lower lift programs that they can run and amplify through the audience of a partner.
It's really hard to find reasons not to do it, but it's also culturally too easy to say “let's do it” and not actually implement anything. So you need to just set up metrics and make yourself the owner of those metrics and accountable for those metrics. Say to your execs, “we're going to do this, and I need help from CS, I need help from marketing, from sales and product and engineering. If we do this together, and we’re aligned on the metrics, then the product metrics will be my metrics.”
Kelly: Yeah, that makes sense. How important do you think Developer Relations is in this? At what stage is it should this be implemented? Even if companies are not trying to become Salesforce, but instead a platform in their space, and have more people build on to them. Should companies they be hiring a developer relations person? How important is it to start that function, and what stage should that function be started?
Francois: I think as soon as you have an API that you may have built for internal reasons, but are starting to expose, you should have a developer relations person on board. It doesn't necessarily mean having a full time person, but at least have someone in the company with that mentality. It could be an engineer or a product owner, or it could be a sales engineer. You need to be able to lean on someone to talk about the API. When I joined Sendoso, we had an API, and we only had one partner building on it.
Within a year of just saying “the API is there, let's talk about it more” we launched two more in the last year, and we have about five or six that are being built actively right now. Because of that traction, we’re building awareness internally about it. Our engineering team that's building the product, knows about it and uses it to their own advantage as well. So it's a source of accelerated innovation internally.
Our sales engineers are more comfortable talking about our API to customers that might want to use the API as well. I wish we had a developer relations person, today we don't. We are hacking around it to provide that type of content to build code samples and things like that, and to list out the building blocks that we need to add to the product to make the developer experience nicer and smoother as well.
Better documentation, better code samples, better visibility. It might feel hard to justify that for certain business models. At Typeform it was a no brainer. We had between 50 when I joined and 100,000 customers when I left, and we had maybe 5000 developer apps registered on the platform. We had one Dev Rel person, but they turned out to be a rockstar. Actually having a small DevRel team might not be a nice thing for the DevRel person, but it's good for the product, because it forces you to obsess about the developer experience and make it as self serve as possible.
Self serve, in turn, attracts more people to actually think about building on it and creating a developer app using your API because they dont have to talk to someone to set up their API keys and sandbox and things like that. Typeform was a product that was naturally a good fit for that scaling without necessarily having a huge team.
That DevRel person was a Rockstar in that space. He also accelerated the pipeline for integrations and worked on so many other things like building proof of concepts for integrations. At Sendoso it might be a little early to have someone fully dedicated to that, but the mindset needs to be there and actually is here to build those code samples, and talk to developers as much as possible. This is one of the things that I'm focusing on right now. Our API is great, we just need to talk to someone to use it. We’re lucky because the level of demand is low. This gives me an excellent excuse to actually do my field research on the developer experience. Down the road, as we want to scale this, we will have to make it as self serve as possible.
Kelly: No, I think that's great advice. It can be a product person, or engineer, or someone else. As long as you have a resource paying attention to it. Then having the partnership person using that to get more information on what would make it scalable. So last question - Is there anything that you see tech partnerships leaders either doing or believing that you think is a mistake? Or is being approached the wrong way in the field? Or any advice that you would give out there to your peers?
Francois: It's a hard question to answer because it really depends on the context of your organization. What I'm doing now covers the same business KPIs and goals that I had at Typeform, but the way of doing it is radically different. The Typeform way would not have worked here and vice versa. What really matters is understanding why you're doing this and making sure that there is alignment across the organization, because it's not a mountain that you can move by yourself. This is true for partnerships in general. Even people dealing with agencies, they have that issue if their onboarding team, education team, and customer success team does not embrace the agency mindset. Then their job is really hard.
It's the same thing with technology partners. If your product team doesn't believe that integrations actually have a huge impact on retention, acquisition, or understanding your customers based on what they're doing with integration that's a problem. Learning more about your customers based on what they're doing with integration is a part of tech partnerships that's often overlooked. Look at what your customers are doing with the integrations and you'll learn more about what they actually do with the product. It really is very obvious in many cases, and not enough people do it. So, convey those three messages, showing data to back it up and build alignment with your whole exec team is really, really important here.
Kelly: Yeah, I think that's a great point. I love that idea of using it to better understand the customer's perspective on your own product. Tied to that a lot of times people don't realize that higher integration usage leads to higher product usage. So because you're in there using the integration, and it's providing new functionality, you end up discovering something else in the product that's related to it, but it's just in the product. Of course product teams love to see that. They're like "Oh, this is making customers actually use our product more," not just use the integration.
Francois: I was making that point actually yesterday in a meeting internally. When I was at Typeform, we saw one particular integration growing really fast at some point. It was with a platform that was 100% focused on e-commerce. We didn't really have e-commerce as one of our buyer personas or verticals that we were marketing to, but we actually discovered that it was a huge piece of our customer profile, by just looking at them using that integration. So much so that we realized we were missing something there.
Kelly: Thank you so much for joining us today and sharing all your expertise. Is there anywhere where people can reach you?
Francois: You can reach me on Linkedin, Partners@Sendoso.com, and Developers@Sendoso.com. I’m also in the SaaS Ecosystem Alliance, CSA, and Product Leaders slack group.
End
If you enjoyed the content, check out our Youtube channel for more and subscribe to our channel. If you're someone who is working on building and scaling SaaS product partnerships, we invite you to apply to be a member of our community and network with other leaders like Francois working on this at SaaSecosystemalliance.com.
