PART 1

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

Talent Job-to-be-Done

As a Recruiter with a particular job to fill, I want to know where the best location is for me to target my recruiting efforts by comparing how difficult it is to fill this job across a set of different regions. Lightcast data helps me make that decision, but it requires a lot of effort to find actionable insight from the data. I can rank markets based on supply, demand, compensation (descriptive), but not by how hard it is to hire a job (prescriptive).

Community Job-to-be-Done

As an economic developer, I want to compare how hard it is to fill a job in my region to the difficulty to fill the same job in competitive regions, thus providing insight that may help me highlight the strengths of my region. I want a single metric to help me understand the differences in difficulty to fill.

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?

Having the ability to rank markets by a single hard-to-fill metric gives users effortless access to real insights that directly affect their decision making. A few of our clients with data analysts have gone so far as exporting our data and creating their own hard-to-fill ranking because we don’t do it.

Value to Lightcast

Sometimes we do things for our own benefit. List those reasons here. 

• Lightcast will be seen as a leader who helps guide our customers with data (prescriptive) instead of letting customers figure out problems on their own with data (descriptive)

• Having a central metric for difficulty to fill will solve various teams, consultants, etc. creating their own

• Enables us to drive a narrative on difficulty to fill that is not solely reliant on our success at calculating posting duration (TTF).

Target User Role/Client/Client Category

Who are we building this for?

• Talent Acquisition

  • Market Strategists (both for TA specifically and site selection for new offices)

  • Recruiters/Sourcers

• Staffing

  • Market Strategists (both for TA specifically and site selection for new offices)

  • Sellers

  • Recruiters

• Real Estate

  • Site selectors

• Economic developers

Delivery Mechanism

How will users receive the value?

The future goal is to give Analyst users a HTF market index where weights are applied to certain metrics to determine a score ranking across different regions, and give users the ability to change the weights according to their values/priorities (for example, compensation might not be a highly weighted factor to a large company like Amazon, but it’s definitely a highly weighted factor to a small local company).

The question is how do we create such an index.

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?

The definition of done for this PI will be to have a clear understanding of …

1. the metrics and the beginning weights that are used to define a HTF market index

2. the architecture for how to create this index for eventual consumption

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.

• Hard to Fill Jobs (location x occupations) – comparing difficulty to fill across different jobs within a single location (This will be needed in the future for alternative pathways models)

PART 2

Solution Description

Early UX (wireframes or mockups)

Data wireframe:

Option 1: HTF market comparison based on the following metrics:

• Duration (last 12 months)

• Salary Growth (12 months v prior 12)

• Posting growth (12 months v prior 12)

• Advertised salary (last 12 months)

Create a composite index and rank. This enables comparison of a single occupation across like locations (state v states, county v counties, etc). https://docs.google.com/spreadsheets/d/10e8AMAjftA5LgyqiMt4SD3xF_lZ1lddg/edit?usp=share_link&ouid=116342619760648830776&rtpof=true&sd=true

Option 2: HTF market comparison based on SmartReq metrics.

Option 3: HTF market comparison based on Applied Research team’s metrics.

Option 4: HTF market comparison based on Models team research.

Non-Functional Attributes & Usage Projections

Consider performance characteristics, privacy/security implications, required copy translations (mostly surveys), mobile requirements, accessibility requirements

No.

Dependencies

Is there any work that must precede this? Feature work? Ops work? 

Negative.

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

No, not at this time.

Risks

Focus on risks unique to this feature, not overall delivery/execution risks. 

The only risk would be working on something that may not come to fruition.

Open Questions

What are you still looking to resolve?

• Is it worth piggy backing off of Micro's framework for their soon-to-be PI2: Index API - MVP? Or do we need to think of a separate framework/model that’s specific to this use-case.

• Regardless, there are still unresolved questions/issues:

  • Comparative regions

  • Scoring mechanism