This conversation is transcribed from our podcast Between Product and Partnerships, a podcast brought to you by our group the SaaS Ecosystem Alliance. It’s focused on bringing together product, partnerships, partner marketing 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 a link to listen on podcast platforms here.
Rachel: I’ll have been at Unanet for two years in October. I've been working with technology partnerships specifically for about 5 years and in partnerships in general for about the last 15. I've done channel services and strategic partnerships, but I always come back to Technology Partnerships, they are my favorites. I was on a call earlier today with a potential partner and he said, “I kind of sometimes think that my software is boring”.
What technology partnerships are doing, especially the integrations they build, that's the really cool stuff.
I get really excited and geeked out when we start talking about technology partnerships. A little bit about me, I'm a mom of a toddler, so my life is a bit chaotic right now. I'm also from Iowa. I just came back from a five day holiday to Iowa to see my family.
So sometimes you'll hear me come out with some very, very Midwest phrases. It's just due to my Iowa background and never leaving home.
Liz: I totally agree with you. I don't specifically work in tech partnerships but a huge part of my role is learning about them and writing about them. How software can collaborate with one another and those joint use cases is really interesting for me also.
You definitely have a lot of experience in building out tech partner programs, and you had mentioned to me before that you're currently leading your program in transformational change. I wanted to ask you about something you mentioned in the last panel that you were on with us. You previously said when you initially joined Unanet, you realized that there were a lot of barriers to entry for tech partners, specifically when it came to building, accessing, and deploying integrations.
Rachel: I'll give you a little bit of background on Unanet before I jump into the question. Unanet is a software company that has three distinct product lines. The first one is a gov con ERP, an ERP specifically focused on government contractors. That is something that we built from the ground floor. It started out as a time entry software, we just built it out to full ERP. Then because of acquisition, we brought on two other software platforms.
One being another ERP that is focused on project-based engineering and architecture. So these are customers that don't build buildings, they design the buildings. We acquired that company about three years ago. We also acquired a company two years ago in October that is a CRM platform for the construction industry.
That’s important because when you have three distinct product lines, that’s three distinct code bases, three distinct API maturity models, and three distinct processes. Sometimes processes are very difficult to break, remold, and retool. As we were building our own integrations, we found that we had very high barriers of entry for new partners who wanted to build to us.
What I mean by that is that processes across product lines were not the same. Getting a sandbox for a partner for gov con or for AE or for CRM was completely different. API maturity, completely different.
What we've really started to do and figure out is how to streamline that. How do we make it very simple for our teams to create sandboxes? How do we make it very simple for our partners to get access to resources rather than emailing 10 different points of contact? Can we be as simple as creating one email distribution list that covers all three product lines?
We're really trying to lower the barrier of entry, remove obstacles, and make things a much more clean process, which is really what technology partnerships are about. They're about working through a process and workflows.
Rachel: When I first started out at Unanet, I reported to our Director of Partner Success who then reported to our Chief Revenue Officer. I think for onboarding and being able to understand the lay of the land here at Unanet, that made a lot of sense, she was able to get me a lot of the direction I needed in order to set the stage for success.
Technology partners are very much different than referral partner, services partner, etc.
We found that when you start looking at technology partners, they are much different than our referral partner, services partner, etc. They need various special access points enabled, they need access to sandboxes, they need access to API endpoints, they need access to product people, and they need to understand the roadmap.
I also realized that my ability to be a change agent and be a great advocate for our technology partners was also not strong because I reported very low into the ranks of Unanet. I used a lot of the messaging that you'll see in blogs from Crossbeam, about how the closer you are aligned to the C-suite, the better off you're going to be.
I drafted a proposal and made a pitch to have me moved over to product, where I report now directly to the Chief Product Officer, which is important because that gives me a seat at the table. It gives every one of our technology partners a seat at the table as well.
They now have access to the roadmap, rather than our team building functionality. I can now say very quickly before they build, “Hey, we've got a partner who does exactly that functionality. Why don't we integrate with them versus us taking the time to build something else that will be important to our client base or customer base?” It's really been a great move for me, in being able to be an advocate for our partners within the product team.
Related Content: Uncovering The Power of Partner Operations: Tools, Strategies, and Advocacy
A sales leader and a product leader are going to evaluate technology partners very differently.
Rachel: A sales leader is going to look at technology partnerships through the lens of “How many leads, can you bring me? How many referrals can you bring me?” Looking at that, both internally and externally, when I've worked at Unanet and seen other examples, we made some mistakes.
The mistakes we made were that we brought on a couple of partners, because they could bring us leads, but their core functionality was in direct competition to core functionality that we had either released or we were going to release.
Those are probably not the kind of partners that you want within your portfolio. That was a clear indication that our reporting structures were a bit misaligned.
Product looks at things differently. They look at parts of our functionality that they're not going to build themselves. They want to look at technology partners that will really delight our customers and expand our product option. Or they want to look at technology partners that will become a pivotal integration that makes our customers more sticky.
All three of those things are important. All three of those are important KPIs to track. All three of those will eventually lead to bottom line revenue. Bottom line revenue is not the number one driver when you report into product.
It's really important that if you're trying to make a pitch to report into a different section of your organization you figure out why you have a technology partner program, and how you're evaluating your technology partner program. Make sure that you are reporting into where the alignment makes sense.
Liz: You mentioned that you're building most of these workflows internally. and there wasn't the choice to go with a partner portal specifically for tech partners.
Rachel: I see a lot of posts, blogs, and information about partner portals. I think partner portals are a valuable resource when you're looking at referral and channel type of partners. The typical selling channel within an organization.
Partner portals are like taking a square peg and putting it through a round hole when you're talking about technology partnerships.
Technology partnerships processes are all about onboarding, enablement, and go-to-market strategies.
It's not about referrals and co-branded marketing material, which is typically in the selling channel.
We did a lot of research in regards to portals and what we're finding is that the portals that are out there today would have to have a lot of configuration, adjusting, and a customization that would be required to make them work for a technology partner program to manage the workflows.
When we talk about technology partners, we're talking about workflows around how do you build the integration? How do you enable your sales team with the integration? How do you build the go-to-market? How do you enable support? How do you enable implementation?
All these different steps that just couldn't be accommodated in the standard portals that you see in the market. We've gone out and we've built our own workflows using various tools, Monday.com being my favorite.
We've gone through and we've built out some pretty extensive templates and workflows that really worked for us. It is something that our product team is very familiar with. Our partners are very familiar with it, they have access to it, and can see what's going on.
These workflows and templates have become our basis for any of our standard or sync calls. We can go through and say where we are with certain tasks, are they finished, Is is stuck or behind, etc. It's become a really great conversation piece and agenda topic.
As we go through sync calls, it also works really well when we're talking to our product team. I can say to product, “Look, these are the five things that are stuck, three of them that are stuck are on our side, and our partners can't move an integration forward until you move them out of the way for me. How do we accomplish this? How do we get this API developed faster for them?” So it really becomes a great talking point.
I think partner portals are great for the selling channel of the partner programs. Technology partners, we're very unique, we're very specialized, and we're very process project management based.
Liz: You mentioned Monday.com is a tool that you've used.
Rachel: Monday.com has worked really well for us. So internally here at Unanet, our product team uses Jira, and Confluence, both pretty standard in their industries. Our CRM tool is Salesforce, pretty standard in the market, but our product team doesn't have access to Salesforce, and I'm not a big JIRA person. We needed to find a tool that was easy to use. Monday.com is super simple.
I am not a technologist by training. I'm a partner manager. I don't know bits and bytes, but I know how to build workflows. Monday.com was a really easy place for us to start, it was a familiar tool and licensing was relatively inexpensive. If I wanted to bring a partner into it to use it as well, the case can be made for doing that.
There's plenty of other workflow tools out there. That just happened to be where we landed, because it's something that we were already using internally at Unanet. I had a lot of subject matter experts who could help me build it out.
We have Monday.com, but we also have that integrated into Slack. When I have a partner submit a ticket, it notifies me in Slack and I know to go check that ticket. We use Monday.com not just for the templates of a workflow, but we also use it for submitting tickets.
For example, I'm a technology partner building an integration and I've got a question about the API. Well, rather than that question being lost in the email world, you can now go to Monday.com, submit a ticket, that goes right to our teams, and they can start processing.
If you have a marketing question, a customer needs access to the API, that all goes through a Monday.com form and we can start processing the processing on our side a bit more efficiently.
Liz: That’s some really great tactical advice. It's interesting, I've read a lot and done a few interviews, and I haven't heard anyone mention Monday.com. It's interesting hearing how you're using it to collaborate with product.
Rachel: To be fair, when I started and I was only managing five to ten partners, I could do a lot of this in Excel and OneNote.
You start to scale and you realize those manual processes don't scale with you very easily.
With Monday.com, or other workflow tools out there, I can build dashboards. When I speak to our Chief Product Officer and he asks me, “Rachel, how many partners are stuck with this topic?” I can tell him right away. Or, “How many partners do we have with our CRM platform?” I can tell him right away.
Being able to create dashboards that roll up from my templates and creates easy access to information is really helpful.
Related Content: What are SaaS Integration Partnerships? All Your FAQs Answered
Rachel: Unanet is not as advanced as some organizations are in the reporting of KPIs. To give some history, Unanet launched our Connect platform in July of 2020. We're just two years into it. When you're building out this marketplace, I think you have two goals in mind: one, how do you get a lot of logos on your website? Two, how do you make sure that those logos and integrations are being used and not just sitting on a shelf?
What we’ve focus the last two years on building out the marketplace, building out our logos, building out our integrations, and building our processes. While I can tell you how much revenue we have made off of those integrations, it's not a KPI where we are evaluated today.
Do I think that's going to change at some point in time? Yes. Really, what we're looking at though, is not just how much revenue has come from those integrations. We're looking at how many integrations do we have per customer? Is it one, two, or three? How many customers are actually actively using the integration?
I don't know if we'll ever get to the point where we are evaluating based on dollars. We're really going to be focusing on usage, because when we start seeing high usage that may tell us when you have other partners in the same vertical. Or if we don't have a lot of usage, either A, we haven't done a great marketing strategy, or B, we hitched our wagon to the wrong horse and this is not an integration where our customers find value.
Revenue is great, but we're really focused on the usage and how many integrations our customers are using.
We want to get to the point where every single customer has one integration, especially in our ERP platforms. When we get to that point, then we can start working on what we want to get to two. Do we want to be 75% using two?
Anecdotally, we all know the more integrations your customers are using, the less likely they are to lift and shift and go somewhere else. The retention becomes really, really high.
I don't know if anybody's figured out what that magical number is. We just know that we need to get to one, then we get to two, and then we'll get to three.
Liz: We actually had a panel with Larry McDonough from Procore, and he mentioned that for every organization it is different. It's just about finding that sweet spot, based on where your company is, what vertical you lie in, etc. It's about seeing that relationship between how retention and churn changes as more integrations are adopted by users.
Rachel: We partner with Procore, I know them very well and I know that messaging and they presented about that last year I believe at their virtual Partner Summit.
That's information that we picked up on here at Unanet, because we were trying to figure out how to evaluate our technology partner program. Is it based just on the revenue? We realized this is the first time we heard it presented that way.
Revenue was great, but the cost of acquiring new customers was so high, we wanted to make them as sticky as possible.
We really pegged on what the Procore team is putting out there about multiple integrations being in place, not just one, but to have multiple integrations per customer.
Liz: When it comes to identifying integrations that would fill gaps or expand product usage, etc? Have you ever had instances where there's a conversation of whether there should be an integration versus things being built? How do those conversations usually go?
Rachel: There's one of two reasons why we're building an integration. One, we know the integration is going to be high value, no matter if we have a customer asking for it or not. A good example of that is payroll. When we started looking at ERPs, and our main product lines are two ERPs, having an integration to payroll platforms like ADP, Paylocity, UKG, those are table stakes.
If you're an ERP, and you do not have integrations to payroll, you are losing a ton of business. We know that payroll is very important to our customers. Right now we have integrations of 14 different payroll platforms.
When it comes to other things that we integrate with or built, we have internal and external portals where our customers and internal resources can submit suggestions for integrations. For example, we should be integrating with a tax platform or we should be integrating with a bill-pay type platform. When we start to see a groundswell of requests for the same thing, then our product team will take the initiative to really start investigating it.
When potential partners reach out to us the evaluation is a bit different. When they reach out to us we're looking at things like Crossbeam or account mapping. Are there some natural overlaps? Are there customers who are already using both of our products> We want to work with partners that are bringing to the table two or three customers that they know are already asking for this integration.
We are heavily involved with our product management team. The reason we do that is twofold.
One is We want to have really deep conversations with a potential partner to make sure what they are doing is does not compete with functionality we already have or what's coming down the pike. That is something only our product managers know for one.
Two, we want our product managers involved because they know our product better than anybody. We want to make sure that they are providing good counsel to our technology partners in order to build an integration that we know will cover everybody.
What gets really frustrating is when technology partners build things in a silo and they build something they think customers will like. Then they realize that every customer likes this, plus about five other things and they're constantly customizing it. We have definitely made some mistakes where partners were building in silos and released it, and nobody wanted it.
We've realized that we need to have our product managers work in conjunction with our tech partners, so that we build high-class wanted/usable integrations that they are then putting out to market.
We really believe in having a true partnership. I have seen too many technology partnerships fail, where one side is doing the build the go to market, the sales, everything. There's a term that someone put on LinkedIn about being an orphan tech partner. When you're doing things on your own, you definitely feel like you're orphaned. For partners that are really our size in base, we try to do this as a true partnership where we're doing it all together.
Rachel: We haven't implemented anything specific. I think that what has happened is that we have a Chief Product Officer, Assad, who I report in to, who really believes in the value of technology partnerships.
They really understand that for their product managers to become incredible product leaders, they also need to see the value of technology partnerships as a throughput to get more functionality and remove some burden from their teams.
For us, It's not about process, it's about executive buy-in. If we didn't have the buy in from our Chief Product Officer, I don't think that we would be as successful as we are today in removing barriers and making processes more simplified.
Rachel: Demo demo demo. I can't hit on this enough. When we are getting ready to put a lot of focus on a technology partner, we really encourage them to have at least bi-weekly, sometimes weekly, sync calls with our product team. This is so that they can be with them every step of the way. We tell our partners right away, “Hey, you're going down the wrong path with us. This is not an efficient integration that you're building. Let us show you how you can build it more efficiently.”
What we see too many times is that partners start building and then we don't talk to each other until it's done. When it's done, it's too late to change it.
We really want to have those conversations with tech partners throughout the integration process.
We really want to have those conversations with tech partners throughout the integration process so we can help them pivot if need be, or understand very quickly, what they're missing in our functionality that we need to get into our roadmap right away.
We use Workato for some of our integrations as our iPaaS. I didn't realize the level of effort it takes to get a piece of functionality into your Workato, or whatever iPaaS, into your connector. It requires the functionality being added to your product, and the API being built, then the functionality being added to your connector. For Unanet those are three different teams, three different sprints or more.
We need to know right away, that we are missing something on our side, because we know it will take some time to get it to you. That's why it's important for us that we are with you every step of the way and not saying, “Here's all your resources, we'll see when you're done.” That's why those sync calls become really important to us.
Liz: Are the partners also on the Monday.com platform as well?
Rachel: We're starting to bring some onto that right now. We have partners that have read access to it, and we have some partners that will be having edit access to it. But yes, to answer your question, yes, our partners are getting access to our workflows and getting access to Monday.com.
Rachel: One of the challenges that every technology partner manager has is that I think we are afraid to say the word "no." Sometimes when we have a potential technology partner come across our desk and we're evaluating it, when our gut tells us no, we're a bit nervous to say no.
Because there's a what-if. I think that as technology partner managers, no matter where it is in your career, it's really important that you feel empowered to say no, and be able to document what you've said. I've seen some really bad partnerships out there because a technology partner manager was afraid to say no, because of the what-if.
If there's a what-if out there, they will come back. We've had a couple of tech partners that we've said no to because it was not the right time. They've come back to us six-nine months later, and it was the right time.
Liz: Thank you so much. This was great.
If you enjoyed this interview, check out our Youtube channel and subscribe for more content on all things APIs, integrations, and technology partnerships. 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 Rachel working on this at SaaSecosystemalliance.com.
.png)