/
Operia People Pipeline

Operia People Pipeline

 

Created Date

Jun 2, 2023

Target PI

PI5

Target Release

Sept 15, 2023

Jira Epic

Document Status

Draft

Epic Owner

Viktor Kotusenko

Stakeholder

Dean Mendes, Nadine Jeserich, Simon Leroux

Engineering Team(s) Involved

Gazelle-Micro/Devops, Gazelle-ETL

PART 1

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

When consuming Gazelle dataset via Gazelle Web Application or Snowflake, I want to get consistently fresh and comprehensive contact information.

Value to Customers & Users

Delivering a solution to this scale would give customers reliable and comprehensive contact information in a way we’ve not ever delivered. 

Value to Lightcast

The automation would greatly reduce manual efforts and the ability to have multiple sources of profiles deduplicated/merged gives greater stability to vendor reliance.

Target User Role/Client/Client Category

Gazelle Client who needs to get the data on contacts working in selected companies

Delivery Mechanism

Gazelle Web Application

Success Criteria & Metrics

The People Pipeline allows sourcing of new contacts for companies produced as gazelle golden records (NeoETL pipelines output).

The People Pipeline is implemented as a series of Databricks notebooks made available for external orchestration in terms of producing a file that can be sent off for translation. It is optimized for regular re-running.

Part of the assessment of choosing the highest quality contact data includes a review of PDL as an additional or substitute source

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.

Have you thought through these considerations (e.g. data privacy) and raised any potential concerns with the Legal team?

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

  1. Scope the steps still to be completed to have a fully operational and scalable solution in place (including integration with email sourcing solution and pinging microservice)

  2. Identify opportunities for Lightcast teams to offload some of the work in this pipeline, including for QAvScope the steps still to be completed to have a fully operational and scalable solution in place (including integration with email sourcing solution and pinging microservice)


Complete with Engineering Teams

 

Effort Size Estimate

3

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.

Team

Effort Estimate (T-shirt sizes)

Jira Link

Team

Effort Estimate (T-shirt sizes)

Jira Link

Gazelle-Micro/Devops

S

Gazelle-ETL

S

 

 

 

Related content