Webinar: Cybersecurity Integrations: The ROI Black Hole

A Fireside Chat with Doug Cahill, Independent Industry Analyst

Published by Synqly • Hosted by Richard Melick, Head of Marketing, Synqly

Download the report “The State of Cybersecurity Integrations 2026”

TL;DR

Cybersecurity vendors are losing renewal revenue and slowing deal cycles because integrations are treated as a tactical checkbox instead of a strategic product capability. The “ROI black hole” opens when vendors can’t see how customers use their integrations or tie them to revenue. The fix: treat integrations like a real product, with a lifecycle, usage metrics, pricing attribution, and dedicated go-to-market investment.

Executive Summary

This fireside chat unpacks new research from independent industry analyst Doug Cahill, based on interviews with product leaders, mostly Chief Product Officers, with engineering leads, alliances leads, and a couple of CEOs, across startups through large-cap cybersecurity vendors. The conversation covers why integrations have moved from “nice to have” to table stakes in buyer decisions, why the industry keeps falling into an ROI black hole where integration value can’t be measured, the mixed reception of the OCSF standard, how vendors should prioritize tactical deal-driven integrations versus strategic roadmap bets, and the biggest mistakes experienced leaders have seen early-stage companies make.

Cahill’s throughline: buyers don’t want one platform to rule them all, they want “many platforms of value” that are open, interoperable, and backed by a visible ecosystem of third-party integrations. Vendors who can prove that commitment, with discoverable integrations, clear customer-value metrics, and disciplined focus on their ICP, win renewals, expansion, and pipeline.

5 Key Takeaways

1. Integrations are table stakes, not features. Buyers assess your integration ecosystem before they’ll sign, especially in cloud security. A visible partner page, data sheets, and implementation guides signal commitment. First-in-category integrations trigger a wait-and-see POC; second-in-category integrations move faster when you have a track record.
2. The ROI black hole comes from missing metrics. If you can’t see which customers use which integrations, and you can’t attribute ARR to them, you can’t defend them at renewal or justify the next round of investment. Visibility + pricing/packaging + feature discoverability is the formula for closing the gap.
3. Standards only work when vendors actually commit. OCSF has real promise to normalize cybersecurity data, but adoption is uneven, some vendors would rather keep all the data (and revenue) to themselves. Treat standards like a product, not a press release, or they stall in the “sea of despair” between hype and maturity.
4. Platform consolidation and best-of-breed are both true. Enterprises run 80–120 security controls and want to consolidate, but they also want optionality. The winning posture is an open platform with a strong third-party ecosystem, what one ESG colleague called “many platforms of value.”
5. Focus beats opportunism, especially for startups. The most common fatal mistake is taking a one-off deal that bends the product away from your ICP. A “yes” to an out-of-strategy integration is a “no” to focus, and it sets false expectations with the board. Leave some of the market for the rest of the ecosystem.

Introduction

Section summary: Host Richard Melick (Synqly) introduces analyst Doug Cahill and discloses Doug’s advisory role with Synqly, while emphasizing that the underlying research was run independently, with Synqly blind to the interviews and data.

Richard Melick: My name is Richard Melick. I’m the head of marketing here at Synqly and the MC of this conversation. I get to put on my journalist hat, which I am a journalist, and have this kind of conversation. It’s really fun to flex on this side.

To my proverbial right is the always wonderful Doug Cahill. Doug, please say hello to the beautiful people.

Doug Cahill: Well, thanks, Richard. My name’s Doug Cahill. I’m in that nebulous sort of semi-retirement stage. For me, that means that in addition to coaching a high school tennis team, I’m an independent industry analyst, still connected to the cybersecurity industry, working on topics such as the one we’re going to discuss today. Previously, I was an industry analyst working for the Enterprise Strategy Group and then TechTarget. I covered cybersecurity areas such as cloud security, data and access management, endpoint security, data security, and this notion of platforms. Prior to that, I was at a couple of cybersecurity vendors, early-stage companies. I was at Threat Stack, an early cloud security company, and before that Bit9, which then became Carbon Black, where I had various roles related to integrations that I’ll reference as we move along.

