The goal of this page is to document, share and iterate on the Jobs to be Done (JTBD) and their corresponding job statements for the Secure and Govern stages.
These Jobs reflect how the UX team frames the Secure and Govern experience. Combined, these Jobs aim to provide a unified view and a shared understanding of the user experience.
This page is a living document; as our understanding of our users deepens and as changes to the product direction take place, we will update our JTBDs.
Utilize JTBDs to:
We utilize the JTBDs framework in the following ways:
We want to use the JTBDs framework as a way of gaining a shared perspective on what the Secure and Govern user experience is, rather than thinking about it in a siloed, Category-focused, way. The user doesn’t care about our organizational structure, and so our grouping of Job Statements shouldn’t reflect that (i.e. you won’t see SAST/DAST/etc. Job Statements in our list). Striving to break free from Conway’s Law, we decided to instead group Job Statements primarily around broad user goals (i.e. Big Jobs), and then have each Category team interpret them as it fits their domain.
We aspire to create a single set of JTBDs for the entire stage, such that that set is mutually exclusive and collectively exhaustive. This means that there should be no overlap between Jobs, and that together all Jobs should exhaust the user goals that Secure and Govern should address.
It is important to form hypothetical Jobs to explicitly call out what goals we believe our users have. However hypothetical Job Statements are not actionable yet. They should be validated (or invalidated) through user research.
The Job hierarchy diagram represents the relationship between Jobs in a visual way. It focuses solely on Jobs, rather than on full Job Statements, to make the structure more easily digestible.
Note that most, but not all, Jobs fit under the Aspirational Job of “Safeguarding my applications from exploits”. Additional Jobs appear as satellites, supporting this core mission.
View Job Hierarchy Diagram in Mural
Micro Job | Job statement | Maturity | Confidence | Source |
---|---|---|---|---|
Identifying vulnerabilities in new code | When committing changes to my project, I want to know if I introduced any business-critical vulnerabilities, So that I can address them prior to sending my code for review. |
|
Tested | Issue |
Identifying vulnerabilities in new code | When I am ready to release changes into production, I want to verify it is safe to release, So that I can release the changes responsibly. |
|
Tested | Issue |
Identifying vulnerabilities in existing code | When I am assessing the security of my application in production, I want to know whether my app is currently vulnerable, So I can address detected business-critical vulnerabilities |
|
Researched | Issue |
Micro Job | Job statement | Maturity | Confidence | Source |
---|---|---|---|---|
Triaging vulnerabilities | When I am triaging vulns, I want to address business-critical risks, So I can ensure there is no unattended risk in my orgs assets. |
|
Researched | Issue |
Remediating or mitigating confirmed business-critical risk | When my code has been scanned, I want to resolve the confirmed business-critical vulnerabilities, So I can ensure my changes are compliant with my org's risk policies. |
|
Researched | Issue |
Exempting detected vulnerabilities from further actions | When I have proven a vulnerability to be either a FP or to be not business critical, I want to exempt it, So that it's clearer for me and my teammates what vulnerabilities we should be focusing on. |
|
Researched | Issue |
Orchestrating remediation | When I have proven a business-critical true positives, I want to initiate and support remediation efforts, So that I can ensure the vulnerability get remediated. |
|
Researched | Issue |
Determining the risk of the vulns found in my application | When I am Investigating a vulnerability, I want to determine it's risk level, So that I can take the next appropriate action. |
|
Tested | Issue |
Verifying resolved business-critical vulnerabilities | When I am made aware a vulnerability has been resolved, I want to verify it has been remediated, So that I can ensure it no longer poses a risk. |
|
Researched | Issue |
When I am writing code for a project, I want that code to be scanned for issues like duplication and not following standards, so it is easier to read by others making contributions.
Micro Job | Job statement | Maturity | Confidence | Source |
---|---|---|---|---|
When I make changes to my project, I want to automatically see how those changes impacted the quality of the code, so that I can be confident my change improves the readability of the project. |
|
Researched | Issue | |
When I review my project summary, I want to see a list of code quality issues, so that I can proactively fix those issues in a future change. |
|
Researched | Issue | |
When I am reviewing code in a merge request or a file, I want to see a list of code quality issues identified in the file, so that I can help improve code quality in the project. |
|
Researched |