Job-to-be-Done or Problem

As a Lightcast Product Manager responsible for revenue associated with Alumni Outcomes as Annual Recurring Revenue, I need to create the foundation for the new 2.0 product into which we can incorporate new data and introduce new experiences while NOT disrupting or changing the experience of current customers on the 1.0 NRR Product.

The foundation includes:

Value to Customers & Users

As in Alumni Outcomes 1.0, Alumni Outcomes 2.0 provides EDU customers with otherwise-hard-to-acquire information about their graduates' career outcomes.

Here’s our Opportunity Summary for AO 2.0

for: Academic Leadership, Enrollment Marketing, and Advancement/Foundations teams

who want to: use alumni career outcome information to support program review, stakeholder engagement, marketing & enrollment, and alumni engagement

so that: they can increase their institution’s enrollment, revenue, reach, and impact

we offer: Alumni Outcomes 2.0 (in partnership with NSC): subscription software with insights on your Alumni

unlike alternatives: which cover fewer of your alumni, lack (or have less granular) labor market information and don’t include powerful workflows or time-saving research tools and visuals.

Value to Lightcast

Building out AO 2.0 and our partnership with NSC allows us to change the business model, revenue category, and impact of our Alumni Outcomes capabilities.

Current TAM calculations for AO 2.0 are as follows:

3,278 buyers x $ 17,000 (average price point) x 33.3% market penetration = $19M

Assume a comparable market size to Analyst (3,278 organizations, per EmsiBI’s Market Penetration by Product report) and ability to penetrate one-third of the market.

Price point based on average values in approved Investment Case (which increase over time)

Target User Role/Client/Client Category

Institutional Research, Academic Leadership, Enrollment Marketing, and Advancement/Foundations teams across all current HE segments.

Delivery Mechanism

AO 2.0 will be delivered as a separate product on the Analyst platform.

Success Criteria & Metrics

We can publish a demo customer’s outcomes to the AO 2.0 DB and allow for interaction with the data in the new application.

Aspects that are out of scope (of this phase)

Differentiated features in AO 2.0. When we finish this epic - AO 1.0 and AO 2.0 will be identical but separate.

AO 2.0 as it exists at the end of this epic should be able to handle the usage and scale of AO 1.0. If performance optimization is needed for anticipated scale, we’ll handle that in a separate epic.

Solution Description

Early UX (wireframes or mockups)

There is no associated UX with this epic.

Non-Functional Attributes & Usage Projections

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

AO 2.0 as it exists at the end of this epic should be able to handle the usage and scale of AO 1.0. If performance optimization is needed for anticipated scale, we’ll handle that in a separate epic.

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

There is no customer-facing rollout associated with this epic.

Internally, We’ll ensure that AO Product and Solution specialists know how to use AO 2.0 and AO 1.0 tools and have a mechanism for associating a customer account with one or the other.

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.?

• Cost of cloned Elastic Search database (at typical AWS costs)

  • Previous costs can provide a reference – we expect to have more rows uploaded, so the costs will eventually be ~2x the cost

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.

Back-end:

• Medium (~1 week? + iteration and testing time with David for up to ~1 week)

Notes:

• Anticipate continuing to use Elastic Search

• Clone existing database

• Potential small schema changes (will break percentage calculations on front-end)

  • this will have front-end implications (e.g. calculations based on number of records)

• Branch off a separate uploader (that supports more records and new schema)

  • fork code, start fresh