Richard Melick: You know, you have a small pedigree of experience there, Doug. I love the fact that you’re semi-retired. Now, we must address one thing. Doug is an advisor for Synqly. So he does do some work for us as part of that relationship. That said, the report that he produced for us is probably the most hands-off I’ve ever had in a report. We came up with the idea and built up the concept with Doug, but Doug ran it. We helped with introductions to people, but Doug did the questions. We didn’t see the data. We didn’t manipulate any of the results at the end. It’s actually one of the more seamless analyst reports. It felt very much like working with Doug Cahill, analyst relations manager, more so than anything else. So despite Doug being an advisor for Synqly, this report is very independent of our voice and our words. Our editing was very minimal, which led to quite a few arguments about commas and conjunctions.

What Sparked the Research

Section summary: Why Doug wanted to revisit integration dynamics in 2026: how vendors position along the feature/product/platform continuum, how organizations consolidate tools and teams, and the full lifecycle of an integration from user story to deprecation.

Richard Melick: You’ve been tracking integration pains in cybersecurity, both as an analyst for over a decade with ESG, as well as having roles at ThreatStack and Bit9. You’ve watched hundreds of organizations come and go, grow, change. When you sat down to really focus on this research, what were you most curious about? How has the environment changed from when you were very active to today?

Doug Cahill: There were a number of things I was interested in revisiting and learning how vendors are thinking about this topic. I’ll start with this notion of how vendors position along the feature, product, platform continuum. I know from my experience in some early stage companies when we thought we had a product, but we really had a feature. We certainly weren’t a platform. And we leveraged integrations to position ourselves in the market as a little bigger and more relevant than perhaps we were.

For example, when I was in the endpoint security market, we integrated with a number of the SIEM vendors, leveraging syslog and CEF as a data format to propagate our alerts up into those SIEMs. We were selling to the enterprise, which was an upmarket play. We were selling to enterprises that had a stack of sophisticated security controls. So it was important for us to participate in their broader cybersecurity stack, which always included a SIEM. We also integrated with software distribution, like McAfee EPO back in the day.

Later in my career, I was at a cloud security company. Early on, DevOps was even a new methodology. It was important for us to integrate not just with other cybersecurity controls, but actually with the DevOps toolchain. A very key influencer in our sales cycle was the DevOps team. So we had to show up in Jira. You had to integrate with the tools that the DevOps team used and were fond of, but also convey the fact, via joint marketing, your website, and so forth, that you were integrated into the DevOps stack as well as the security stack.

As an industry analyst, I started to do market research around this notion of consolidation broadly. It wasn’t just about platforms and consolidating from eighty to one hundred tools to a smaller number of tools. It was also organizational consolidation. In cloud security, for example, we found early on that there were separate teams using separate controls to secure separate environments. That meant there was very little coordination when you wanted to reduce mean time to detection and response, as well as operational inefficiency by using all those controls.

I was also interested in organizational dynamics. When an integration candidate comes in, where does it come from? How is it vetted? How is it prioritized? How is it implemented? What’s that implementation experience like? Do organizations proactively promote those integrations so they can monetize them? What’s the go-to-market dimension? For me, that was all about the lifecycle of an integration: from a requirement for which there may be a user story written, to establishing a partnership with a third party, doing the implementation, managing the implementation, making sure you’ve got customer success, evolving that integration across good, better, best capabilities, promoting it in the market, and maybe it deprecates over time.

So I was excited about the project because a lot of these dynamics were familiar to me from my experience. But it was great to talk to so many product leaders. When we say product leaders, we’re talking about mostly CPOs, but also engineering leads, business development alliance leads, and I think we had one or two CEOs. And we had small companies, medium companies, large companies. So we had a really good spectrum of participants.

The Integrations ROI Black Hole: What It Is and Why It Matters

Section summary: Where the black hole comes from: missing customer-usage visibility, pricing/packaging gaps that block revenue attribution, and shelfware driven by poor feature discoverability. Overlapping coverage across bloated security stacks compounds the problem.

Richard Melick: You’ve said quite a few things that I wish we could dive into a lot more. The lifecycle of the integration is one I keep coming back to. I think about how many times we’ve all announced an integration and six months later, an API change has deprecated it to the point that it’s unusable. It was clearly developed for the sale to close that deal, not developed to support the roadmap. The title itself, though, “the ROI black hole,” is a very blunt statement. Is this a new problem or a newly quantified one? Are we starting to think about this as something where we say, why do we need integrations?

