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 FigJam
| Micro Job | Job statement | Maturity | Confidence | Source |
|---|---|---|---|---|
| Defining what scans need to run where, and under which circumstances | When I am configuring a CI/CD security scan, I want to specify which assets need to be scanned and under which circumstances, So that I can ensure my assets are secure prior to or at their release. |
|
||
| Defining what scans need to run where, and under which circumstances | When I am configuring a security scan outside of CI/CD, I want to specify which assets need to be scanned and under which circumstances, So that I can ensure my assets are secure in production. |
|
||
| Defining what which types of vulnerabilities are relevant to my org | When I am configuring a security scan, I want to specify which types of vulnerabilities the scan should detect, So that we don't waste time sorting through irrelevant findings. |
|
||
| Enabling security tests | When I am either enabling or configuring a security scan, I want to run a demo scan, So that I can validate my configuration before it is implemented |
|
| Micro Job | Job statement | Maturity | Confidence | Source |
|---|---|---|---|---|
| Defining what vulnerabilities must be remediated before code can be integrated | When I am implementing security controls in my org, I want to define what vulnerabilities must be resolved prior to release, So I can prevent business-critical vulnerabilities from being introduced into production. |
|
||
| Defining who to alert and under which circumstances | When I am implementing security controls in my org, I want to specify who needs to review and approve changes to my assets, So that I can ensure that the changes to my assets maintain compliance with my org's policies |
|
| 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 |
| Micro Job | Job statement | Maturity | Confidence | Source |
|---|---|---|---|---|
| Applying license compliance policies (Little Job) | When I am creating a compliance framework for my organization to follow, I want to implement policies for software licenses, So I can ensure my org maintains compliance. |
|
||
| Complying with my project's license compliance policies (Little Job) | When I am committing changes to my application, I want to be made aware if I am violating a policy, So I can ensure my changes maintain compliance with my org's policies. |
|
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 |
