Lawyers hire software to make a risky judgment call defensible, not to save time on a task. When a legal-tech PM asks "what does this feature do," they get an accurate list of tasks; when they ask "what job would firing this software leave undone," they surface the outcome — usually protecting a reputation or avoiding a malpractice exposure — that actually drives the purchase.

Quick Answer: Legal workflow discovery fails when PMs collect task lists ("draft, redline, file") instead of jobs. Use Jobs to be Done interviews to separate the functional job (get to a defensible draft) from the emotional job (feel in control) and social job (look competent to a partner or client), then score opportunities with Ulwick's importance-vs-satisfaction gap.

Why Lawyers Describe Tasks Instead of Jobs

Lawyers default to describing procedure because procedure is what their training rewards and what protects them if something goes wrong. A PM who asks "walk me through your week" gets billing codes and document types, not the anxiety underneath them, because naming the anxiety feels like admitting weakness in a profession built on projecting certainty.

This isn't evasiveness — it's professional habit. Litigators are trained to speak in the passive, precise register of pleadings; transactional lawyers narrate in defined terms and cross-references. That same register shows up in a discovery interview, and it's a poor substitute for what you actually need: the underlying job-to-be-done.

The fix is structural, not persuasive. Instead of asking lawyers to self-report their motivations — which they're professionally conditioned not to do — ask about a specific recent instance and reconstruct the job from the sequence of events, the moment of struggle, and what "good" looked like when it worked (or didn't). This is the switch interview technique central to the Jobs to be Done methodology popularized by Clayton Christensen and refined into a practice by Bob Moesta and the Rewired Group.

The Jargon Trap

Dense jargon in legal interviews often functions as a shield rather than a description. When a lawyer says "I need better redlining," they may mean anything from "I don't trust associates' first drafts" to "opposing counsel always finds the clause I missed."

  • Ask for the last time, not the general case. "Walk me through the last contract you redlined start to finish" beats "how do you usually redline."
  • Listen for the moment they hesitated or double-checked something. That pause is usually where the real job lives.
  • Translate jargon back to them ("so 'clean version' means the one you'd be comfortable putting your name on") and watch whether they correct you — corrections are gold.
  • Don't accept a feature name as an answer. "I need a better search" is a solution, not a job; ask what happens right before they reach for search.

Our complete guide to legal tech covers the broader product landscape this discovery work feeds into, including where jargon-heavy workflows tend to cluster by practice area.

Every legal software purchase bundles a functional job, an emotional job, and a social job, and the emotional and social ones are usually the deciding factor even though they're rarely named in the RFP. Missing either of the latter two produces a tool that scores well in a demo and gets abandoned within a quarter.

Functional job is the visible, task-level outcome: get from a blank page to a filed motion, get from a term sheet to an executed agreement, get from a pile of discovery documents to a privilege log. This is what most legal software marketing addresses, and it's necessary but not sufficient.

Emotional job is how the lawyer needs to feel while doing the work and after it's done — usually "in control" and "not blindsided." Litigation and deal work are adversarial or high-stakes by nature; a tool that produces the right output but leaves the lawyer anxious about what it might have missed will get double-checked by hand anyway, erasing any efficiency gain.

Social job is how the work makes the lawyer look to someone whose opinion matters — a partner reviewing their output, a client paying by the hour, opposing counsel probing for weakness. A junior associate doesn't just want a clean contract; they want the partner to see a clean contract with their name on the routing slip.

Job typeWhat it sounds like in an interviewWhat it actually meansDesign implication
Functional"I need to turn this around faster"Reduce time-to-defensible-draftSpeed features, templates, automation
Emotional"I just want to know I didn't miss anything"Reduce anxiety about undetected errorConfidence signals, coverage indicators, audit trails
Social"I can't send the partner something sloppy"Protect professional reputation upwardPolish, formatting fidelity, review-ready output
Social (risk)"If this is wrong, it's my license"Avoid malpractice exposureCitation grounding, source traceability, human-in-the-loop gates

Why the Social Job Is Underweighted in Most PRDs

Most legal-tech roadmaps over-index on the functional job because it's the easiest to observe and quantify. A time-motion study will tell you contract review takes four hours; it won't tell you the associate is willing to spend an extra hour manually re-checking the tool's output because being wrong in front of a partner is a career event, not a productivity metric.