Doug Cahill: That’s another great question. We actually had three different titles we were kicking around because there were so many relevant findings. We have this notion of making sure your integrations are customer-driven, that you’re really listening to the market at large and what the use cases are. We also found this dichotomy between tactical requirements, close an in-pipe deal, versus strategic requirements, thinking longer term as part of the roadmap, how integrations allow you to expand market reach and drive more revenue.

But on the notion of the black hole, we found some organizations will implement and deliver an integration but not necessarily have the metrics, the business metrics, to really understand whether or not the integration is delivering value. Is the black hole a new problem? I don’t think it’s a new problem, but I think for different vendors, it manifests differently.

Part of it is that the black hole starts with customer visibility. One of the things I asked the product leaders I spoke with was: how do you know if what you delivered is not only being used but is providing value? We all want to be sticky. We want to make sure that we’re delivering a solution that the customer would just never rip out. There were a couple of vendors I heard from that said, hey, we do track integrations. It’s software as a service, so we know what capabilities of the product are being used, including integrations. And we know that those customers that use more than one integration are more likely not only to renew, but also it gives us an expansion opportunity.

The first part of the black hole is visibility into customer usage and value. The second part depends on how a vendor prices and packages the integration, which leads to whether or not you can attribute direct revenue contribution to an integration or a family of integrations.

Some vendors I heard from have different approaches based on their center of gravity. There are vendors where cybersecurity is a data problem at the end of the day. For a SIEM, for example, or human risk management, where you’re tracking user behavior across multiple corporate assets, correlating that with level of privileges and authorization with your IDP, the integration is core to the data. So the black hole is less of an issue because it’s strategic, it’s the lifeblood of the product.

The depth and width of the black hole depend on whether you have customer visibility, whether you have a pricing and packaging model that allows you to assign revenue contribution to an integration. There’s also this notion of shelfware and feature discoverability. Years ago, I did a qualitative study with a colleague where we talked to cybersecurity leaders in the endpoint security market about whether they were using certain capabilities in the product they already owned. We found that the amount of capabilities they were actually using was modest at best. They didn’t even know the products were capable of doing certain things. In endpoint security, device control, behavioral intrusion protection and detection, people just didn’t know these features existed.

A lot of this black hole is also about making sure your integration connectors are discoverable. Do customer marketing. Make sure your customers know it’s there, they understand the use case and the value that it provides, and you can nudge them to use these important capabilities. That will help you close the black hole.

Richard Melick: You and I have had quite a bit of conversation about the feature discovery component. We’ve all been at companies where even at Bit9, there were so many capabilities that weren’t even really understood by the product marketing team and the product team, because it was a secondary benefit of a capability that was built for a completely different aspect.

We’re seeing that now as organizations reassess their security stack and IT stack. You look at these stacks and you realize you’ve got triple coverage in some areas. Whether that’s because they bought a product for a feature or they added products into their stack due to an acquisition, they might have double or triple coverage of a specific gap they’re trying to address and not even know it.

So we have almost this notion where the lack of integrations and lack of visibility, centralized visibility, is leading to overspending and over investment in quite a few security products. But it’s also on the vendor, the provider themselves, to say, you can do X with Y. That education component is critical.

And it’s always interesting to see that endpoint tools today can still do quite a few asset management capabilities. They can do identity capabilities, not to the full extent that specialized identity and asset management tools can, but they can get eighty percent there because they’re already pulling the data in. You said it at the very beginning: cybersecurity is a data problem. A lot of these cybersecurity companies are data companies, and how they apply and use that data is the critical aspect.

Doug Cahill: And to put that in financial terms, full management has an asset management capability as well. Wallet share is another key term here. We continue to be passionate about this market because there is a common mission. The obvious adversarial dynamic means there’s a mission here. But, obviously, a vendor’s top agenda item is to capture more wallet share.

The way you capture more wallet share is to make sure you have clear feature discoverability, and integrations are really an enabler for that. That’s one way to think about it. At renewal time, if the capabilities of your product are not well known by your customers, you are at risk. If you’ve got three overlapping products and you’re not being actively used, that’s going to increase the likelihood of churn, which we don’t want.

