The goal of this page is to create, share and iterate on the Jobs to be Done (JTBD) and their corresponding job statements for the Respond group. Our goal is to utilize the JTBD framework to better understand our buyers' and users' needs.
Utilize JTBD and job statements to:
First, when an alert is triggered, I want to be able to triage it quickly, so I can decide if it's worth investigating further or not. Secondly, during an active incident, I want to reduce the time to resolution, so I can get the things back up and running as quickly as possible.
|During an incident, I want to have quick access to my teammates and communication channels, so we can get to the root cause of the issue as quickly as possible.||Researched||Issue|
|During an incident, I want to publicize important updates about the incident, so that stakeholders can stay informed.||Researched||Issue|
|I want to automate as much of my incident response documentation as possible, so I spend more time resolving the incident and less time documenting my work.||Researched||Issue|
|After an incident has been resolved, I want to review a timeline of events with my team so that we can identify system, application, and process changes to make so we can improve over time.||Researched||Issue|
|I want to review summary information about my application so I can proactively investigate irregularities before they become large incidents.||Researched||Issue|
|During an incident, I want to automatically apply fixes to known problems, so that I don't have to manually fix things.||Researched||Issue|
|I want to review the trends of my incident resolution, so I can track how my response to incidents is evolving over time.||Researched||Issue|
|I want to easily capture key details as I investigate an incident, so that I can learn from the present incident and more easily resolve similar future incidents.||Researched||Issue|
|I want to be able to integrate my tools together, so that all of my tools work together seamlessly and I don't have to spend time making the same updates in different tools.||Researched||Issue|
|I want to generate reports about the incident to share with stakeholders so I can more easily facilitate discussions about the incident with those stakeholders.||Researched||Issue|
|I want all of my alerts from all of my monitoring tools to be visible in one location so that I don't have to check for alerts in multiple places.||Researched||Issue|
|I want to see all relevant metrics relating to an alert, so that I can more quickly pinpoint the root issue.||Researched||Issue|
|I want to see all relevant logs relating to an alert, so that I can more quickly pinpoint the root issue.||Researched||Issue|
|When triaging an incident, I want to review all relevant data so that I can more quickly pinpoint the root issue.||Researched||Issue|
|I want to be able to assign an alert to someone on my team, so that they can continue investigating it.||Researched||Issue|
|I want all relevant alert details ported over to any incidents created, so any information uncovered during investigation of the alert is automatically captured in the incident.||Researched||Issue|
|I want to be able to change the status of the alert, for example to acknowledge the alert or mark it resolved, so that my team members know the current status of the alert.||Researched||Issue|
|I want a log of any changes that are made to the alert by my team (for example, status changes) so I can see what happened, when.||Researched||Issue|
|I want my alerting tool to integrate with my chat platform (ex Slack), so that I can easily communicate with my team members in our other communications channels.||Researched||Issue|
I want to set up on-call schedules to handle my alerts so I can be confident that, if an alert is firing, the appropriate people will be paged.
|I want to set up escalation policies for my on-call schedules so I can be confident that, even if the first person paged to review an alert isn't available, someone else will be notified.||Researched||Issue|