JTBD as a Framework for Evaluating AI Investment

Recap of a talk given at The Design Summit, July 2026

If you work anywhere near tech, it’s no secret. The tech sector is absolutely drowning in AI tools, features and initiatives.

As an industry, we’ve been obsessed with figuring out a new way of working with AI. Somewhere in the frenzy to be first on the scene and figure out what was possible, our discerning judgement fell by the wayside. Most of us didn't even know exactly what we needed AI for — we just knew it was suddenly a critical part of how we work. The message from leadership was simple: use AI or fall behind.

So we did.

Now we're burning through tokens. Prices are rising. The free ride is about to be over. We can't keep using every tool and resource indiscriminately without consequence. So the question becomes: what's actually worth keeping, investing in, or building?

Naturally, the question most teams default to becomes: what features does this tool have? What features should we be supporting?

Why feature audits fail

Focusing on features alone is a familiar mistake. One that we’ve all seen before.

Once upon a time, it was a common practice to build websites in Photoshop using the slice feature. We would build an entire web “page” as a single image, slice it into rectangles, and stitch it back together with a table or image map. The end result looked like a website.

The problem was that Photoshop, and specifically slicing an image, was never built for the job of building a website. The text in that image wasn't real text. It couldn't be read by a screen reader, indexed by search, selected, or edited without going back into Photoshop and re-cutting everything. The layout was locked to fixed pixel dimensions, so it broke the moment a window resized.

The job designers were actually trying to do was build content that's structured, readable by a browser and a screen reader, indexable by search, fast to load, and editable without redoing everything from scratch.

"Does this have the features we need?" skipped the only question that mattered. That question is “What job does this feature or tool solve for our user?”

Distinction between jobs and features

Defining the job immediately helps clarify the problem space. As an example, Google Search and ChatGPT both promise to "answer your question." Same feature claim, same marketing language. If we were to evaluate these tools by feature alone, they look interchangeable.

In reality, nobody has a job called "answer a question." The real job is specific. Within a user journey about international travel, one job might be: "I need to check my flight status."

Now we’re getting somewhere. "Answer your question" could mean anything. "Find out if my flight is delayed" is specific enough that you can actually start asking what it requires.

But naming the job isn't the whole answer yet. It tells you what you're solving for but it doesn't give you a way to check whether a tool actually delivers it. For that, you need one more piece.

Capabilities: the translation layer

Capabilities tell us how — the specific type of support needed to complete a job at a specific moment. They're the translation layer between what work needs and what tools do. Without this vocabulary, "what a job needs" and "what a tool does" stay two separate conversations that never quite connect.

Back to Google Search and ChatGPT: it's impossible to evaluate them on "answer your question" alone. But translate each into capability terms, and the picture changes. Google Search's real capability is Retrieve. ChatGPT's, absent any tool access, is Generate.

In practice: Searching "[airline] flight 1234" in Google surfaces flight status directly in results. Information like the gate and delay time are pulled from live data feeds. It retrieves real, current, structured data.

Ask ChatGPT "is my flight delayed" and it can't actually know. It will either say it doesn't have real-time data, or much worse, generate something plausible-sounding with no evidence behind it. In this case, ChatGPT isn't just the wrong tool for the job, it would actively harm the user.

Capabilities are what make a mismatch visible. A job's needs and a tool's behavior can both sound fine described on their own. It's only once you translate both into the same language that the gap shows up.

Attaching a score

Once you can see whether a job's needs and a tool's behavior actually line up, the next question is scale: how much does this particular thing matter? The answer depends on whether you're looking at something already running or something that doesn't exist yet — but the first two factors are the same either way:

• Reach — how many people this touches.

• Impact — what happens if the need goes unmet. Do workarounds exist or is the job unable to be completed?

The third factor changes based on what's being evaluated:

• Evaluating a tool already in place? Use Urgency — if a tool fails, how fast does the need need to be addressed. In what timeframe does the user need to accomplish their job? This generally ranges from real-time to days or weeks.

• Evaluating a feature that doesn't exist yet? Use Business Consequence — what it costs if you never build it. Is the consequence that your users are annoyed or would this actively have a revenue impact or compliance risk?

Without a number, these calls run on gut feel — whoever complains loudest, or whichever pitch is newest, wins the roadmap slot. Criticality turns "this feels important" into a defensible figure you can actually bring into the room.

Putting it on the map

With the job understood, the capability identified, and the criticality scored, all that's left is placing it:

Do the capabilities align with what the job needs?
Depending on criticality, either Protect it (work hard to keep it) or Maintain it (leave it running, low effort).

What if the capabilities don't align?
If it's important enough, Optimize — close the gap. If not, it's a candidate for Deprecation.

What if nothing exists for this job at all?
If it's high priority, Build/Invest. If not, it goes to the Backlog.

The cost of skipping your homework

If you're buying: you pay for capability, not fit. A tool can check every box and still be the wrong shape — so you keep paying for it while your users quietly route around it.

If you're building: you can ship a feature nobody needed, or miss the one that actually mattered, because nobody asked what job it served.

The next time someone asks "should we buy this" or "should we build this," don't start with the tool or the feature. Start with the job. Ask what that job actually needs, in plain capability terms. Find out how users are doing that job today — whether something's already in place, or nothing at all. Find out how much it matters. Then decide, with the evidence in hand.

Job, then capability, then criticality, then decision.

Stop asking what the tool can do. Start asking what the job needs.