Richard Melick: There’s a great report from MuleSoft that was published two years ago, and I’ll include this in the follow-up materials. MuleSoft did interviews with actual sales leaders about integrations and churn and deal closure. When talking about the necessity of not only delivering on those promised integrations but supporting them,  and why that is such a critical component for the sales cycle and the renewal cycle, you’ve found in this report that that story is still being told today, two years later. It still hasn’t been addressed.

RealSoft, being the behemoth that they are within the generic iPaaS space, has had influence on this, but it’s still such a big problem for organizations to address. But I’ll include that report for everyone to read.

Now back to our report. What’s the one thing that really stopped you? When you started getting the results in, using your background, what new data point came forward that made you go, “Wait a second, I wasn’t expecting that”?

The OCSF Surprise: Standards Adoption and Vendor Incentives

Section summary: The Open Cybersecurity Schema Framework (OCSF)  got a mixed reception from product leaders, some all in, others openly resistant because they’d rather be the aggregator. A reminder that standards fail without real investment and customer education.

Doug Cahill: This might be a little bit of being on my soapbox, but I was a little surprised at the mixed reviews that OCSF got. And here’s the soapbox part: this industry is devoid of industry standards that are adopted and used and implemented, standards for which there is real collaboration across vendors and multiple domains that are really thinking about customer value. And OCSF has a lot of promise to be one of those standards.

We have Stix and Taxii for threat intel sharing, and that really helped move the needle for all consumers of threat intel. We had some promising standards like OpenDXL, but it was vendor specific. But enter OCSF. Since cybersecurity is a data problem, if we can normalize a data model, we can help defenders rationalize disparate telemetry across a complicated environment to more quickly detect and remediate threats.

It wasn’t that all respondents threw OCSF under the bus. There were some that were all in. There were some that said, you know, there’s work to be done. Fair enough. But there were one or two that said, you know, “Why would we adopt OCSF? We want all the revenue for ourselves. We want vendors in our data model, in our data lake, and all the data coming to us. We want to be the aggregator.”

That was a little surprising, and I think it’s probably me being idealistic. There are vendors who have done great work here around the model. Splunk, Amazon, and others have done a lot to define it and get it out there. I just hope it has legs. If I think of other technology domains like networking, we have SNMP in networking that was able to thread the needle: what’s the standard amount of information about a networking device that should be exposed via SNMP? But it allowed vendors to hold back some device information that was proprietary and represented their differentiation in the market. In the storage market, we had SMI, which was a similar standard for instrumenting heterogeneous storage devices.

So that was maybe a disappointment or a surprise. Maybe it was just me being idealistic coming into it, thinking everybody was going to be all in on OCSF. And not everybody was, but some were.

Richard Melick: We’re getting there. I’m seeing the needle move on OCSF. There has been, and this is on us, we are an OCSF shop and we contribute to the program. As we watch OCSF take shape, there’s been poor education around its capabilities. I think this is true of almost every single attempt at a standardized language or schema model. It goes in with the highest of hopes, but in the long term isn’t supported as well.

We saw the hype cycle. We saw the dip, I call the dip the sea of despair, where we all just kind of give up. But we’re standardizing it now. There are more conversations about it, but more education is critical to support it. It’s not just an organization saying, “We’re going to build our whole product on OCSF.” From our perspective, OCSF represents the ability to map your data to a standard that can be easily mapped to other standards and other schemas. That’s an education necessity that everyone contributing from CrowdStrike, Palo Alto, Okta, and everyone else in the program needs to participate in.

We operate in six-month cycles. Every six months, there’s a new technology we have to either address, adopt, assess, and something has to go on the back burner. It’s the exact same experience our customers see when it comes to building out integrations. Do we build the integration? Do we have the time to support it long-term? The necessity is there.

If we want OCSF to survive and thrive, we need to support it like a product, not like a minimal investment. So I do agree with you. That was a surprise, but it also was validating to something I’d been feeling as I was looking at the data.

Integration as Table Stakes: How Buyers Make Decisions

