The Ecosystem-Led Product: Architecting Integration Density and the Network Moat
By Sebastian Hoelzl,
Most B2B SaaS companies ask their partner teams to bring integration ideas to product. That model produces the wrong integrations, built badly, used rarely. There is a better way to structure the conversation.
The average B2B SaaS company treats the partner team as an internal customer of the product function. The partner team submits requests. Product reviews them. Something gets built. Months later, the integration sits largely unused and nobody quite knows why. Agata Bugaj, Chief Product Officer at ButterflyMX, has seen this play out repeatedly across her career spanning FullStory, The Home Depot, and Bain and Company. Her answer is not a new process. It is a different model for how the two functions relate to each other from the start.
The argument for bidirectional collaboration
The common framing puts product in the role of gatekeeper and the partner team in the role of advocate. Partner teams bring lists of requested integrations. Product teams triage them against roadmap capacity. The result is a negotiation rather than a discovery.
Bugaj argues for something different. The partner team should not arrive at the product conversation with a list of integrations to defend. It should arrive with a commercial question: what underlying value would this integration create for the end user, and how do we know? That shift changes the entire dynamic. Instead of product evaluating whether an integration is worth building, both functions investigate together whether the value is real before any build decision gets made.
This matters because the wrong integrations are expensive in more ways than one. They consume engineering capacity, create ongoing maintenance obligations, and produce the kind of customer experience that quietly erodes retention rather than building it. The partner team that validates value before advocating for a build is a more credible commercial partner to product, and a more effective one for the external partner too.
How to choose the right partner when the options are imperfect
One of the more counterintuitive points from this conversation is that market breadth is not the most important selection criterion when choosing which partners to work with. A larger partner with wider reach sounds like the obvious choice. In practice, if that partner is slow to prioritise the integration, difficult to coordinate with technically, or unwilling to commit internal resources, the integration will stall or ship in a degraded state.
The conversation surfaced a cleaner selection framework. Internal relationships matter. The partner’s willingness to prioritise the integration from their side matters. The quality of the working relationship between the two engineering teams matters. A smaller partner that moves with speed and genuine commitment will often generate more commercial value than a larger partner that treats the integration as a low-priority side project.
This shifts the evaluation from a market coverage question to an execution quality question. The partner who is hard to work with is not just an operational inconvenience. They represent a risk to the end user experience and, by extension, to retention.
And according to Agata, “clarity is kindness” in partnerships. Teams should quickly identify if a partnership is feasible and viable; if a potential partner is non-committal or difficult to engage, it is often better to move on.
What happens when product asks a hard question
The conversation reframes how partner teams should interpret pushback from product. When a product manager asks a difficult question about an integration, that is not resistance. It is engagement. It means the product team is taking the proposal seriously enough to pressure-test it.
The commercial implication is significant. Partner teams that treat these questions as obstacles to manage are less effective than teams that treat them as an invitation to go deeper on the evidence. Answering thoroughly, with data on end-user value and commercial outcomes, is how trust between the two functions gets built. It also means that when product does say no, or redirects the effort toward a different integration, the partner team has enough shared context to understand why and to use that knowledge next time.
In fact, according to Agata, one of the most overrated, and often misleading, metrics used by product teams is tracking the number of customers using a feature or integration. She argued that while this metric indicates the quality of distribution, it often fails to measure whether the product is effective or provides actual value to the user.
Ultimately, accepting a no is not a failure. It is a signal that the process worked. An integration that should not be built not getting built is a better outcome than one that gets built because nobody asked hard enough questions.
The commercial case for getting this right
Partner teams that operate as advocates, and product teams that operate as gatekeepers, are both working from the wrong model. The function that creates durable revenue is the one where both sides investigate value together, choose partners based on execution quality rather than logo size, and treat every hard question from the other side as a reason to go deeper rather than to retreat.
Chapters
- Introduction and guest background
- The case against the isolated product roadmap
- How to decide which integrations actually belong on the roadmap
- Structuring the relationship between product, engineering, and partner teams
- Choosing the right partner when the options are imperfect
- Why a no from product is sometimes the right commercial outcome
- Rapid fire and closing thoughts
⭐️ Leave a Review: If you enjoyed this episode, please follow Ecosystem Alpha on Spotify and leave us a 5-star review! It helps us bring more incredible guests onto the show.
