WHAT NEEDS TO BE TRUE FOR GOALS TO BECOME REALITY

Written by Jessica Murray

I spent a good part of December in annual planning mode for Empower, our partners and a few outside initiatives. The support those efforts, in a couple of instances, I repurposed a common product development framework and put a twist on it. The result was an effective method to match strategic objectives and goals with the actual work required to execute those things.

The framework? Jobs to be Done (aka JTBD).

Before diving into my spin on JTBD, a quick bit of context on where this framework comes from and its standard use.

What is JTBD?

JTBD originated in product and innovation circles to help teams understand why people choose certain products and services. The core idea: People don’t buy goods or features, they “hire” things to get a job done.

In standard applications, JTBD is external-facing, and centered on users, customers and markets. In other words, “jobs” belong to those stakeholders; not the company. The purpose is to guide strategy, roadmap decisions and customer research.

Typically, teams build up a series of well-structured JTBD statements that clearly define:

• The Job: Progress someone is trying to make.

• The Situation: Timing, constraints or environment that make this job necessary.

• Desired Outcomes: What success looks like when the job is done.

• Alternatives*: What people do now to get the job done, and what’s given up by choosing one path over another.

• Forces of Progress*: JTBD surfaces change, so there’s a push, pull and inertia that require consideration.

These statements give teams a shared reference point for discussion around outcomes.

A quick example:

When I need to prepare a weeknight dinner (Situation)

I want to get a healthy meal on the table quickly (Job)

So I can move on with my evening, satisfy my family and avoid stress (Desired Outcomes)

*These aren’t explicitly written in the statements, but are considered and discussed.

My “spin” and how it’s been working

The approach

I’ll focus on one use case.

While working with a lean, fast-moving startup, aiming to accomplish a lot in the first half of the year, we needed a much clearer way to match up desired milestones with the cross-functional work required to deliver them.

The challenge brought me back to my last in-house product strategy role, and naturally, to JTBD.

Even though the framework’s core use case centers around the external customer, not the company, I saw an opportunity to apply similar principles for internal execution planning.

So that’s what I did. After seeing its effectiveness, I applied it again in other contexts before 2025 came to a close.

How it came together

So how did this actually come together, and how is it being used?

I’ll keep it high-level, but reply to this email if you want more detail.

• Step 1: Opened a Google Sheet (choose your favorite spreadsheet)

• Step 2: Built the shell of the sheet with the following columns:

  • Function / Department

  • Sub-Function

  • Product Line / Customer Type / Initiative

  • JTBD (i.e., a discrete piece of work that needs to be completed in order to accomplish an objective)

  • Description of the JTBD

  • Accountable Leader

  • Job Owner (i.e., the person(s) actually doing the work)

  • Timing

  • Priority

• Step 3: Reflected on how we were defining:

  • 2026 success and milestones

  • Q1 company objectives

  • The product roadmap

• Step 4: Based on the Q1 objectives, I took a first pass at a comprehensive list of “jobs” required across each department.

• Step 5: Got leadership input to make sure nothing was missing, misrepresented or unaligned.

• Step 6 (still in process): Taking all of these inputs and driving decisions related to:

  • Resource optimization and hiring needs

  • Roadmap prioritization

I’m confident this exercise will better position this team to make more informed decisions and trade-offs in 2026. It has also created far more cross-functional visibility into what it actually takes to deliver a feature, launch a marketing program, operationalize an initiative, and more.

Frameworks are tools. They don’t have to be rigid. If you surface an optimal way to leverage one for your specific team and needs, I say go for it!