Section summary: Buyers treat integrations differently for first-in-category (wait-and-see, POC required) versus second-in-category (move forward if you have a track record). A visible technical-alliance ecosystem — partner pages, data sheets, implementation guides, is how vendors prove commitment.

Richard Melick: I want to jump back into the report and lean on something you’ve said in the past. You’ve talked about integrations as table stakes. Did your research show that buyers are actually making purchasing decisions at the product level, or is it still more of an aspirational evaluation criteria like, “Oh, we’ll get the integration; let’s just get the deal closed”?

Doug Cahill: That’s an awfully good question. What I would say, and what I heard, was that if it was a first in a category, there was a wait and see. There could be an in-pipe deal, fairly well qualified with budget and known stakeholders, but integration is required to push the deal over the finish line. If it’s a type of integration the vendor hasn’t delivered yet, the customer is going to wait and do a POC before they issue a PO.

If it’s a second in a category, so, hey, we’ve integrated with one ticketing system but not another that we use in the SOC, then it’s more likely they would move forward because they have a level of confidence that the vendor is committed to doing integrations. They have a track record of doing them. They can see what the other integration looks like. As long as they can see value in the product pre-integration and even more value after they get the integration, that works.

So it’s a little bit “it depends.” The other thing I found, especially in the cloud security market, is that buyers want to know that vendors are committed to their technical alliance ecosystem. They want to see that on your partner page. In addition to your channel partners, you’re talking about your technical alliances, and you have materials that they can consume around the integration. There’s a data sheet, there’s an implementation guide. It’s not a product capability that’s secondary. You’re conveying it proactively via your outbound materials, your website, your social presence as something that is core to what you’re committed to. It’s a main capability.

That’s the “prove it to me” mentality. It just demonstrates a commitment to integrations to the market.

Richard Melick: I like this idea. From a product perspective, integrations help move the needle forward. When an organization delivers an integration, not just the requested one but maybe they’re watching the market, it also helps customers increase their confidence in that company, they have their finger on the pulse. They know what’s going on. We see this with companies that have dwindled in their presence. It feels like they’ve siloed themselves, they don’t want to play with others. They don’t want to admit that there’s change in the environment.

And we see the opposite side too. Just coming off RSA, we see a lot of companies that just slapped AI on top of everything. There’s a toll road here in Colorado that claims to use AI to support traffic management. It’s three lanes, Doug. It’s three standard lanes across the whole ring. There’s no traffic management, but they’re claiming it.

So on one side, you have companies that don’t have their finger on the pulse, that go hermit. On the other side, you have companies just trying to be like everyone else. Neither side establishes confidence. It’s the actual act of doing that, delivering real integrations, that establishes confidence in the vendor, in the purchase, in the renewal. Your investment into that vendor as a customer is validated.

There are some reports we’ve got to write if we keep diving into that one. But there’s a real prioritization that vendors are facing. The follow-on question is this: customers are asking for things. Vendors need to prioritize what’s next. You’ve got new categories, you’ve got compliance mandates, you’ve got integration requests, you’ve got an engineering backlog to deliver on all of that. How are you seeing the roadmaps? How did the product leaders talk about their roadmaps and how they’re prioritizing for the future?

Prioritization: Tactical Deals vs. Strategic Roadmaps

Section summary: Every vendor has a “deal-of-the-day” integration from sales plus a strategic backlog. Prioritization lenses include ICP fit, go-to-market leverage (joint marketing, channel partners, marketplace access), and whether the integration ladders up to the roadmap.

Doug Cahill: This is an area I was really interested in learning more about. One of the first questions we asked was around sourcing, vetting, and prioritization. When an integration requirement hits the dev team, is it coming from the field? Is it coming from the alliances team? Is it coming from the product manager? Where do they come from? And then how are they vetted and prioritized? This gets at the subtitle of the report: there are both tactical needs and strategic requirements.

The punchline is all of the above. Every respondent said, “Yes, we have the deal of the day. The top sales rep says, ‘If you just give me this integration, I can close this business and we can make the quarter.’ ” That’s a really common dynamic, and hopefully nobody listening is surprised.

But similarly, there were others who said, “No, this is important. This is strategic.” So these things are in our backlog and we’re prioritizing them.

