Jobs-to-Be-Done Research for a Five-Person Firm
Before buying an AI tool, diagnose which broken workflow actually limits what your firm can do.
A five-person firm asking "what AI tool should we try?" is asking the wrong question, and the wrong question is why 85% of AI and machine learning projects, according to Gartner, fail to produce a return. The failure traces to scoping, and the fix is a method called Jobs-to-Be-Done, borrowed from product strategy, repurposed here to answer a much narrower question: before you buy anything, what job is actually broken?
Wrong scope looks predictable once you've seen it a few times. A firm sees a competitor announce an AI chatbot and decides it needs one too, ignoring the fact that the competitor has a different client base and a different bottleneck. Sometimes a firm falls for the flashiest demo, the one that generates a slide deck in nine seconds, and buys it, only to find that slide decks sat outside the real constraint entirely. Most commonly, a firm bolts a tool onto a workflow that was broken before the tool arrived, which means the workflow is still broken, just now with a subscription fee attached. Each of these traces back to a diagnosis problem, and JTBD is the diagnostic.
What Jobs-to-Be-Done actually means and why it fits AI selection
Clayton Christensen's original formulation is simple: when you buy a product, you "hire" it to do a job, and if it does that job well, you hire it again. Fail the job once, and you're fired, usually without severance. A "job" in this sense is the functional outcome someone is actually trying to achieve, independent of any tool. Christensen's famous example was a milkshake chain that discovered its shakes were being "hired" by commuters for a long, boring drive, not by kids after dinner. Nobody on the product team could have guessed that from a taste test.
That's what makes JTBD useful here. It's technology-agnostic by design; it asks what the underlying need is and holds the vendor question until the actual problem has a name. Firms that use jobs-based approaches see something like an 86% success rate on new initiatives compared to roughly 17% for feature-driven approaches, and the gap exists because JTBD surfaces real demand instead of surface-level preference. Applied to AI, the question becomes: "what job do we keep failing to finish, and what changes if we finally finish it?"
Any team can run this method without a research department. The method was built to be run by the people who already do the work, which is fortunate, because a five-person firm has five people and a deadline.
The four forces that explain why small teams stay stuck in broken workflows
Every switching decision, AI included, gets pulled by four forces: push, pull, anxiety, and habit. Push is the frustration with the current setup. Pull is the appeal of the new option. Anxiety is the fear that the new thing breaks something or wastes money. Habit is the sheer gravitational pull of doing it the way you've always done it, even when the way you've always done it is bad.
In a five-person firm, habit usually wins, and it rarely loses to cost or complexity the way people assume. Habit wins because someone spent real hours learning the current spreadsheet macro, because the whole intake process quietly reorganized itself around that macro's quirks, and because the workaround eventually became indistinguishable from the job itself. People remember only that this way, annoying as it is, works well enough not to touch.
Consider the stat that among firms with fewer than five employees, 82% cite "AI is not applicable to our business" as their main reason for staying out. That is habit dressed up as analysis. JTBD interviews are built to catch exactly this, because they surface all four forces explicitly instead of letting habit disguise itself as strategy. Knowing which force dominates tells you something a tool audit cannot: whether your real obstacle is finding the right AI, or getting five people to stop doing something they've done for six years out of muscle memory.
How to run JTBD interviews inside a small firm without a research team
Start with your own team, then interview the clients who touch the workflow you suspect is broken. You are pattern-matching around a specific moment of friction, and ten to fifteen "switch" interviews will surface the overwhelming majority of what's actionable. A five-person firm can hit that number by talking to its own staff plus a handful of regulars, in an afternoon or two, without hiring anybody.
A switch interview looks for one specific moment: a time the process failed the person, or cost them something real. Ask what triggered the frustration. Ask what they wished they could do instead. Then ask what stopped them from fixing it sooner, because the answer is often habit or anxiety, and interviewees will say "I just never got around to it" when what they mean is "I was scared to touch it."
Three questions do most of the work: "Walk me through the last time this took longer than it should have." "What do you do when this breaks down?" And the important one: "If that problem disappeared tomorrow, what would that let you do that you can't do now?"
That last question reveals whether a friction point is a mere annoyance or a true bottleneck. An annoyance, once removed, saves time. A bottleneck, once removed, changes what the business can take on, quote, or deliver. AI can help with the synthesis, transcribing calls, clustering themes, but it cannot conduct the interviews for you. Talking to people is still the part nobody's figured out how to automate. Budget two weeks for the whole sprint, since that's realistic for someone running a business, not writing a dissertation.
What you're looking for: the bottleneck that changes capability, not just cost
JTBD interviews will surface a pile of friction points, most of which fall below the threshold of your firm's limited attention, and the entire point of the exercise is choosing the one with real leverage.
Ask this: does solving it save time, or does it remove a ceiling? Time savings mean the same output happens faster, which is nice, and bounded. Ceiling removal means the team can do something it structurally could not do before, quote more jobs, add a service line, respond at a pace that was previously impossible. Listen for lines like "we turn away work because we can't process it fast enough," or "we'd offer that service but nobody here can do that part," or "that decision always sits on one person's desk and everything backs up behind it." Those are ceilings.
Contrast that with complaints about a clunky tool that has an easy manual workaround, or a slow task that doesn't block anything downstream. Annoying, sure, but a different category from the job.
The clearest illustration comes from an insurance brokerage where manual data entry was eating most of the quoting cycle. Automating that entry saved hours and let the team run multiple quotes at once, which changed what business the firm could actually bid on. The output of this whole exercise isn't a ranked list of gripes. It's one sentence: when [situation], we need to [outcome], so that [consequence that actually matters].
Why the SMB AI adoption numbers reveal a method problem, not a technology problem
Small business AI adoption has moved faster than any prior technology wave, rising from 6.3% to 8.8% between February 2024 and August 2025, while large-business adoption sat flat around 10.5%. The gap is closing, and fast. Among growing small businesses, 83% report using AI, compared with 55% of businesses in decline; the correlation between adoption and trajectory is no longer theoretical, it's measurable.
Adoption and transformation are two different things. Roughly 74% of SMBs report some productivity gain from AI, yet for most, that gain hasn't cracked 25%. That gap, between having AI and having AI doing the one job that matters, is exactly what JTBD is built to close. Look at what firms are actually doing with AI in 2025: 68% are poking around features already bundled into their existing software, 63% are trying to figure out where AI creates the most value. That second number is the JTBD question, asked by instinct, without the method behind it. The firms pulling ahead of that pack are applying the same software to the right job first, which proves harder in practice than it sounds, given how few firms do it.
The embedded implementation gap that JTBD research alone can't close
A job statement still needs a deployment. Knowing exactly what needs to happen and having it running in production are two different projects, and the distance between them is where most small-firm AI efforts quietly die.
Large enterprises close that gap with something called a Forward Deployed Engineer: a senior engineer parked inside the client's environment, wiring the AI into real data, real logins, real messy workflows. Job postings for this role exploded in 2025, concentrated mostly at startups with 11 to 200 employees, but the engineers labs actually dispatch go overwhelmingly to large, regulated accounts. The math explains why: an engineer costing $350,000 to $550,000 a year in total compensation cannot break even on a five-person firm's budget. It's like hiring a Michelin-starred chef to make you a grilled cheese; the skill is real, the unit economics are not.
What small firms get instead, as one industry observer memorably put it, is "sparkling Sales Engineering," a demo full of enthusiasm and a handshake that evaporates the moment the invoice clears. Meanwhile, 66% of SMBs report AI saving between $500 and $2,000 a month, but those savings cluster disproportionately among firms that had some structured implementation behind them, rather than simply buying a license and hoping. One practitioner benchmark puts the value at $78,000 a year in labor-equivalent gains for a five-to-25-person firm running AI workflow automation properly, and that number assumes the automation is wired into the real workflow rather than layered over it. This is exactly where the JTBD process earns its keep: it hands whoever does the implementation a precise job statement, a four-forces read on the team, and a shared definition of success, which shrinks the diagnostic phase of any deployment from weeks to days.
Turning a JTBD job statement into a 30-day deployment target
A well-built job statement is already halfway to a spec. The situation tells you when the system needs to switch on. The functional outcome tells you what "done" looks like. The downstream consequence tells you how you'll know it worked, because a P&L demands concrete numbers, not vague efficiency claims.
Speed matters more than elegance here. A working system after 30 days teaches you more than six months of scoping ever will, because it generates real feedback from a real workflow instead of hypothetical feedback from a whiteboard. Learning compounds; planning produces diminishing returns.
A 30-day deadline forces discipline. It keeps scope narrow: one high-leverage job. It forces the team to be involved from day one, because a system nobody helped build is a system nobody adopts. And it forces a clean before-and-after number tied directly to the job statement. One freight client saved more than 160 hours a month by deploying against a single job: the coordination and paperwork that had been quietly capping throughput, exactly the kind of bottleneck a JTBD interview would have flagged in week one. The first working system does two things at once. It removes the ceiling it was built to remove, and it hands the team the confidence, and the data, to spot the next one.
So the real question for a five-person firm is which job gets deployed against in the next 30 days, and what the business looks like on the other side of it.
