When Your AI Breakthrough Doesn’t Save Anyone Time

What job was it being hired for?

I closed MS Teams and logged off. Mid-afternoon on a Tuesday. Just shut it down and walked away from my desk.

A few hours earlier, I demoed a Figma plugin I built for the team. Something to help with design system documentation work. The demo went well. People seemed excited. There was celebration. I felt good.

Then I pinged my coworker to se how it was working and to see if it was saving any time compared to the old way. Nothing official, just a quick check in.

He responded, “oh ya it’s working. Not really saving much time because this is already a quick process. It’s actually pretty easy.”

I messaged another teammate. Same thing. Then he sent me a list of other plugins that would ACTUALLY be time savers.

That’s when I closed Teams.

Illustration showing a blue figure looking through a telescope at code in the clouds while a coral-colored user waves their hands trying to get attention - visualizing how builders can focus on technical implementation while missing what users actually need.

A month later I realized the problem with the plugin was that I never asked “what job was my plugin being hired to do?”

I focused purely on the technical questions like “what does it do” or “how does it work”, but never the Jobs to be Done question: what painful job were people hiring my plugin to solve?

The answer in this case?

Nothing. There was no painful job.

The documentation work was already quick. Already easy. They’d already hired something, their current process, and it worked fine.

I’d built a solution to a problem that didn’t exist.

Illustration contrasting two approaches: on the left, a purple figure calmly holding an organized framework document against a grid background; on the right, a coral figure struggling with a chaotic, teetering stack of blocks amid scribbles and chaos - visualizing the difference between methodical discovery and improvised building.

Over that month, I was working on a different project that was using Jobs to be Done. More formal process: watching users, documenting observations, creating JTBD maps based on what we saw.

The contrast between the two approaches became impossible to ignore.

The JTBD work forced us to ask what should we build? before anything else. What job are people trying to get done? What are they currently hiring to do that job? Why is their solution insufficient?

The Figma plugin? I’d only asked how do I build what I was asked for?

My coworker said “can you build something to help with documentation” and I immediately started thinking: how do I solve this technical problem? What’s the right approach? Can I actually pull this off?

I never asked if documentation was actually painful for them. What’s the current process? Why does it need fixing?

The difference between a real project and an ad hoc request. JTBD led to understanding what we should build. The plugin was just about figuring out how to build the thing I was told to build.

You can read more about the technical side—how I eventually figured out the “how”—in Context is King. But that’s not really the point.

The point is I built something nobody needed because I never asked if they needed it.

What was I actually excited about?

Illustration showing a figure balancing precariously on a chaotic house of cards while holding up an AI globe - visualizing how building AI solutions without understanding user needs creates an unstable foundation destined to collapse.

Why did I jump straight to building?

Honestly, I was excited about seeing if I could build something technical with AI.

Not solving a problem anyone had. Solving the challenge of making it work.

When my coworker asked about the plugin, I heard “Figma plugin for documentation” and my brain immediately went: This is possible with AI. How do I make it work? I need to learn more.

That curiosity is genuine. It’s not about impressing people or proving myself to others. It’s about being genuinely fascinated by what’s suddenly possible.

Wow, this is possible? How do I solve this technical problem?

I got so absorbed in that technical puzzle that I never stepped back to ask whether the thing should exist.

“Your scientists were so preoccupied with whether or not they could, they didn’t stop to think if they should.” - Dr. Ian Malcolm, Jurassic Park

Not quite as dramatic as creating terrorizing dinosaurs, but the principle still stands.

When is that excitement the right response?

Illustration showing a figure running inside a hamster wheel-like geometric sphere labeled “technical puzzle” - visualizing how getting absorbed in solving technical problems can become a self-contained loop that loses sight of whether the solution is actually needed.

Sometimes that absorption in the technical puzzle IS the right move.

Learning. Experimenting. Exploring what’s possible beyond the hype. That matters. That’s how you figure out what AI can actually do.

But sometimes it means I build something nobody needs.

Since I’ve had some time since this realization, I think I’ve come up with some criteria to consider when I’m in this situation:

Illustration showing a purple figure balancing on a seesaw while juggling three shapes labeled “stakes,” “scope,” and “role” - visualizing the framework for deciding when to experiment freely versus when to slow down and do proper discovery.

Stakes: Low stakes, experiment freely. High stakes, slow down and ask questions first.
Scope: Quick one-off for yourself, just build it. Tool for the whole team, do discovery.
Role: Personal learning, follow the curiosity. Professional delivery, follow the process.

Those all make sense when I write them out like this, but in the moment when I’m staring at an interesting technical problem?

I’ll probably still just start building.

Where’s the line?

Illustration showing a teal figure balancing on a seesaw between a yellow cube labeled “tech” on one side and a coral figure labeled “human” on the other - visualizing the challenge of balancing technical experimentation with understanding actual user needs.

I haven’t actually applied Jobs to be Done to an AI project yet.

Partly because I haven’t had the right project. But mostly because the ad-hoc nature of AI experimentation is too exciting. I get wrapped up in figuring out what’s possible. The technical puzzle pulls me in before I remember to slow down.

I’m trying to find the balance between that excitement and working diligently the right way.

I know the formal JTBD process works. It led to understanding what we should build, but it’s hard in the moment to force that intentionality into the puzzle work of AI.

Next time I get excited about building something with AI, I’m going to TRY asking “what job is this being hired for?” first. I’m going to try talking to the people who would use it. I’m going to try asking what’s actually painful about their current process.

But I’ll probably still get absorbed in the technical puzzle immediately. I’ll probably still jump to “how do I make this work?” before I’ve fully explored whether anyone needs it to work.

On the whole side, I might over-correct. I might spend too much time on discovery and kill the experimental momentum. I might lose what makes this work exciting.

I’d rather fail by being too careful than build another plugin that gets a polite “oh ya it’s working” before everyone goes back to their old way of doing things.

But I don’t know if that’s actually true. I don’t know if I’ll slow down when I should. I don’t know where the line is between necessary experimentation and building things nobody needs.

If you’ve figured out how to balance AI experimentation with understanding actual user needs, I want to hear about it. Because I’m actively trying to find that balance, and I don’t have good answers yet.