How do they get prioritized? One is: Is the integration strategic beyond the technical aspect? Meaning, is there a go-to-market opportunity there? One of the things we discussed with respondents was gaining access to online marketplaces. This is pretty common, especially with earlier stage vendors. They think, “If we invest in integrating with a CSP or ServiceNow or Salesforce, we participate in a broader ecosystem. We attach ourselves to that bigger brand, we endear ourselves to that larger company’s field.” There’s a lot of goodness there.

Prioritization was also about the in-pipe deal, ideally with a customer that represents your ideal customer profile. If the integration is maybe going to bump something else off your next sprint, but that customer is right down the bowling alley for you, they meet every attribute of the ICP, that’s probably a good trade-off. So it makes a tactical, deal-driven integration decision more strategic.

The other thing is: Is there go-to-market leverage here? Can you do joint marketing with this vendor? Can you meet in the field? Do you have common channel partners where you can leverage the integration to cross-sell and upsell? Is there access to an online marketplace? Those are the things I heard from vendors about how they’re prioritizing the different types of integrations coming from different sources and putting them through that lens: Is it tactical? Is it strategic? Is it a little bit of both?

A Startup Leader’s Biggest Mistake

Section summary: Doug’s cautionary tale: chasing a big one-off deal that distorted the product roadmap and set false expectations with the board. The lesson is focus, a “yes” off-ICP is a “no” to focus, and even Series B/C companies aren’t immune.

Richard Melick: You’ve been a corporate leader, the boss, quite a few times. You’ve had those conversations about prioritization from a sales perspective, from a business perspective, bringing your own experience. If you could give advice to a startup leader, someone running into this for the first time, who hasn’t sat in that final decision position, what would you tell them?

Doug Cahill: Early on at that cloud security company, we had a net new sales opportunity brought forth from a beta customer. The product team brought it forth. We had a really big, prominent beta customer who wanted a different delivery model. It was going to be good revenue for a pre-revenue company. We naively thought we could do both, have one codebase and satisfy this one-off while delivering our core product. It was my decision, and I was a kid in a candy store. I made the wrong decision. I went for that business. That was a mistake for two reasons.

One, it set an expectation with the board on revenue. “Wow, we’ve already got this revenue here. So up and to the right, what’s the trajectory?” Well, that’s a one-off. It’s not repeatable. It wasn’t repeatable, and it didn’t align with the investment thesis. We realized the mistake and wound that down over time and focused on the core product. We were able to convert a bunch of those betas into paying customers and we were off to the races.

But it was a distraction. The big thing with startups is focus, focus, focus. There’s always a shiny object, the dog chasing the squirrel kind of thing. If there’s an integration that’s going to lead you to close business and get closer to a customer that is your ICP, great. If it’s an outlier, have the conversation. As an early stage product leader, you want to be mindful of the adjacent markets. But if you apply resources, it can just be a distraction.

Richard Melick: I think that’s a great lesson. We’ve seen a lot of startups chase that first deal and shift their full model. I’m going to say it’s not even all startups. Sometimes we see some Series B and Series C companies. An opportunity comes along and they shift their full model to support a single customer. But that one customer is such an outlier in their use case. It’s neither scalable in the support model, nor is it scalable in the expanded sales opportunity because that one customer is the only one that’s ever going to use it that way.

I haven’t sat in your seat. I haven’t been a corporate leader in that sense. But I’ve been in the product seat. And to reiterate: you cannot be the solution for everybody. Your ICP is a very grandiose scheme. When we do ICP research, we look at how we’re going to impact this from a feature and capability perspective. You cannot get one hundred percent coverage. Nobody is ever going to get one hundred percent coverage. Even if you got fifty percent, that’s a massive thing.

You’re going to get a sliver, a piece of that pie. You’ve got to leave some for your competition to address and invest in because if it’s not going to help you scale to the next stage and next product and capability, then you’re not actually helping your organization. You’re just chasing dollars. That’s where you get a fractured product environment.

Doug Cahill: That’s a great point. I think that’s the way buyers think about it too. They want the platform vendors, the aggregators, to be leaving some open space for innovators and startups. They want best-of-breed optionality. That company I mentioned, while that wasn’t a deal we should have done, it was sort of a catalyst to really focus on our ICP, which led to an integration with a major CSP. And that led to field engagement, being on stage with the CSP. You know, you go through these things as a startup. If you weren’t making mistakes, you weren’t trying hard enough. So that was an educational mistake that allowed us to reset and focus, and that ended up being the recall, ultimately.

