Jobs to be done, the theory associated with Clayton Christensen, says customers do not buy a product for its features. They hire it to make progress in a specific situation, and they fire it when something else makes that progress better. It is the right lens for a team whose messaging lists features and never says what problem triggers a purchase.

How it works

The method starts with interviews about a real switch: what was happening when the customer started looking, what they tried, what nearly stopped them. Bob Moesta's Four Forces structure those interviews around the push of the current situation, the pull of the new solution, the anxiety about switching and the habit of the present. The output is a job statement in the customer's terms, not a persona.

Jobs to be done is mostly qualitative, and it belongs in a list about product data because the job decides which events matter. A team that knows the job can name the action that shows a user made progress, and that action is the event worth protecting. A team that tracks features without a job ends up with an event for every button and no answer to whether anyone got what they came for.

What it assumes your events already do

Event	What the framework uses it for	What it reports when the event breaks
Activation or First Impact event `first_report_shared`	The first moment the job gets done.	If it is defined as a feature click rather than the job, it measures exploration, not progress.
Core value action `report_viewed`	The job done again: the reason customers stay.	A workaround can outnumber the real job in the data and point the roadmap at the workaround.
Return visit `session_started`	Whether the customer comes back when the situation recurs.	Without it you cannot tell a job that recurs weekly from one done once.

Event names are illustrative; yours will differ. The dependency map shows which other frameworks share each event.

The feature that served a different job

Illustrative example. The company and the figures are invented to show the mechanism.

A scheduling product tracks every feature and finds that its most used one is calendar export. The team invests in more export formats.

Interviews later show why people export: the product's own calendar view does not show their team's availability. The job is seeing when people are free, and export is a workaround. The event count was accurate. Without the job, it pointed the roadmap at the workaround.

Checks before you trust it

Write the job in the customer's words before choosing which events to track.
Name one event that shows the job got done, and protect it as carefully as revenue.
Revisit the job when usage patterns shift; a heavily used feature may be a workaround.
Pair every metric that moves with at least one conversation about why.

Heard in The Question

Interviews in The Question that bear on this framework:

AmirBahador Bahadori: product data is three layers, not one. Product data is three separate layers that answer different questions, and a dashboard pattern is a hypothesis until a person confirms it.
Arash Farhani: the first data he trusts is a testimonial. Before a few hundred users, intuition and testimonials lead, and a number earns authority only once direct contact with clients confirms it.
Maria Petrova: data tells you what happened, never why. Data establishes what happened and never why, and tracking is infrastructure to build before the first real user, not something to add later.
Shahin Katebi: data finds the stuck user, a person asks why. When users are not from the tech world, domain expertise decides what to build, and product data has one narrow job: locating where a user got stuck.
Niko van Eeghen: one metric, three meanings at Evondos. The number is rarely the hard part: one metric means different things to different people, and in parts of the economy you cannot or may not collect it.
Emad Ghorbaninia: five analytics tools or one five-minute call. The data he trusts most is not tracked but asked for, and anything that reaches a client passes a human review first.
Hamid Farmani: talk to people before you track anything. Big organisations earn trustworthy data through interdependence and documentation; solo, he builds that discipline for his agent, and trusts a real person's need first.

Check the events under it

Before Jobs to be done (JTBD) goes into a plan, find out whether the events it needs exist and still fire the way it assumes. The free audit maps what your product collects today: sign in, connect a GitHub repository or Supabase, and Skene returns one audit, with no card. On Pro, Skene Cloud reviews every pull request on a linked GitHub repository for removed or broken tracking, so a pull request that removes or renames one of these events is flagged before it merges.