Job Leveling for Postings (English)
Created Date | Oct 31, 2022 |
---|---|
Target PI | TBD (early 2023?) |
Target Release | TBD (early-mid 2023?) |
Jira Epic | |
Project Pages | WF Taxonomy: https://economicmodeling.atlassian.net/l/cp/vAwL1YY9 |
Document Status | Hold Draft |
Epic Owner | @Hal Bonella |
Tech Lead | @Nathan Triepke |
Stakeholder | @Abby Santos @John Pernsteiner @Ben Bradley @Mark.Hanson |
Engineering Team(s) Involved | Documents Micro C&E Analyst Taxonomy Data Quality |
Customer/User Job-to-be-Done or Problem
The Scope of the user problem should be narrowed to the scope you are planning to solve in this phase of work. There may be other aspects you are aware of and plan to solve in the future. For now, put those in the Out of Scope section.
When user wants to see job posting data by the seniority (entry level, senior level, etc.), I want to have this data provide through a filter based on a job-level title classifier, so users can how the difference in what's listed in a posting between a entry level role and senior level of the same role.
While some of this work has been done before and is currently tagged on documents the goal is to start from scratch and treat this as a new feature.
When using Lightcast's job postings data to create reports, I want to be able to filter, sort, or compare postings from different job levels. Some the questions I may want to answer are: What skills are being asked for a entry job vs a senior job of the same title or occupation? How do the salaries differ between job levels? Answering questions like these will give me a better grasp on the job market as use Lightcast’s product to accomplish my goals, whether it be restrict my programs to help graduates land jobs or how stay competitive in the market for experience workers in my field.
Value to Customers & Users
In the JTBD framework, these are the “pains” and “gains” your solution will address. Other ways to think about it: What’s the rationale for doing this work? Why is it a high priority problem for your customers and how will our solution add value?
Clients have been expressing interest in seeing the difference in job postings data between entry level vs senior level. For instance, is there a difference in what skills are needed? Education? Years of experience? Or are some skills just assumed at the senior level?
In addition, Burning Glass Occupations (i.e. LOT v3.4) had senior occupations as an option. LOT v6 will not have this, so creating this new feature will allow us to replace this aspect from v3.4 that clients are losing.
Value to Lightcast
Sometimes we do things for our own benefit. List those reasons here.
Monetary Value for Lightcast
TBD, but new features would indicate some amount of new revenue; still need to look into how much.
Target User Role/Client/Client Category
Who are we building this for?
This should be a feature for all out clients at the end, but we may roll this feature out to select clients in the beta stage.
Delivery Mechanism
How will users receive the value?
This should be a filter available in jpa reports in Analyst, API, etc. as well as a field in Snowflake.
Success Criteria & Metrics
How will you know you’ve completed the epic? How will you know if you’ve successfully addressed this problem? What usage goals do you have for these new features? How will you measure them?
Aspects that are out of scope (of this phase)
What is explicitly not a part of this epic? List things that have been discussed but will not be included. Things you imagine in a phase 2, etc.
Job leveling for profiles
Solution Description
Early UX (wireframes or mockups)
<FigmaLink>
Non-Functional Attributes & Usage Projections
Consider performance characteristics, privacy/security implications, localization requirements, mobile requirements, accessibility requirements
Dependencies
Is there any work that must precede this? Feature work? Ops work?
Legal and Ethical Considerations
Just answer yes or no.
High-Level Rollout Strategies
Initial rollout to [internal employees|sales demos|1-2 specific beta customers|all customers]
If specific beta customers, will it be for a specific survey launch date or report availability date
How will this guide the rollout of individual stories in the epic?
The rollout strategy should be discussed with CS, Marketing, and Sales.
How long we would tolerate having a “partial rollout” -- rolled out to some customers but not all
Risks
Focus on risks unique to this feature, not overall delivery/execution risks.
Open Questions
What are you still looking to resolve?
Should we separate this feature by geos?
it will definitely need to be separated by language
If we do break up by geo, need to determine which geos are in the initial role out.
Complete with Engineering Teams
Effort Size Estimate | L-XL |
---|
Estimated Costs
Direct Financial Costs
Are there direct costs that this feature entails? Dataset acquisition, server purchasing, software licenses, etc.?
Team Effort
Each team involved should give a general t-shirt size estimate of their work involved. As the epic proceeds, they can add a link to the Jira epic/issue associated with their portion of this work.
Team | Effort Estimate (T-shirt sizes) | Jira Link |
---|---|---|
|
|
|