Platform Consolidation vs. Best-of-Breed: Can Both Be True?

Section summary: Both trends are simultaneously true. Enterprises running 80–120 controls want consolidation, but not one platform to rule them all, they want “many platforms of value” that remain open, with best-of-breed optionality. Agentic AI will only accelerate demand for innovation from startups.

Richard Melick: You’ve said a few times in this conversation that we’re seeing platform consolidation and best-of-breed preference. We’re seeing a lot of small companies become the mega vendors that they once sought to go up against, through acquisition and new features and new capability. Did this research report really move that needle? And as you’re looking at that tension between what you’ve described as platform consolidation and best-of-breed, did this report change your perspective of what’s happening next?

Doug Cahill: No, not really. I think both things are true, which is maybe another way of saying “yes” or “no,” or “it depends,” which is squishy. But what I mean by both things are true is that most enterprises are operating eighty to one hundred twenty cybersecurity controls. They have tools for everything. It’s untenable. As I said earlier, it’s separate teams, separate controls, separate environments that creates seams for adversaries to exploit. So there is consolidation inside organizations. It’s more top-down than bottoms-up. They do want some consolidation to platforms. They just don’t want a single platform to rule them all.

A colleague of mine at Enterprise Strategy Group used to talk about “many platforms of value,” which is what I mean by both things are true. Yes, buyers do want platforms. Some of the vendors I spoke with are positioning as platforms. But the other thing that is true is that even those vendors positioning as platforms have a strong ecosystem of third-party products.

AI is a catalyst for this, especially agentic AI. Some of the things we heard at RSA with agentic AI making unauthorized system changes, pushing code to repos, and deploying code to production. Because of that fluid nature of our world, there’s always a need for innovation in the startup community, which is why we continue to have strong venture investment.

So both things are true. Yes, organizations want to consolidate platforms. They just want those platforms to be open, interoperable, and still have optionality to integrate best-of-breed controls into those platforms.

Richard Melick: You’ve talked about platforms being hindered by a lack of third-party integrations. Even before you started working with us and doing this report, is the data showing that that’s still a primary barrier to success? Or do you see the shift starting? I guess the better question is: is there a catalyst for a shift coming?

Doug Cahill: I think the catalyst from a sell-side perspective, from a vendor perspective, is there are now more options to bring integrations forward. One option is internal development. What I heard there was either there’s headwind internally in terms of working with the product team on prioritizing integration user stories, or it’s shoving the backlog. I heard from a very large cybersecurity vendor that they set up a separate team to do integrations so they can control their own destiny.

Or I outsource the development, but then I’m outsourcing something that could potentially be really strategic. Or I work with an integration-as-a-service partner that allows me to deliver and maintain the integration. So there’s more optionality there.

I also think from the buy-side of the market, platformization market requirements are becoming more clear. As I said earlier, they want to consolidate, but they still want openness and interoperability. I’m not sure it’s a shift, Richard. I think it’s maybe more of an evolution.

Richard Melick: It’s the buyer cycle evolution, and maybe it just comes from better education. The ability to understand that there are options on the table for adding this. It’s not just relying on one cycle — build in-house or say no to the integration or outsource it. You’ve got various workflows, vendors, iPaases, unified APIs, technologies starting to address this in either general manners or hyper-specific spaces.

This report is substantial, but it’s just a start, right? We at Synqly are dedicated to repeating this report every single year. Next year, we’re bringing in more data and more qualified interviews, and I look forward to re-interviewing some of the people you talked to in this first report to see what has changed. But for this year, for two thousand twenty-six, you have to distill this report down to a recommendation for the CISO, for the chief product officer reading it. What’s your final recommendation for them?

Final Recommendations: The Action Plan

Section summary: Doug’s action plan for CPOs and product leaders: validate the customer use case (not just one customer), invest in sales enablement and partner go-to-market, budget for the hidden pre-work (NFR copies, test data, API docs, alliance agreements), plan for API-drift maintenance, and build a financial model that assigns ARR value to integrations.

