JTBDUX As A Strategy Filter: How To Decide What Not to Build

Every product team has a backlog full of nice ideas.

Not bad ideas. Not obviously wasteful ideas.

Nice ideas.

The kind that sound reasonable in a meeting. The kind that get a “Yeah, we should probably do that” from everyone in the room. The kind that steal a month of design and engineering attention, and then ship with a resounding thud.

JTBDUX is how you stop building those nice ideas. JTBDUX is the convergence of Jobs-to-be-Done and UX into a shared decision language.

In JTBDUX, a roadmap item doesn’t earn its place by being requested, or exciting, or easy to ship. It earns its place by doing one thing: Helping users make progress in the Job they hired the product to do—without creating new fear, confusion, or effort that cancels out the value.

The backlog problem

The issue isn’t that teams have too many ideas, or even too few. It’s too many undefended ideas.

Most roadmaps are built on soft logic or feelings:

• “Customers asked for it.”
• “Our competitor has it.”
• “This would be cool.”
• “It’s not that hard.”

None of those statements are about user progress. They’re about internal pressure.

And internal pressure is infinite. If you don’t have a filter, you don’t have a strategy—you have a list.

JTBDUX gives you a filter that’s hard to argue with because it’s grounded in the same shared language across the team:

• What job is the user trying to get done?
• What situation triggers it?
• What’s pushing them away from the current way?
• What’s pulling them toward a new way
• What habit keeps them defaulting back?
• What anxiety makes them hesitate?
• What emotional stakes are on the line—trust, confidence, safety, competence, reputation?

When you can answer those questions, you can kill “nice ideas” early—before they steal your ROI.

The nice idea problem

Nice ideas don’t map to a real situation. They sound valuable in the abstract, but nobody is desperate for them at the moment they’re trying to make progress.

Take this request: “Add more customization.” This is a pretty common nice idea in SaaS.

But customization on its own doesn’t serve the Job.

It’s a request that hides multiple situations:

• When I’m setting this up for my team, I need it to match our workflow…
• When I’m trying to look professional in front of a client…
• When I’m power-using this daily and the defaults slow me down…

If you can’t name the situation, you can’t design the right solution.

You’ll build “settings” instead of helping users make progress.

Nice ideas also tend to serve the wrong layer of the job

A lot of roadmap items improve functional capability while hurting or ignoring  the emotional job.

For example, take this idea: “One-click auto-send with AI.”

On paper, it’s pure efficiency. In reality, in many products, it’s a trust disaster.

If the user’s emotional stake is “don’t embarrass me / don’t make me regret this,” then removing that last moment of control increases anxiety so much that adoption drops.

You built a speed feature and created a fear problem.

JTBDUX catches this early because it forces you to surface the emotional stakes before you commit to the build.

The JTBDUX filter in practice

Let’s say a product team brings a nice idea into the roadmap review:

“Add an AI ‘Auto-Respond’ button for customer emails.”

A normal roadmap discussion asks:

• how long will it take?
• how many users requested it?
• is it competitive?

A JTBDUX roadmap discussion asks something else first:

“What job is this really serving?”

The Job here isn’t simply “reply to email.” The real job might be: “When I’m drowning in support tickets and I’m scared customers will churn if I don’t respond quickly, I want to reply fast without sounding careless, so I can protect trust while keeping up.”

Now we have stakes:

• urgency (drowning)
• risk (churn)
• fear (sounding careless)

JTBDUX also asks: What forces are actually at play?

• Push: what’s frustrating about the current way (too many tickets, slow response time, stress)
• Pull: what’s attractive about the new way (faster replies, less typing, consistency)
• Habit: what keeps them stuck in the Status Quo (copy-paste templates, personal drafting style, muscle memory)
• Anxiety: what makes them afraid to change (AI might sound wrong, might promise the wrong thing, might create liability)

If anxiety is high, “Auto-Respond” is not a feature—it’s a risk. And then – and this is really important – JTBDUX asks: What’s the emotional job we must protect?

In the case of an AI-powered auto-responder, that Job might be feeling professionally competent and smart. The user doesn’t just need faster replies. They need to feel confident they aren’t about to send something that damages a relationship.

And so the JTBDUX conclusion might be: Don’t take away the AI, but don’t do auto-send.

A “nice idea” (instant automation) turns into a better execution decision:

• draft suggestions
• a tone selector
• a preview step
• highlight risky phrasing
• easy edit and undo
• training the system on approved language

You still deliver pull (speed), but you reduce anxiety (control). That’s the tradeoff JTBDUX makes visible before you build the wrong thing.

When JTBDUX becomes your strategy filter, certain team rituals change for the better.

Backlog prioritization stops being feature sorting

Instead of ranking items by “value” (which always becomes subjective), you rank by:

• which items unblock user progress fastest
• which items reduce the biggest anxieties
• which items remove the most common demotivating friction
• which items deliver the earliest relief

Roadmap reviews stop being politics

Roadmap meetings are usually where competing internal narratives fight.

JTBDUX replaces narrative fights with a shared language. You can still disagree. But you’re disagreeing about the user’s reality, not your preferences.

And that’s a disagreement you can resolve with evidence.

Sprint planning stops being only about shipping features

A sprint goal becomes:

• “Reduce abandonment in first-use by removing the setup tax”
• “Increase confidence at the moment of commitment”
• “Make progress visible so users know it worked”

Nice ideas will never stop coming. That’s normal. JTBDUX is how you keep them from stealing your roadmap—by forcing every idea to earn its place in the only way that matters:
Does it help users make progress in the job they hired you for, without creating new fear, confusion, or effort that cancels out the value?