PART 1

Customer Job to be Done

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 any user, internal or external, needs to choose a date or timeframe, they need to be able to do this in our tool so they can run analyses according to the correct date or timeframe.

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?

Our timeframe selection capabilities are not flexible. Users can’t select the exact dates and timeframes they need, or they need to wait until a certain date to access our data and reports. This equates to bad UX, and the current timeframe selections cause a lot of confusion, which equates to bad UI.

Value to Lightcast

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

This is a usability issue. Making updates like this shows that we care about our clients' workflows and it will help mitigate the need to explain timeframes and to add more custom timeframes. The user will be able to select exactly what they need.

Target User Role/Client/Client Category

Who are we building this for?

Internal and external users.

Delivery Mechanism

How will users receive the value?

The calendar will be available in filters or input pages for reports throughout Analyst. The goal is to replace the current timeframe mechanism in Analyst.

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?

Internal and external users are able to successfully select the exact timeframes they need.

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.

Not known at this time.

PART 2

Solution Description

Early UX (wireframes or mockups)

Figma mockup

Non-Functional Attributes & Usage Projections

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

Not known at this time.

Dependencies

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

Some design work, although we do have a Figma mockup to base the work off

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

These will be applied to all filters and input pages within our reports. We could add a feature flag to test the waters, before implementing the update across the platform.

Risks

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

No known risks at this time.

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.