If you pick a random SaaS company out of a jar and go to their website, chance are they integrate with another tool. Typically, the end goal of integrations is to meet users in the middle by working with other tools they’re already using on a day-to-day. Put another way, integrations are a strategic business decision.
But the question remains: why don’t companies just build a tool with similar functionality in order to make the product stickier? Especially when the tools you integrate with are in your same space. Think Asana integrating with Notion.
Early on, we made the decision to integrate with tools that, from the outside looking in, could look like competitors. And in some ways they are, in many ways they aren’t. But regardless, we decided we weren’t going to take out the time to build additional functionalities into our tool. Why? Let me explain.
We do a lot of things very well, but we don’t do everything
At a high level, the guiding principle of our software is that we want to be a hub of incident management for everyone—that means engineers, customer service, marketing and even product teams. And we really feel like this is our differentiating factor.
But the reality is that, right now, we don’t own every step in the incident management process. This is by design, and put bluntly, we don’t have the capacity to build a tool for every single step in the incident management process.
Our guiding philosophy for integrations is all about meeting folks in the middle. If there are existing pieces of software that organizations use to help them with their incident management, chances are we have an integration with them.
Companies are complicated and nothing works in a silo. So whether you’re using Pagerduty, OpsGenie, Jira or any of the other tools we integrate with, incident.io exists to level-up the overall incident management process, or as we like to put it, the rising tide that lifts all ships.
On-call paging is a solved problem for escalations
On-call paging is incredibly important in the incident response process. By setting up an on-call function, you guarantee that someone is available at all times to deal with any disruptions to your product or software. So why haven’t we created our very own on-call product? Put simply, PagerDuty already has and what they do is hard. So we’ve said to ourselves, this is a solved problem.
On-call paging is really hard to get right. And it's the kind of thing that needs to be absolutely bulletproof because you need to have as close to 100% confidence that incidents won’t slip through the cracks. So rather than spending hundreds of hours on R&D, dozens of engineering resources and lots of money, we integrated our product with PagerDuty. Problem solved.
Tracking follow-up actions? There’s already a solution for that, too
When it comes to follow-up originating from incidents, we could own that within our product. And in some cases we do. But the work coming out of incidents typically needs to be prioritised and worked on alongside the other work being carried out by engineering teams, and those teams don’t track their work inside incident.io.
For this reason, our preference is to integrate with tools like Jira, Linear and Asana, and allow you to push your incident actions there instead. It still makes sense to maintain the link within the incident so we can provide valuable control and insights, but building an integration with their tool felt like the sensible choice to make.
Post-incident documentation is also accounted for
If we look at post-incident processes, there's a couple of things that need to happen. One of them is that typically folks need to document what's happened in that incident. And again we could build a Google docs-type product where you go in and create incident post-mortems but doesn't feel particularly beneficial to us.
In reality, it would take us six months to build a slimmed-down but comparable document editor, which wouldn’t be high leverage use of our time. And ultimately our customers might say “we’re already using Google Docs, why did you build this product?”
So that's why we've been integrated into Notion, Google Docs, and Confluence. These are all tools that have been in the document editing space before us, so why waste the time and resources to create a competing product?
And early feedback on our Notion integration has been great, so at least for the time being it seems like it was the best decision.
So what’s on the roadmap?
With all of that said, there’s still a bunch of functionalities in our immediate domain that would make sense for us to own.
The three that we commonly talk about are response, paging, and public status pages. Those three things are all tightly related to incidents, and so they make sense for us to eventually build. But there are other places we integrate that we would just never build. Take Github for example. We're never going to build a competing product because it falls outside of the scope of incident management and response.
But even if, and when, we build a response product, a paging alternative and a status page, our integrations are here to stay.
I'm one of the co-founders and the Chief Product Officer of incident.io. I've spent my whole career working in engineering.
