The jobs to be done resurgence: What users hire products to do vs what teams think they are building

The most dangerous competitor you will face this year does not have more features than you. They have fewer.

This should be counterintuitive. Product teams spend enormous energy expanding capability, adding integrations, broadening scope. The assumption is that the product with the broadest coverage wins. More features means more use cases. More use cases means more customers. More customers means the strategy is working.

But users do not switch to better products. They switch to more precise ones.

That sentence explains more lost deals, more churned accounts, and more market share erosion than any competitive analysis deck I have ever read. And it is the reason jobs-to-be-done thinking is having a resurgence right now, at the exact moment when AI is making it trivially easy to build products that do one specific thing extremely well.

The breadth trap

I watched this play out at Freshworks in a way that still bothers me. The CRM product was built to do everything. Email, phone, chat, social media, analytics, workflows, reporting. The pitch was compelling: one platform for your entire customer engagement stack. No more switching between tools. No more data silos. Everything in one place.

On paper, it was a strong strategy. But in the market, something else was happening.

A competitor, much smaller, had built a tool that did one thing: email sequences for outbound sales. That was it. No phone integration. No social listening. No analytics dashboard. Just email sequences, done with obsessive precision. The templates were better. The scheduling was smarter. The deliverability was higher. The reporting on open rates and reply rates was tighter and faster.

And they were capturing the exact segment we were losing.

The sales team kept saying we needed to improve our email features. But that framed it as a feature gap, which it was not. The real issue was a job gap. Those users were not hiring a CRM. They were hiring a tool to run outbound email sequences. And when you are hiring for a specific job, you do not want the generalist who can do a bit of everything. You want the specialist who has done that one thing a thousand times.

It is the same reason you choose a surgeon over a GP when you need a specific procedure. The GP understands your whole body. The surgeon understands your specific problem. When the stakes are high enough, precision wins every time.

I call this the breadth trap. The belief that adding more capability makes a product harder to leave. In reality, breadth makes a product easier to replace in any single dimension. The broader you go, the more surface area you expose to a competitor who goes deeper on the one thing that matters most to a specific user.

Precision as a switching trigger

Here is what makes JTBD thinking so urgent right now. AI has collapsed the cost and time required to build a product that does one job exceptionally well. A year ago, building a specialised tool for a narrow use case required a funded team and months of development. Today, a solo founder with the right instinct can ship something in weeks that does a single job better than an incumbent's version buried inside a platform.

The proliferation of AI alternatives is not creating better products across the board. It is creating more precise products for more specific jobs.

But most incumbent teams do not see it this way. They see a new competitor and ask: do they have feature parity? The answer is almost always no. And the team relaxes. But feature parity is the wrong question. The right question is: do they do the specific job our users hired us for better than we do? That question produces a very different answer.

At Schneider Electric, I worked on an IoT thermostat. Our product did one job: maintain a comfortable temperature with minimum energy consumption. That was the job users hired it for. Control the temperature. Save on the energy bill. Simple.

Competitors had products with ten additional features. Lighting control. Security cameras. Voice assistant integration. Their product roadmaps were impressive, full of connected home visions and feature expansion plans.

But users hired a thermostat to control temperature.

Our product beat competitors with far broader capability because it did the one job users cared about with more precision. The interface was clearer. The energy savings were more visible. The scheduling was more intuitive. When you are cold and you want to be warm without spending too much, you do not want a smart home hub. You want a thermostat that works.

Nobody ever hired a product to do everything. They hired it to do one thing they could not do themselves.

What teams think they are building vs. what users are hiring

The gap between what a product team believes they are building and what users actually hire the product for is the most expensive misalignment in product work. It is also the most common.

Teams build for the vision. Users hire for the job.

At Freshworks, the vision was a unified customer engagement platform. But a significant portion of users had hired it to send outbound emails effectively. At Schneider Electric, the vision was a connected smart home component. But users had hired it to keep their house at the right temperature without thinking about it.

The vision is not wrong. But it is not the job.

JTBD thinking forces an uncomfortable question: if a user could hire anything to do this one job, would they still choose your product? Not your platform. Not your brand. Your product, for this one task. If the answer is not a confident yes, you have a precision problem, regardless of how broad your capability is.

This is what I call the precision advantage. It is not about building less. It is about understanding what the user actually hired you for, and being so good at that one thing that switching to a broader alternative feels like a downgrade.

The hard part about doing less

The precision advantage sounds simple. It is not. Because every product team faces the same gravitational pull toward more. More features get requested by sales. More integrations get demanded by enterprise buyers. More capability gets pitched in board meetings as competitive positioning. The entire organisational incentive structure pushes toward breadth.

But every feature you add that is not the core job dilutes your precision. It adds complexity to the interface, cognitive load for the user, and surface area for a competitor to beat you on the one dimension that actually matters.

The hardest product decision is not what to build. It is what to refuse to build, knowing that the refusal protects the one thing your users actually hired you for.

I have gotten this wrong more often than I have gotten it right. At Freshworks, I was part of the team that kept adding capability because the sales org said we needed it. At Schneider Electric, we had the discipline to stay narrow, and it worked. The difference was not intelligence or strategy. It was honesty about what users were actually hiring us to do.

Products do not die because they lack features. They die because they lose clarity about the job they were hired to perform. And in a market where AI is making it easier every month to build a more precise alternative, clarity about the job is not a strategic luxury. It is the only defensible position.

The teams that will hold their ground are not the ones with the biggest feature lists. They are the ones who can answer a four-word question without hesitating: what job, done well?