In partnership with The SaaS Ecosystem Alliance and Digital Bridge Partners, we hosted a discussion with product and tech ecosystem leaders at Duda, Procore, LeafLink, and Digital Bridge Partners.
Our CEO Cristina Flaschen spoke with Larry McDonough, Director of Product, Ecosystem at Procore Technologies, Justin Wells, Ecosystem Partnerships Manager at Duda, Andy Lauta, Partner and Consultant at Digital Bridge Partners, and Will Clifford, Director of Product, Integrations at LeafLink.
They shared why SaaS organizations should make building an integration ecosystem around their product a strategic priority, and what it takes internally to support the product organization in being ecosystem-first. Read about some of the conversation below, or watch the full recording here.
.jpeg)
Digital Bridge Partners supports high tech companies in optimizing their partner ecosystems, and Andy shared that they have developed a Go to Ecosystem Framework in support of this. The SaaS market’s continued growth and the success of individual SaaS players relies on an effective integration approach, which depends on product organization’s adoption of an Ecosystem-centric Mindset.
Andy further explained that this is because SaaS competition is fierce, and there is plenty of research that shows that companies that have better product ecosystem strategies are the companies that are more successful – they sell faster, they grow faster, they have greater lifetime value, customer activation, retention, and all the rest.
Justin explained that integrations are a strategic priority at Duda, because agencies rely on them to offer the best solution. They believed treating integrations as a strategic priority is part of upholding that promise.
Duda, as a web design platform, caters to agencies that are building websites for clients. Justin shared that they look at their ecosystem as a very curated experience for customers, being selective of who they bring in to solve unique use cases.
“Regardless of whoever's building the app integration– and we iframe a lot of our integrations and have a very robust API framework– if that experience is broken at any point of a users journey, they look at Duda,” Justin stated. “This is regardless if it's built by a partner or third-party. So, we really treat it as almost on an equal playing field as our product strategy. We want the agencies to feel confident that we're offering an ecosystem that has a rich experience.”
LeafLink is a wholesale platform for the Cannabis industry, and Will explained that in a flourishing industry like cannabis, there are many companies that pop up with specific offerings like CRM, point of sale, or ERP. Customers then have many different forms of technology thrown at them, and have to figure out how they will manage the implementation and data entry of that tech.
“By becoming a centralized marketplace, we can step in and say, ‘We're the solution for you, and we can talk to these other companies that you're working with and help you remove that double data entry.’ That's what's going to set us apart, help us gain customers, and retain them within the ecosystem.” - Will Clifford,Director of Product - Integrations at LeafLink.
Will further explained that when SaaS companies establish this connection between other apps in their ecosystem, it becomes more difficult for customers to hop between systems because of the benefits from being on your platform.
“If you think your product is going to be the only system that solves all of a business’ problems, that’s not the right mindset,” Will said. “You’ll have what you do really well, and then you want to find the right technology partners that do other things well so that you can work together to make a better experience for your joint customer.”
Larry from Procore shared that he has seen tech stacks getting more and more technically complex when it comes to SaaS, pointing out that customers are now expecting the different software products they use to work together.
“From a customer perspective, they really need everything in their tech stack to work together,” Larry said. “And so, if you focus as a company on your stack alone, and just the set of partners you have, and not on the larger problem that customers are trying to solve, then you're going to miss out on additional routes to market.”
Our CEO and moderator of the discussion, Cristina Flaschen, started working in tech over 15 years ago, and recounted that the impulse then was to build what the customer asked for, even if wasn’t your core competency.
Since then, she has appreciated the transition into highly specialized pieces of software that do a handful of things well and operate in a composable stack that works best for their specific needs.
Related Content: Uncovering The Power of Partner Operations: Tools, Strategies, and Advocacy
Justin explained that there can situations where a product feature that is on the product roadmap could be solved with an integration. In a situation like this, the product organization may want hold on to the space for that feature, for example, if they want it to be a native and a core experience of the platform – even if it may be two years out in the backlog.
In this case, Justin explained that organizations have to remember that customers want things now, and SaaS companies can't say that it's going to take, for example, two years to offer a feature.
“One way I would get buy-in as a partnerships manager is by suggesting that we execute on an integration and find learnings from it,” Justin explains. “For example, we can learn more about how customers are using that product, and what features they actively use. It almost gives you a litmus test to the features that are on your roadmap.”
He further added that this approach can help product teams gain better insight into what they’re going to build because they’re able to learn and iterate on that.
Larry made the point that If product management is done well, PMs should be identifying within their own organization what is part of their core competencies and what isn’t. By defining this they decide what they’re not going to deliver.
“Good product organizations identify what they're not going to do, and enable others to do it well for their customer. If customers need a feature, but it’s not part of your product's core competencies, then you should enable it somehow. Otherwise, you're being irresponsible to your customers, and you're leaving money on the table.” - Larry McDonough, Director of Product, Ecosystem at Procore Technologies
Larry went on further to explain that product organizations can do this by building or extending their API's in such a way that enable partner integrations to take a product to the next level. He mentioned that this is an area where he sees many product teams often fail, including in his own experience as a PM.
He empathized as someone who works in product, that it can be easy to get sucked into your own deliverables. He furthered Justin’s earlier point by suggesting there is space left open on product roadmaps for potential integrations.
Andy then brought up the challenge of resources when you have a diverse set of customers that likely have diverse needs. In cases like this, he recommended to guard against getting sucked into the morass of all the different integrations that individual customers want.
He built on Larry’s point about defining what a product will and will not deliver, and suggested balancing your product and engineering resources based on this. For example, determining the top critical strategic integrations you need your product team to take ownership of, and what are the integrations that you can let go of and let your ecosystem or solution provider build for you.
To demonstrate the importance of integrations, Larry shared that one of the most compelling metric to show the product org is the correlation between integrations and retention rates.
“In my experience the most compelling metric to show to your product team is that there is significant higher retention for customers leveraging integrations. I think if everyone looks they’re going to find that. Business listens to retention.” - Larry McDonough, Director of Product, Ecosystem at Procore Technologies
Will added to Larry’s point by bringing up the importance investing in building API capabilities and accurate documentation that will allow SaaS companies to more easily scale operations and reduce churn.
“As companies grow, they're going to look for efficiencies, because they're continuing to inherit new technology. Along with having key integrations your company owns, you want an extensive base layer of APIs with accurate documentation to extends all the capabilities you want to enable via API,” Will shared. “For example, if you're placing 10 orders a week, and then jump to placing 1000, you're going to want to automate that through API's. If you're not ready with that connectivity on your end, that's where you could start to encounter churn risks.”
When product teams are building a feature, Will suggested that they ask themselves: How is this feature gonna be used by our customers? By our biggest customer? By our smallest customer? How will the feature be used by the emerging growth markets?
He added that oftentimes when a first version of a feature is built within the UI of a product or on a platform, there may quickly need to be integration capability. Tthat is something he often sees being missed.
“You can built out this amazing platform, but if you can't communicate with it digitally through an API, then you're going to run into requests that come up from strategic customers. They're going to ask 'Why can’t I automate this?' and so on.” - Will Clifford, Director of Product, Integrations at LeafLink.
Andy added onto Will’s point by describing a best practice he called “Solutioning”. He defines a solution in this case to be “A combination of a specific customer, or customer segment, and a use case.”
In order to implement this approach, he suggested to first identify the customer segments that a product has, and to be clear on how one’s customer base is segmented. He used the example of the cannabis industry, and how that customer base is likely segmented by state because the legal implications of selling cannabis in each state is different.
He went on to suggest not only segmenting customers, but also segmenting use cases.
“You want to define customer segments and also segment use cases, because as your solution or platform expands, you're going to be enabling multiple use cases; However, different use cases are going to bring into play different products that you need to integrate with,” Andy shared. “And so, you want an understanding of what are the ‘solutions’, ie customer segments and use cases, that are your highest priority.”
For smaller SaaS companies especially, he suggested focusing on one to three integrations in-house, and then beyond that, prioritize and work with their ecosystem to provide integration solutions. This would require, however, that they have a robust API and developer support.
As a best practice for partnerships managers, Justin advised that they work closely with product managers to run their ecosystem roadmap side by side with the product roadmap. To explain further, he stressed the importance of ingraining himself in processes that allow him to be aware of what is being released, what feedback the product team is hearing from customers, and what the development team wants build.
By looking at both the ecosystem roadmap and the product roadmap side by side, Justin shared that this allows him to know what's coming next from the product standpoint, and gives him the opportunity to find things in the market that the product team might not be looking for. Then, they can work together to prioritize features we know will be requested.
“Together we’re then able to decide how much development or other resources this will take. Sometimes, we might have a solution in mind that fits our highest strategic partner, but it’s not a solution for the long tail,” Justin said. “In this case, maybe we launch a feature and launch an integration at the same time and message those differently. At the end of the day, we’re providing a solution to the customer.”
“The more I can be ingrained in what our product team is doing, and the more they know what I'm looking at in terms of ecosystem strategy, the the better the outcome is going to be overall.” - Justin Wells, Ecosystem Partnerships Manager at Duda
Larry weighed in, sharing that a common misstep he has noticed is when product teams build APIs and release them for third party use without thinking of the API as a separate product with different use cases by user.
“A common mistake on the API side is when you release some APIs that enable a third-party to build what you have already built. That's not what they're trying to do. They're trying to build something that extends from your product,” Larry said. “For example, you might be building something that allows users to create and enter data in a form, but a third party might want to do something automated with this with maybe have 1000 users. Therefore, your API will have to be able to not just handle submitting one form at a time, and instead, have batch processing capabilities . If you don't think of the API as a separate product, with different use cases, then you're going to stumble there.”
Related Content: How To Build an Ecosystem First Product Organization
When thinking about the breadth and depth of integrations, Justin stated that he never sees this as a “either/or” decision, but instead tries to implement both approaches. He continued by saying that depth of integrations offered is especially necessary.
He also built on Larry’s earlier point about the importance of developing APIs as a product with different use cases, and how this can allow for future integrations to have more depth because of an already established foundation. He also suggested bringing in third parties for simpler use cases, or to alleviate development resources.
Andy agreed with Justin’s point, and stressed the importance of providing the functionality that SaaS customers need when it comes to top priority, strategic integrations. He then brought up the struggle of resources, stating that all of this comes down to the resources that are available for internal development, supporting APIs, and external developers.
Will also provided some best practices for addressing requests for new functionality being added to integrations. He suggested treating the integrations and these requests like any other product.
“For example you can have a customer screen share virtually to understand what they're doing day to day. Just like you would on any kind of like UX/UI update,” Will shared. "You can potentially step in and say ‘I noticed you're doing these three things. We can adjust it in this way, not necessarily what you requested, but in a way that’s better for you potentially.’ Then you get the win of enhancing your integration for your wide scope of customers, but also meeting their needs.”
As for customer concerns over the robustness of integrations, Larry stated that he has certainly seen that interest coming from customers. He also expressed the lack of trust customers may have in the functionality of integrations when they are asked to install integrations to a product using third-party platforms.
“As always is the case with partners, and customers, it's really about trust. No matter who the integration is built by, they're going to call you when something goes wrong. So, you want to do everything you can to make sure that you have high quality, well tested, well validated integrations.” - Larry McDonough, Director of Product, Ecosystem at Procore Technologies
He also stressed not only vetting integration use cases, but customer support use cases. This is because, especially in the current age of social media, word gets out quick when certain software is not working well.
The panelist then continued the conversation to talk about advice for gathering data to determine integration use cases, and specifically how to analyze the relationship between integration adoption and retention and churn.
If you're interested in hearing the full discussion, watch the full recording here, and apply to become a member of the SaaS Ecosystem Alliance to network with 1100+ product, partnerships, and engineering leaders working on building SaaS ecosystems.
