PI 4 Definition of Done: Documents are tagged with Benefits data

(Proposed) PI 5 Definition of Done: Data is accessible in Snowflake for evaluation (TBD: API?) and Front end design complete (filter? packet? report?)

PART 1

Customer/User Job-to-be-Done or Problem

As a talent and market analyst, I want to see benefits data within the software so that I can analyze compensation offerings by role, industry, market, competitor, etc. and so that I can better advise on the benefits that should be advertised to attract applicants.

As a workforce developer, I want to see benefits data within the software so that I can better understand my region and make key decisions on which jobs and industries to support.

As a Lightcast consultant/economist, I want to see benefits data within Snowflake so that I can quickly utilize benefits data in my research and quickly provide valuable insights to clients.

Value to Customers & Users

Benefits data helps inform decisions on talent strategies.

Two big questions are being asked: “What benefits are employers advertising in order to attract applicants for particular roles?” (addressed in phase 1) and “How much do benefits contribute to the total cost of a hire?” (addressed in phase 2).

Here’s Matt Walsh on the value of benefits data from job postings:

“Job posting text serves two purposes: describe the job and advertise the value prop of the job to jobseekers. We capture a lot of data on the job description, but we don't capture much of the value prop for the candidate (salary is the big thing we do get). Employers, industry associations, and other workforce stakeholders benefit from knowing both the quality of benefits offered and the frequency with which those benefits are advertised/explained to jobseekers. We can get limited information on the quality of benefits from BLS, via the total compensation survey. From job postings we can get info on how often the benefits are advertised to jobseekers. If an employer or industry is advertising benefits less often than some benchmark, that could be one reason why they are having a hard time attracting talent.” – Matt Walsh, Lightcast

Here are some specific quotes from Talent customer interviews:

“Increased pay, benefits, and bonuses have become super popular in trying to attract and retain talent in this tight labor market. Most of this info has been realized anecdotally, not analytically with any type of data.” – Lou Grossi, Volt

“Everyone's end goal obviously is to make money and make revenue, but if you really want to get serious about corporate source responsibility and being wise and honest Talent advisers with companies, both the pay and the benefits have to be viewed equally… Benefits information is gold… If you can call out general benefit trends even if it's at broad labor category areas (‘these benefits tend to go to this class of worker or this type of worker based on job posting analysis’), that's super useful. That's where a lot of companies are missing the mark completely and other companies are really getting into it because they can't keep increasing pay.” – Eddie Beaver, Allegis

Value to Lightcast

The consulting and economist teams in Talent, Community, and Corporate Economists have each conducted research projections to view benefits trends (via job postings) and quantify the total compensation packages (via BLS) across jobs, markets, and industries.

Productizing the work they’ve already done will make it easier and faster for them to conduct the research again for future clients.

Target User Role/Client/Client Category

• Talent and market analysts

• Workforce developers

• Lightcast consultants/economists

Delivery Mechanism

The goal is to productize the work already done by internal AR teams. They’ve each created their own group of benefit categories and queried the postings data with keyword strings. The most in depth classification (see Excel file below) used 8 benefit categories with ~65 unique benefits.

Open

The work to be done would be to consolidate the the AR team’s work and use it as a product springboard. The full delivery would be…

1. Create a small, consolidated, and standardized 2-tiered benefits taxonomy

2. Create classifiers for each of the item in the taxonomy

3. Use the new classifiers to tag all US job postings

4. Make available in JPA API & Snowflake

5. Call API and display the data in a filter and a graph inside Analyst job posting reports

A later phase 2 of this initiative would be to quantify the benefits to see how much they contribute to a total compensation package. This would be leveraging the BLS total compensation survey.

Success Criteria & Metrics

At the end of PI4, I hope to have Items 1 and 2 listed above completed so that we are ready to start tagging the job postings in PI5.

Data Success

The files below are two examples of the AR teams conducting research on benefits in job postings and can be used as benchmarks to measure the quality of data that comes back.

Example 1 was conducted for all US job postings for three particular months. (See tab labeled “Data”)

Open

Example 2 was conducted for all job postings in two industries in five US states from 2018 to 2023.

Open

Aspects that are out of scope (of this phase)

Items 3, 4, 5 and the later phase 2 are all out of scope for PI4.

PART 2

Solution Description

Early UX (wireframes or mockups)

The following mockups are for Analyst only.

Benefits filter on the left side of all job posting reports with browsing ability:

Open

Open

Benefits tab inside job posting table report:

Open

Top Benefits packet inside Job Posting Competition/Analytics with level toggle ability:

Open

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?

Complete with Engineering Teams

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.