PRD - Self Identification - Phase 2
Overview
Background
Objective
Make the Authority Document search and selection process faster by allowing users to tell us a little bit about themselves and their company in order to propose a set of authority document which may be of interest to them.
Personas
Self identification will typically happen at the sign-up phase. The user signing up mostly is any of these roles:
If a user is already signed up, the selected industry can be changed by the owners/admins of the workspace. These typically will be any of the first two roles above.
Success Metrics
Project goals and the metrics we’ll use to judge success.
Goal | Metric |
---|---|
Users self-identify their industry in UC 4.0. | The percentage of users who add an industry to their profile. |
Users self-identify their affiliations in in UC 4.0. | The percentage of users who add affiliations to their profile. |
Users self-idenfity their state-agency in in UC 4.0. | The percentage of users who add state agencies to their profile. |
Users find benefit in the shared lists (time-saving is achieved). | Differential between real builds and our suggestions. Do we have an 80/20 of the most selected list AND do we avoid suggesting outliers to general audiences? |
Current Challenges / Limitations
The current Common Controls Hub (CCH) search functionality is confusing for customers to locate authority documents that are important to them.
Customers typically use three tools (CCH, Research, and the internet) to search for and confirm the ADs that are of interest to them.
Benefits
Vastly increase the time-to-value and user experience by providing a proposed list of ADs based upon an 80/20 rule (i.e., propose the top 80% of ADS that others use in that industry).
Subscription / Pricing / Billing Impacts
Describe any financial impact this product will introduce (if any)
Beta and Early Access
Describe if beta customers and/or early access is essential for success. If betas are required, there could be a substantial recruitment process required, which needs to be anticipated and planned for.
Risks and Assumptions
See risks and assumptions from Phase 1 PRD - Self Identification - Phase 1 | Risks and Assumptions
Milestones and Phases
Milestones and how each milestone can be successfully measured.
Number | Description | Success Measurement |
---|---|---|
1 | Admin Users can self-identify their industry in UC 4.0. | We can store industry information captured from users without impacting data we receive from other sources. |
2 | Admin Users can self-identify their affiliations in UC 4.0. | We can store affiliation information captured from users without impacting data we receive from other sources. |
3 | Admin Users can self-identify their state-agency(ies) in UC 4.0. | We can store state-agency information captured from users without impacting data we receive from other sources. |
Product Requirements
Use Cases
Happy Day Scenarios
This is the “happy path” that includes the beginning to end steps the customer/user takes to be successful.
Rainy Day Scenarios
Here is where you describe what to do when things go wrong (e.g., user closes the browser, API doesn’t return results …)
Requirements
Requirement | Importance | Status Jira Issue | Comments |
---|---|---|---|
During the sign-up process allow the customer to specify which Industry their company most closely aligns with | P1 | Not Started |
|
During the sign-up process allow the customer to specify which memberships they belong to (e.g., ISACA) | P1 | Not Started |
|
During the sign-up process allow the customer to specify which State-agency they work for (e.g., Alabama Department of Education) | P1 | Not Started |
|
Propose a list of ADs based upon the industry self-identification. |
|
|
|
Propose a list of ADs based upon memberships self-identification. |
|
|
|
Propose a list of ADS based upon State-agency self-identification. |
|
|
|
Open Questions
List any open questions that come to mind throughout the lifecycle of this project
Question | Answer | Date Answered |
---|---|---|
Is the sign-up process the best place to ask for the information? Or would on-boarding be better for the user experience? |
|
|
Out of Scope / Future Functionality
List the known features that are out of scope for this project or might be revisited at a later time.
As is the case with the assumptions, it is important to list these out so that architects and engineers can plan accordingly for these later updates.
Impacted Product Components
If this project is a component to other areas or an update to an existing product, specifically call out where this product will interact with other areas.
User Interaction and Design
As soon as user registers, they go through a simple self-identification page with minimal friction.
The user chooses which industry best fits their organization or chooses other.
Once user is signed up and self-identifies which industry they are in, the call to action (CTA) is to setup their compliance portfolio.
Based upon their industry self-identification a list of regulations / frameworks are proposed which they can add to their compliance portfolio (AKA List).
Process Flow Diagrams
Links to user journeys, process flow, or other diagrams related to the requirements.
Guides
If there are UI components to this requirement, list the main areas where interactive user guides would be needed.
Additional References
List and link to any other reference sites, documents … that might be important to the reader.