Agile Backlogs: Features in Search of a Job

There’s a moment every product team hits, usually somewhere around their third “alignment meeting” of the quarter, when someone says a sentence that sounds responsible and is actually fatal: “Let’s just put it in the backlog.”

Once something becomes a ticket, it gains a kind of immortality. It can sit there for months collecting dust, occasionally resurfacing when a stakeholder asks about it again. Because it exists as work, it feels like progress — even when nobody can explain why it matters beyond “we should probably do it.”

That’s how backlogs rot.

Agile backlogs are engineered for output, not meaning. They are excellent at turning requests into tasks. They are terrible at protecting you from building features in search of a job.

And if you’ve ever shipped a perfectly competent feature that nobody uses, you’ve already lived the punchline: execution quality doesn’t rescue you from job confusion. It just makes the waste prettier.

Let’s make it painfully concrete.

A very normal backlog, in its natural habitat

Imagine a B2B workflow product. Could be a project tool, an ops tool, a content tool, doesn’t matter. The backlog looks like every backlog on Earth:

• “Permissions & roles”
• “Notifications overhaul”
• “Reporting dashboard”
• “Onboarding improvements”
• “Integrations: Salesforce, Drive, Zapier…”

If you ask why these exist, you’ll get sincere answers: sales says something is blocking deals, support says people are confused, the biggest customer asked, a competitor has it, someone calls it “table stakes.”

Those are not whys. Those are sources.

They tell you where the request came from. They don’t tell you what progress the user is trying to make, or what situation makes the request urgent, or what “good” even means in that moment.

So the team does what teams do: they break each epic into smaller tickets, estimate them, and start delivering.

And here’s the trap: the more efficiently you execute, the less you notice you’re lost. A backlog can be “healthy” in Jira and completely sick in reality.

What Jobs do to a backlog

A JTBD lens doesn’t ask “what should we build next?”

It asks: what are people actually hiring this product to do — and in what situations do they fire it? That sounds philosophical until you apply it to a backlog, and then it becomes real.

When you translate feature tickets into job statements, one of two things happens immediately:

• The ticket becomes obviously important, because it protects job completion in a high‑stakes moment.
• Or it becomes obviously nonsense, because it’s a solution looking for a problem.

The backlog stops being a pile of work and becomes a set of bets you can actually argue about.

Take the epic that shows up everywhere: “Permissions & roles.” The feature‑first version is always the same. It’s a list of knobs: custom roles, granular permissions, view‑only mode, audit logs. The stakeholder story is usually, “enterprise needs this.”

But “enterprise needs this” is not a job. It’s a label you slap on anxiety.

Underneath, in most products, permissions aren’t bought because someone loves permissions. They’re bought because someone is trying to make progress on a social, high‑risk job: “I need to share this work and get it approved without getting blamed when something goes wrong.”

That is the Job.

Once you name it, the epic reorganizes itself.

Audit logs stop being a compliance checkbox and become a trust mechanism: proof in case something breaks. View‑only is the line between safe review and chaotic collaboration. Granular permissions are no longer an end in themselves; they’re a late‑stage refinement once the basic approval flow is safe and understandable.

Same ingredients. Completely different meaning. And meaning is what changes priority.

Priorities change when you rewrite a slice

Feature‑first prioritization works like this: the loudest deal shouts “permissions,” so you build custom roles. Another deal shouts “reporting,” so you build dashboards. Churn complaints mention “notifications,” so you do an overhaul. Someone says onboarding is leaky, so you add tours and tooltips.

It feels rational. It’s actually reactive.

A Jobs‑first prioritization makes you pick which job you’re committing to win, and which jobs you’re willing to lose for now. You can’t “do everything.” You can only win a few moments that decide adoption and re‑hire.

So instead of asking “which epic is most requested,” you ask questions like: which job is most intense right now? Which moment is most likely to get us fired? Which work creates compounding value across multiple requests?

If the job is “get approval without drama,” the first thing you build is almost never “custom roles.” It’s the earlier, leverage‑heavy pieces that actually change that moment:

• A share‑and‑review experience that doesn’t require full‑org adoption.
• Defaults that prevent accidental edits and mis‑shares.
• A clean “what changed since last time” view for reviewers.
• A lightweight audit trail that answers the unspoken question: “If this goes wrong, can I prove what happened?”

Once that works, you can invest in deeper permission complexity. You’re building for the moment that determines whether the product gets hired again.

A concrete rewrite: digest emails

Pick a ticket that seems harmless and shows up in just about every backlog: “Add digest emails.”

Feature‑first, it’s a quick win. A little engineering, some templates, ship it, tell customers you listened. Jobs‑first, you stop and ask what job a digest is actually serving.

Usually it’s something like: “I need to stay on top of what changed without babysitting the tool.”

That job has a very specific definition of “good.” Not “I received an email,” but “I can re‑enter, find what matters, and act fast.”

If your product can’t reliably detect what matters, a digest is a noise cannon. If your deep links don’t land someone in the exact context where a decision is needed, the email creates frustration, not progress. If your re‑entry experience is weak, the digest is just a reminder that the product is hard to use.

Seen through that job, the plan often changes. Instead of building digest emails first, you build the internal re‑entry spine:

• A clear “what changed since you last looked.”
• Some notion of “this needs your attention.”
• Links that drop someone into the exact thread, not the top of a project.

Then — only then — the digest becomes an amplifier for an already‑good experience. This is where JTBD thinking saves you from “cheap features” that create expensive disappointment.

Cutting gets easier, not harder

The best part of rewriting a backlog through a JTBD lens isn’t the new priorities. It’s how easy it becomes to cut without feeling arbitrary. Once you’ve named the job, you have a standard: Does this help someone make progress on the job we’re trying to win, in the context where it actually matters?

If the answer is unclear, it’s drift.

This is the moment you realize the backlog is full of features that aren't wrong per se, they’re just unmoored. They’re the byproduct of too many conversations where “why” was replaced with “put it in Jira.”

Jobs give you permission to stop pretending that every request deserves to live. You’re not saying “never.” You’re saying “not for the job we’re committed to right now.”