PART 1

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

When using Lightcast Job Postings API to surface live job postings (Job Board), I need to be able to present a link to the actual job posting to help facilitate my users to be able to actually Apply for this posting which they found using my product. However, oftentimes the URL I get from the Lightcast JPA API is dead. This negatively impacts my credibility as a job board and my users' experiences.

Value to Customers & Users

This is the main call to action for a job board user - click on this link to go to the live job posting and apply. When many links are broken users of our client’s products will stop using them.

Value to Lightcast

This work is important because it’s important to KEEP existing job board clients (primarily Legacy BG users) and grow this segment of our client base for Lightcast. Without a few key investments in this area, we will continue to lose renewals and deals involving job boards. This it a key piece of being able to win in this market and represent a large existing book of business (well over $1M).

Target User Role/Client/Client Category

Clients who need to link to live jobs (job boards).

Delivery Mechanism

Job Postings APIs (US, UK, Canada and eventually Global)

Success Criteria & Metrics

Current expiry spiders run every 10 days. URLs could be up to 12 days old in the API.

Definition of done for PI4:

• De-couple crawlera and non-crawlera expiry runs

  • (currently crawlera cannot be run more frequently than 10 days)

• Evaluate and tune the non-crawlera run frequency. General target would be 5 days, but TBD by the team what is achievable.

• Rank order the ‘active_url’ field - ranking company sources at top, followed by crawlera sources

  • Provide this rank order methodology to Documents team to implement

Stretch Goal:

• Implement increased non-crawlera run frequency

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.

PART 2

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?

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.