I joined PagerDuty in 2014 when the company was, by many measures, a successful startup. The company was growing and had become the default choice for businesses that needed an effective and highly reliable IT alerting tool. I believe that early success was due, in part, to its founders choosing to solve a very specific problem that they had experienced first-hand. Their experience created a critical ingredient for successful product design: empathy. Having empathy means appreciating the target audience’s context and goals, their problems and priorities, their existing tools, constraints, and assumptions. PagerDuty’s founders developed knowledge over time through their work as on-call engineers, then leveraged this knowledge to build a cloud service for people in similar positions. That foundation in empathy is one of the qualities that convinced me to join the company as a user experience designer.

What convinced me to grow my career at PagerDuty was the company’s commitment to learning. Success in business is transient, and as I learned in my first few months on the product team, PagerDuty had no intention of resting on its laurels. The company aspired to go beyond on-call notifications and support the entire incident response process. To achieve that goal, we started by asking some big questions:

• What are common models and tools for incident response? What is working well, and what is working poorly?
• Who participates in incident response? What are their goals?
• How do responders, managers, and impacted end-users differ in how they think about incidents?
• How well does PagerDuty model and surface what people in different roles across an organization actually care about?

Desire to Make a Difference

To answer these questions, we could not rely on institutional knowledge and the occasional feature request to inform product design. To develop empathy for people who didn’t use PagerDuty and who faced a set of challenges unfamiliar to us, we had to devise a new way to learn. One of my trusted guidebooks in the discovery phase of user research is Interviewing Users: How to Uncover Compelling Insights by Steve Portigal. I recommend this book to every member of my team. For one, it’s a short read, and secondly, everyone who’s involved in the product-making process should understand how to talk to users in a way that yields valuable insights. Leveraging Portigal’s framework for conducting user research, we interviewed customers across a wide range of industries and organization sizes about their incident response practices. Not everyone attended every interview, but along the way, representatives from product management, engineering, user experience, support, marketing, and sales listened in and shared their key takeaways. We then met as a cross-functional team to synthesize the data and create a prioritized list of needs and opportunities. My colleagues’ engagement and desire to make a positive difference left a deep impression on me. I feel truly fortunate to work with people who genuinely care about our shared mission.

Swapping Engines in Flight

It was a good thing that my team was committed to the cause because we needed every ounce of enthusiasm to digest our findings. In talking to our users, we realized that building upon PagerDuty as it existed in 2014 would make solving their incident response problems extremely difficult. To drive an effective incident response, people need to know what is broken and the scale of impact. PagerDuty couldn’t convey what was broken because it tracked monitoring tool integrations, not the services/applications being monitored. PagerDuty couldn’t convey the scale of impact because it represented every critical alert from a monitoring tool as an incident, even though many customers told us that the way they respond to alerts is different than the way they respond to incidents. We realized that to achieve our goal of supporting the entire IT incident response process, we were going to have to evolve the fundamental constructs within our application without disrupting customers who were happily using the product. In essence, we had to perform the equivalent of swapping out our jet engines in flight.

It took multiple product development teams working in careful collaboration and months of iterative development, but we did it. Today, PagerDuty services can model our customers’ services and applications, no matter how many tools are monitoring them. PagerDuty incidents can model our customers’ incidents, whether there are zero alerts involved or thousands. I am astounded at how seamless the transition has been from our customers’ perspective. Customers were not forced to change their workflow or go through a complex migration process. If a customer wants to continue using PagerDuty for highly reliable IT alerting, they can. And when they’re ready to transform their digital operations, PagerDuty is ready to help them make the leap.

When people ask me what I like most about working at PagerDuty, I have to say it’s the feeling of making an impact. But the best part is that I’m not making that impact alone. I have close partners throughout the organization who have put in the effort to cultivate empathy for those we aspire to serve. They’ve demonstrated their willingness to act upon what we learn, even if it means ripping out and replacing the guts of the product with surgical precision. No one claimed that evolving PagerDuty from an IT alerting tool into a digital operations platform would be easy or straightforward. But here we are, two years later, and I know the possibilities for where we go next are limited only by our own vision.

If you’re interested in shaping that vision, come join us!