Doug Cahill: First of all, big thanks to the CPOs who participated. It was fun and interesting to talk to CPOs across such a broad range of cybersecurity vendors, from innovative startups to large cap cybersecurity brands we all know. I really appreciate everybody’s time, especially the fact that they gave their time to this, it’s an important topic.

So what’s the action plan, the call to action here from what we learned in those interviews?

I think the first one is for someone from a product manager perspective. Really understand the customer requirement. It’s not an individual customer; it’s customers that represent a market. Really vet that use case. When the sales team comes forward with an integration opportunity, the product owner and product manager should really get with that customer and understand the good, better, best phases of the integration.

One participant said he was sometimes concerned that their product team had a “center of the universe” view of their product, like they were the hub and all the other security controls were around them. He had to get the product team to think less centrically and more broadly about how the customer thinks about the role of their digital technology in their cybersecurity stack. That’ll help them develop better use cases. In addition to the good, better, best on a roadmap, there’s also the crawl, walk, run phases of investment on partner go-to-market.

Think about your go-to-market activities from a sales enablement perspective. This is all basic stuff, but do it. Make sure you’re getting in front of your sales team and educating, especially your sales engineers, around the value prop and the use cases.

One of the things we heard loud and clear from everybody was that there’s an upfront cost before you can actually implement the integration. Beware of the need for a technical alliance agreement. You need to identify the right contact at that vendor. You need to get access to an NFR copy, maybe test data. Do you need the API documentation? There’s a whole lot of lifting involved, some sunk cost before you can even put hands on keyboard. Be mindful of that.

And be mindful of the ongoing maintenance costs, especially as APIs shift. There was some pain around changes to APIs that weren’t always documented. Unfortunately, sometimes that results in a customer satisfaction issue. Integrations break in production because a third party changed APIs. Yikes.

And I guess the last one I would end on is back to the black hole. Make sure you have visibility in how your customers are using integrations. Also have some sort of financial model so that you can start to assign ARR value in terms of how your integrations are providing expansion opportunities, making you stickier, to reduce churn, maximize renewal rates. Think about the business metrics that’ll allow you to assign value into your investment in integrations.

Richard Melick: Those are great, and they approach it from not just a technical perspective but a business perspective as well. Understanding the longevity of this capability and the partnership you’re building.

I do appreciate you talking about the pre-work that is so critical. This is not just about going into somebody’s docs, grabbing their API, and plugging it into an LLM and saying, “Okay, build me an integration.” That’s only one component. Without the mock data, without the relationship, you’re still having to do the manual monitoring of that API, the support of it. And it’s going to change, my friends. It’s going to change.

Everything else that comes with it is such a heavy lift. Talking to our product team, they say that building the integration is the easiest part. It’s only a fraction of the full capability necessary to move the needle on a process. Talk to any development team that used to work at a SIEM or a SOAR. We’ve talked to quite a few, and they say, “We don’t ever want to do it again because the process is so long and so intense in terms of energy spent to support it, just to support the idea, not just deliver it.”

Closing Thoughts

Section summary: Where to find Doug, and what’s coming next from Synqly — including an annual refresh of this research, a recording on YouTube, and a recap blog.

Richard Melick: Well, Doug, beyond the tennis courts, where can people find you? How can they get in touch with you?

Doug Cahill: I’d say find me in the usual swimming holes, LinkedIn. You can find me there. I’d look forward to connecting with folks on LinkedIn and learning more about what vendors are up to. I’m always interested in a chat. That’s probably the best way to find me.

Richard Melick: Excellent. Well, Doug, I appreciate you giving your time today. I appreciate this report. I really look forward to us starting to plan out the next one and seeing what else we can talk about and shed more light on the integration challenges that are impacting the cybersecurity and IT space.

To everyone that stuck with us throughout this conversation: I’m going to be sending out an email shortly with all the links. I’ll have a link to the recording on YouTube so you can watch this. We’ll also have a transcript up on our blog and a recap blog talking about what we’ve discussed.

If you have any questions or want to talk to us here at Synqly, visit Synqly.com. Otherwise, I hope you all have a wonderful day. Thanks for your time.

Resources

• MuleSoft Integration Report: Sales Impact on Churn and Deal Closure