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 recruiting new employees into my roles, I want to benchmark the types of bonuses being offered by my peers, so that I can offer competitive, market-aligned incentives to attract and retain talent.

 When clients want to benchmark sign-on or other bonus, I want to provide that data for them to make educated decisions.  

Clients have expressed interest in adding more Benefits Data at the Job/Company level. 18/28 Clients said that Benefits data would be ‘Extremely Helpful’  and eight more said they would be ‘Very Helpful.’ ’They want to use this data to ‘Improve Employee Retention’,  ‘Attract more talent’, and to ‘Increase Competitive Advantage.’ Several clients also specifically mentioned Benchmarking.  Of clients who completed the survey and said Benefits data would be “Extremely Helpful” or “Very Helpful” ranked “Incentives” data as the most important. 

The JTBD would be extracting Benefits data from Job Postings Data or developing a web crawler to collect benefits directly from Company websites. 

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?

Pains: The limitations for Extracting Benefits from Job Postings, the current extractor is working at a 91% rate, but coverage might not be great enough to provide useful insights. Switching to Company Level Benefits might create a much larger engineering problem.  

Clients are not able to benchmark offered Benefits against other companies to be confident in their competitiveness, either for employee retention, competitive advantage, or attracting talent. 

Gains: This would provide a reference point for Clients to feel confident in their actions regarding Incentive Benefits (Sign-on/Referral). UPS has specifically mentioned their intention to hire 300,000 new seasonal employees, where sign-on bonus data would be very valuable. 

The 28 Talent clients, to date (10/18/22), who have completed the survey have a median contract value of $58,000, with a max value of over $200,000. Developing and maintaining relationships with large clients like these is a good direction for creating more value. 

Value to Lightcast

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

Having broader Company Benefits Data could help us make better Benefits decisions.

Target User Role/Client/Client Category

Who are we building this for?

The primary target is Talent clients, based on their strong interest in job postings data. A mix of Talent Industries have expressed interest, with a majority from Staffing and Recruiting Clients.

Delivery Mechanism

How will users receive the value?

Up for debate currently. Currently, I think we could incorporate it into JPA, but a separate Benefits page could be developed in time if we continued to acquire Benefits data.

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?

Engineering says we’ve developed an effect extractor/crawler, reached reasonable coverage (ROI not viable) of our accessible Benefits Data and that data is available in Analyst

Client feedback/approval: If usage is lower than expected/reasonable, a follow up survey or interview with select client could be done  

Usage goals: A notable increase in JPA viewership in Metabase and specific usage tracked in Pendo. 

Pendo/Metabase, Typeform/Intercom

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 current initiative is focused on Sign-on/Referral Bonuses, not other parts of Benefits, in terms of collecting data, but some planning for larger Benefits data in the future.

Solution Description

Early UX (wireframes or mockups)

<FigmaLink>

NA

Non-Functional Attributes & Usage Projections

Consider performance characteristics, privacy/security implications, localization requirements, mobile requirements, accessibility requirements

NA

Dependencies

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

Not that I’m aware of

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

Roll out to clients who completed the survey/agreed to an interview. 

Yes, a new type of data should be advertised, especially if we see ourselves expanding in this arena. 

Not sure on the length of Partial Rollout, I wouldn’t guess anything out of the ordinary.

Risks

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

Poorly representing complex Benefits data from Job Postings, as they might be stated in a variety of different ways and if we don’t capture them well, then we’ll be selling med-poor data.

Open Questions

What are you still looking to resolve?

Larger Benefits data framework/interest/value

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.