This is why AI-assisted legal tools face a trust tax that ordinary productivity software doesn't. If your product touches drafting or research output, the discovery work on hallucination risk and how lawyers actually rebuild trust after an AI error is worth reading alongside this piece — see our breakdown of rebuilding trust after legal AI hallucinations and why citation grounding functions as a trust feature, not just an accuracy one.

Scoring the Opportunity: Importance vs. Satisfaction

Once you have a candidate list of jobs, score each on how important it is to the lawyer and how satisfied they currently are with existing solutions — the gap between the two, not either number alone, tells you where to build. This is the core of Anthony Ulwick's Outcome-Driven Innovation method, and it converts a pile of qualitative interview notes into a rank-ordered backlog.

Ulwick's formula for an opportunity score is straightforward:

Opportunity Score = Importance + max(Importance − Satisfaction, 0)
  1. Ask every lawyer in your interview sample to rate each desired outcome (not feature) on a 1-10 importance scale and a 1-10 current-satisfaction scale.
  2. Calculate the gap. A job rated 9 for importance and 3 for satisfaction is a screaming underserved opportunity; a job rated 9 and 8 is already well-served and a poor place to compete.
  3. Plot every job on the importance/satisfaction grid. High importance, low satisfaction is your build zone. High importance, high satisfaction means differentiate elsewhere or compete on the emotional/social layer instead of the functional one.
  4. Re-run the exercise per practice area. A litigation associate and a transactional partner will score "confidence in citation accuracy" very differently — don't average across segments and lose the signal.
Job (litigation associate sample)Importance (1-10)Satisfaction (1-10)Opportunity scoreRead
Find every relevant precedent, not just the obvious ones9414Underserved — build here
Produce a document formatted to firm style777Well-served — table stakes
Know a citation hasn't been fabricated or misapplied10317Critically underserved
Turn around a first draft same-day8610Moderately underserved

The critically underserved row above is exactly why hallucination trust and citation grounding sit near the top of most legal-tech opportunity maps once you actually run the scoring — not because it's an interesting technical problem, but because the importance-satisfaction gap is unusually wide even by legal-industry standards.

Applying Forces of Progress to a Lawyer Switching Tools

A lawyer switches from Word and manual process to a new tool only when the push and pull outweigh the anxiety and habit holding them in place — and in legal practice, habit and anxiety are structurally stronger than in most industries, because errors carry professional and disciplinary consequences. The Forces of Progress model, developed by Bob Moesta and Chris Spiek as an extension of Jobs to be Done, maps four forces acting on any switching decision.

  • Push (the problem with the status quo): A missed deadline, a partner's comment that a document "wasn't tight enough," a near-miss where an outdated clause almost shipped. Push is what makes the current way of working newly uncomfortable.
  • Pull (the attraction of the new solution): A colleague's demo, a case study that names a familiar-sounding scenario, a sense that the new tool would make them look sharper in front of a partner. Pull needs to be concrete, not just "AI-powered."
  • Anxiety (fear about the new solution): "What if it hallucinates a citation and I don't catch it before filing?" "What if IT can't guarantee client confidentiality?" "What if I look incompetent fumbling through a new interface in front of a client?" In legal contexts, anxiety about liability transfer — if the tool is wrong, is it still my malpractice exposure — dominates every other anxiety.
  • Habit (attachment to the current way): Years of muscle memory in Word's track-changes workflow, a firm-wide template library built around it, the comfort of a tool that's never been the reason something went wrong.
ForceWhat it looks like for a Word-to-tool switchPM lever
PushPartner feedback on turnaround time; a near-miss errorSurface the cost of status quo in messaging, not just the benefit of switching
PullPeer recommendation; a demo that mirrors their exact matter typeUse scenario-specific demos, not generic feature tours
AnxietyFear of an undetected AI error; fear of looking inexperiencedHuman-in-the-loop review gates; visible source citations; low-stakes trial matters first
HabitWord's track-changes muscle memory; firm template librariesImport existing templates; keep familiar keyboard shortcuts and document conventions

