PART 1

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.

As a staffing account manager with SmartReq, when trying to convince my client that the pay rate they’re offering is too low and won’t attract the experienced talent they’re seeking, I want to show them the experience level their pay rate will actually attract so that I can hopefully convince them to raise their pay rate, thus making it easier for me to find the right talent with the right experience.

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?

Staffing users will be able to be more consultative to their clients when they’re able to benchmark the client offering wage against what’s in the market.

Value to Lightcast

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

• Improved reputation among staffing clients. We’ve been telling them that this is coming for the past year. We really want to get this out the door and in the hands of users.

Target User Role/Client/Client Category

Who are we building this for?

• SmartReq users (Staffing Sellers and Recruiters)

Delivery Mechanism

How will users receive the value?

• Originally planned to consume the Market Salary model, we’ve pivoted to instead consume the legacy Compensation model (using years of experience as a proxy for experience levels).

• In addition to wages from the Comp model, we will adjust by Employment Cost Index (ECI) scores.

  • Wage by Years of Experience × ECI %

• Last year, Peter Peck (a legacy Analyst engineer) built a prototype graph in SmartReq using the Compensation model that we originally ditched for the Market Salary model. It’s possible for us to revive his MR and reuse most of his work from the prototype.

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 wage by experience meter is client facing for all SmartReq users

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.

• This is limited only to SmartReq. Anything related to other parts of Analyst are outside of the scope.

PART 2

Solution Description

Early UX (wireframes or mockups)

SmartReq

Open

Non-Functional Attributes & Usage Projections

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

• Feature flag for testing new wage results

Dependencies

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

• @David Beauchamp gathers the ECI data and create the fields in Reqify API

• Micro exposes the ECI field in the Reqify API

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

We can release this internally first via feature flag to make sure we don’t run into any issues for a week. Then release to all customers. Talent Marketing will be notified at least a week before internal release.

Risks

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

• We can’t revive Peter’s prototype from his old MR

• After we adjust the wage data by ECIs, the data doesn’t pass the sniff test

Open Questions

What are you still looking to resolve?

• Can we revive Peter’s prototype from his old MR

Complete with Engineering Teams

Estimated Costs

Direct Financial Costs

Are there direct costs that this feature entails? Dataset acquisition, server purchasing, software licenses, etc.?

NA

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.