Jobs-to-Be-Done Doesn't Stop at the User

You know the deal. The demo went perfectly. The person who'll actually use the product leaned in, asked the right questions, and said some version of "this is exactly what we need." Your champion was sold. And then the deal stalled. Not on a feature gap, not on a competitor, but in procurement, or in a security questionnaire, or in a budget approver's inbox where it sat until the quarter turned over and the urgency drained away.

It's tempting to file that under bad luck or slow process. It usually isn't. More often it's a strategy problem that traces back to one assumption: that nailing the user's job was the same as winning the deal.

It wasn't. In any enterprise purchase, the person who uses the product, the person who approves the spend, the person who clears it on security or compliance, and the person who administers it are rarely the same human. And here's the part teams skip: each of them is hiring your product for a different job.

The user's job is the one you designed for: get the work done faster, with less friction, at higher quality. But the approver isn't hiring your product to do that work. The approver is hiring it to justify the investment to leadership — to defend, in a room you're not in, why this spend was the right call. The security reviewer is hiring it to confirm this meets our standards without becoming the person who waved through the thing that caused an incident. The admin is hiring it to get the team set up without friction, because the rollout lands on their desk and a painful one is their problem for months. Four people, four jobs, one purchase. Satisfy the user's job brilliantly and miss the other three, and you've answered a question that doesn't decide the deal.

This is exactly why a jobs-to-be-done analysis that stops at the primary user systematically misses why deals stall. The failure isn't visible in the demo, because the demo is aimed at the user. It surfaces later, in the part of the process nobody mapped.

And this is the point worth being explicit about. Mapping only the primary user's job is the research-artifact version of jobs-to-be-done: the persona-and-journey-map view that captures how one person experiences your product, then stops there. It's useful, but it treats the job as a deliverable. Mapping the entire buying group's jobs is what turns jobs-to-be-done into the front end of a strategy rather than a research finding, because it's the buying group's jobs, not the user's alone, that determine whether you actually win. You can be the best answer to the user's job and still lose, if the approver can't build their case and the security reviewer can't get to yes.

What makes this practical rather than just a caution is that each performer's job maps to its own requirements and its own evidence to gather. Jobs become prioritized Market Requirements: the specific, measurable things your whole solution has to deliver. The user's job points to performance and workflow requirements. The approver's job points to a different set entirely: the proof points, the references, and the return-on-investment narrative that let them defend the spend. The security reviewer's job points to compliance attestations, data-handling specifics, and the documentation that clears a standards review. The admin's job points to provisioning, onboarding, and support requirements that decide whether the rollout is smooth or quietly turns into churn. Miss a performer and you haven't just missed a stakeholder; you've mis-scoped the strategy, and the requirements you most needed to satisfy never made it onto the list. (The same jobs, sized across your segments by who performs them and how often, also inform the revenue forecast downstream, a secondary benefit rather than the headline.)

There's a reason this gap is so common. Most teams work without a connected structure for any of it — a fragmented patchwork of PowerPoint templates and Excel models, rebuilt from scratch every deal, where the user research lives in one artifact and the procurement reality lives nowhere. Framed as research, the user's job is one more slide in that patchwork. Framed as the front end of a strategy, the whole buying group's jobs become the structure the rest of the analysis is built on. This is the framing we work from, drawn from decades of practitioner experience in corporate innovation and new business development.

So the next time a deal dies after a great demo, resist the urge to blame the process. Ask which performer's job you never mapped — and what requirement you'd have surfaced if you had.

If you want the full treatment of how a job becomes a testable strategy — what a job is and isn't, the competing alternatives it names, and how it maps to measurable requirements — we put it on one page: Jobs-to-Be-Done: The Front End of Strategy.

And if you want to structure the buying group's jobs into a strategy you can defend, that's what Growth Forge® Software is built for. Its Jobs to Be Done tool structures customer jobs across the full journey and the full set of performers; from there the same connected model derives and prioritizes the requirements, surfaces the competing alternatives, and lets you evaluate the strategy against evidence rather than presentation quality. Growth Forge is a free trial away, with a worked example pre-loaded so you're not starting from a blank page.

BRI Associates helps companies grow by drawing on decades of practitioner experience in corporate innovation and new business development — practitioners, not pundits or academics — through direct consulting, training workshops, and Growth Forge® Software, built for the unique requirements of corporate innovation and growth organizations.