For a switch to happen, push plus pull must exceed anxiety plus habit — and because legal anxiety is unusually acute (a bad output isn't just embarrassing, it can be a bar complaint), most legal-tech products underinvest in anxiety-reduction relative to feature pull. A trial period on a low-stakes internal memo, before touching a client-facing filing, is often a more effective adoption lever than another feature demo.

Where This Intersects Billable-Hour Incentives

Selling automation to professionals who bill by the hour introduces a fifth complication the classic Forces model doesn't name directly: some anxiety is economic, not just professional. A tool that visibly compresses review time can look, to an associate, like a threat to billable hours rather than a productivity gain. Our piece on selling automation to billable-hour professionals goes deeper on reframing that specific tension.

Building the Opportunity Map Into a Product Roadmap

A JTBD interview program only pays off once the raw notes become a structured, comparable opportunity map that a roadmap review can actually act on — otherwise the insights live in someone's interview transcripts and decay within a quarter. This means standardizing how outcomes are worded, scored, and revisited across practice areas and over time.

  1. Standardize outcome statements across interviews using the Ulwick format ("minimize the time it takes to X," "increase the likelihood of Y") so scores are comparable across lawyers and practice groups.
  2. Segment by practice area and seniority, not just firm size — a partner's social job (protect the firm's reputation) differs meaningfully from an associate's (protect their own standing with that partner).
  3. Re-score quarterly, not once. Satisfaction scores shift fast once a competitor ships something or your own tool closes a gap — a static opportunity map goes stale.
  4. Pair the opportunity score with the Forces of Progress map for the same job — a high-opportunity job blocked by high switching anxiety needs a trust-building feature before it needs a faster one.
  5. Feed the ranked list into prioritization, ideally against a framework like RICE or Kano so functional-job wins, emotional-job wins, and social-job wins aren't silently competing on an apples-to-oranges basis.

This is discovery work most legal-tech teams do with a spreadsheet, a slide deck, and a lot of tribal knowledge about which practice group said what. Prodinja's Customer Jobs tool is built to hold this whole workflow in one place — capturing jobs from interviews, scoring them with Ulwick's importance-versus-satisfaction method, and mapping the push-pull-anxiety-habit forces for a given switch — so the underserved legal workflow you found in interview six doesn't get lost by roadmap review in month three.

If your discovery work is still early, it's worth reading how JTBD connects to the rest of the customer research stack — our complete guide to Jobs to Be Done and the companion complete guide to customer journey mapping cover the adjacent frameworks (journey emotion curves, moment-of-friction mapping) that pair naturally with an opportunity score once you've found the underserved job.

Key Takeaways

  • Lawyers describe tasks, not jobs, because procedural language is a professional habit; reconstruct the job from a specific recent instance rather than a general self-report.
  • Every legal software purchase bundles three jobs — functional (get the work done), emotional (feel in control), and social (look competent, avoid malpractice exposure) — and the latter two usually decide the sale.
  • Score opportunities with importance minus satisfaction, not importance alone; the widest gap, not the highest-rated outcome, marks the best place to build.
  • Citation accuracy and undetected-error anxiety score as critically underserved in most litigation samples, which is why trust and grounding features consistently outrank speed features in legal-tech opportunity maps.
  • The Forces of Progress model (push, pull, anxiety, habit) explains why a lawyer with a compelling demo (pull) still won't switch if anxiety about liability transfer isn't directly addressed.
  • Re-score quarterly and segment by practice area and seniority — a static, firm-wide opportunity map goes stale and erases the differences that matter most.

Frequently Asked Questions

What is Jobs to Be Done in the context of legal software?

Jobs to be Done for legal software means identifying the functional, emotional, and social outcomes a lawyer is trying to achieve — like reducing malpractice exposure or looking competent to a partner — rather than the tasks they describe, such as "redlining" or "drafting."

How do you interview lawyers who won't reveal their real motivations?

Ask about a specific recent instance ("walk me through the last time you did X") rather than asking lawyers to generalize or self-report motivation, and listen for hesitation points, corrections, and comparisons to a bad prior experience — these reveal the job more reliably than direct questions.

What is Ulwick's opportunity scoring formula?

Opportunity score equals importance plus the positive difference between importance and satisfaction (Importance + max(Importance − Satisfaction, 0)), calculated from lawyer ratings of each desired outcome; the widest importance-satisfaction gap marks the most underserved, highest-priority job.

Why do lawyers resist switching from Word even when a new tool is objectively faster?

Because habit (years of track-changes muscle memory and firm template libraries) and anxiety (fear of an undetected error or looking incompetent) can outweigh the push and pull toward a faster tool — the Forces of Progress model explains switching as a balance of all four, not speed alone.

Is legal workflow discovery different from discovery in other regulated industries?

It's related but distinguished by the intensity of the social job — professional reputation and malpractice liability create anxiety and habit forces that are structurally stronger than in most regulated industries, which is why trust-building features often outrank pure speed or automation features in legal-tech roadmaps.