Discovery & Requirements Elicitation

A structured or unstructured conversation between the BA and stakeholders (users, customers, subject matter experts) to gather detailed information about needs, expectations, and pain points. Interviews are the most used elicitation technique, and they come in formats you can mix:

• One-on-one interviews: direct interaction with a single stakeholder. Best for depth, candor, and sensitive topics.
• Group interviews: multiple stakeholders at once. Efficient, and lets you watch where people agree and disagree.
• Structured interviews: follow a predefined set of questions. Best when you need comparable answers across many people.
• Unstructured interviews: flexible, free-flowing conversation. Best early, when you do not yet know what you do not know.

Use when: you need depth, nuance, or trust; or when a stakeholder's individual perspective matters. Most discovery efforts start here.

A small, deliberately diverse group of stakeholders or users brought together to discuss and give feedback on a product, service, system, or idea. A moderator facilitates, asking open-ended questions to stimulate conversation and draw out needs, preferences, and concerns.

Use when: you want reactions and group perspectives rather than individual task detail, and when hearing participants build on (or push back on) each other's views adds value.

A creative group session where participants propose ideas freely, without early judgment. Used to explore possible solutions or features broadly before narrowing.

Use when: the problem is open-ended and you need volume and variety of ideas, not precision. Pairs naturally with workshops. (Module 20 teaches full facilitation craft for sessions like these.)

Reviewing existing documentation (reports, manuals, policies, business plans, system specifications) to extract relevant requirements. Especially useful for:

• Understanding the current state: what existing documents say about how things work, and where they need improvement
• Gathering historical data: past projects and records that reveal patterns, challenges, and lessons learned
• Clarifying requirements: cross-referencing what stakeholders say against what formal documents record, to catch inconsistencies and gaps

Use when: documentation exists (always check), when you need to prepare intelligently before taking up stakeholders' time, or when verifying claims. Document analysis is the technique that makes your interviews sharper.

Analyzing an existing system, application, or product to understand its components, functionality, and underlying logic, deriving the specifications and requirements it fulfills. You deconstruct the system to identify how it works, what it does, and which business requirements it satisfies.

This technique shines when:

• Legacy systems are involved and you must understand how they operate before upgrading or integrating
• Documentation is missing or outdated, and the only source of truth is the system's own behavior
• Modernization is planned and the new solution must honor existing workflows

Reverse engineering uncovers hidden and implicit requirements that no interview will surface, because nobody remembers them: the system is the only witness. It is usually combined with other techniques to fill knowledge gaps. In Salesforce work, this often looks like clicking through a legacy database or spreadsheet system field by field, asking "who uses this, and what breaks if it goes away?"

Collecting structured feedback from a large group using standardized questions. Forms include questionnaires (a set of predefined questions answered in writing or online), polls (shorter, quick-insight instruments), and rating scales (respondents rate agreement, satisfaction, or importance).

Surveys are particularly useful when:

• Large groups must be consulted, making interviews or focus groups impractical
• You need statistical analysis to find trends and patterns
• You want both quantitative data (multiple choice, rating scales) and qualitative insight (open-ended questions)

Trade-off to respect: surveys reach a wide audience fast, but they cannot explore complex or ambiguous issues in depth the way interviews and focus groups can. Use surveys for breadth, interviews for depth, and do not reverse them.

Facilitated, collaborative sessions where a group of stakeholders (business users, subject matter experts, project team members) come together to discuss, analyze, and define requirements. Workshops run on a clear agenda with a facilitator guiding the group through specific topics and activities. They are designed to generate ideas from diverse perspectives, clarify requirements and resolve ambiguities through discussion and consensus, prioritize needs, and build alignment and buy-in across stakeholder groups.

Their key advantages: real-time feedback (participants clarify and refine ideas on the spot), active involvement (stakeholders shape the requirements themselves, which makes them champions of the result), and rich discussion (complex issues get explored with the people actually affected).

Use when: stakeholder alignment is critical, consensus is needed on key requirements, or innovative solutions require collaborative energy. Workshops are expensive in coordination effort, so bring real preparation (Module 20 covers facilitation in depth).

Whichever technique you use, one habit multiplies its value: question why things are the way they are. When you hear "that's how we've always done it," you have found a place worth digging. Sometimes the old reason is still valid; often it evaporated years ago and the process outlived it. Questioning the status quo, respectfully and curiously, promotes deeper understanding and opens the door to innovative solutions. It is also, as the next section shows, the entire spirit of Jobs to Be Done.

The classic origin story: a fast-food chain wanted to sell more milkshakes. The team brainstormed the obvious ideas: bigger shakes, more flavors, kids'-meal bundles. Sales did not move.

Researcher Clay Christensen's team studied the restaurant for a day and noticed something odd: most milkshakes sold to adults before 8:30 AM, alone, to go. When they asked buyers, "What job are you trying to get done that prompts you to buy a milkshake so early?", the answers converged: a long commute, the need to stay full and occupied until break time, and a preference for something they could hold in one hand while driving. The milkshake was not competing with other desserts. It was competing with bananas, donuts, and bagels.

Armed with the real job, the chain made shakes thicker (they last a whole commute), added fruit (a healthier breakfast), and sped up purchase with prepaid cards in the drive-through. Milkshake sales rose sevenfold.

The lesson for BAs: the restaurant had a product problem because it had an understanding problem. Its customers were not looking for a better dessert. Until you know the job, your improvements are guesses.

Everything in JTBD flows from four principles:

1. Customer-centric: start from what the person is trying to achieve, not from your product, your expertise, or your title.
2. Solution agnostic: define the job without reference to any particular technology or solution. Jobs describe problems; solutions come later.
3. Stable over time: well-defined jobs endure. "Get to work with a full belly and stay energized" was true before milkshakes existed and will outlive them. Needs and circumstances evolve; the job stays put.
4. Measurable outcomes: tie jobs to outcomes defined in terms of the person's success, so you can tell whether a solution actually helps.

To apply the framework, identify four elements:

• Job performer: the person or group trying to get the job done: the primary consumer of the solution. Not always a job title or persona; sometimes a team or community. Remember that people rarely act in isolation: a solution touches the social dynamics around them too.
• Job to be done: the performer's primary objective: a problem to solve, something to avoid, something to accomplish. Sub-jobs exist, but needs and motivations are defined around the main job.
• Circumstances: the context: time, place, and manner. Circumstances change everything about what "good" means. Compare: prepare a meal when camping; prepare a meal I can eat quietly at my desk; prepare an impressive first-date meal. Same job verb, radically different success criteria. Instant noodles triumph in the tent and fail on the date.
• Needs: the person's requirements for getting the job done: the success criteria along the way. As JTBD author Jim Kalbach puts it, needs are not demands for a particular solution; they are an individual's requirements for getting a job done.

Needs come in three dimensions, and strong BAs listen for all three:

• Functional: what the performer wants to do. Clear start and end states. ("Collect business requirements from stakeholders." "Integrate data from different sources.")
• Emotional: how the person feels or wants to feel while doing the job or when it is done. ("Feel confident nothing slipped through the cracks.")
• Social: how the person wants to be seen while doing the job, or how the job fits an existing social dynamic. ("Be seen by leadership as on top of the numbers.")

Business contexts overweight functional needs because they are easiest to define. But emotional and social needs drive real decisions constantly, even in enterprise software. An admin choosing a tool is partly asking "will this make me look competent to my stakeholders?" Pretending otherwise produces solutions that are correct on paper and unloved in practice.

Raw interview notes become useful when translated into job statements. After talking with customers, debrief with your team, work through the notes, identify patterns, and articulate the functional, emotional, and social dimensions you heard.

Effective job statements share characteristics, and so do ineffective ones:

Compare these pairs:

• Weak: "Use a mobile app to easily access customers' notes from my car to prepare for a meeting." Better: "When I'm on the go, I want to access my notes, so I can feel confident and prepared for customer meetings." (The weak version bakes in a solution: a mobile app.)
• Weak: "People prefer using gamified learning apps to courses on the company website." Better: "When I need to learn new things for work, I want an engaging way to practice, so I can have more fun while I skill up." (The weak version is an observation plus a preference plus a solution.)

Two common methods structure this work:

• Job story method: capture the triggering situation, the motivation, and the desired outcome: When [situation], I want to [motivation], so I can [outcome]. Example: an account executive: "When I'm focused on closing deals I can realistically move to final negotiation, I want to quickly focus on the right opportunities, so I can maximize the likelihood of hitting my quota."
• Outcome-driven method: identify main jobs, then define a comprehensive list of desired outcomes per job. Each outcome statement has four parts: a direction of change (minimize, increase), a unit of measure (time, effort, likelihood), the object of the need (what is affected), and a clarifier (context). Example: minimize (direction) the time (measure) it takes to create a segmented audience (object) when launching a campaign (clarifier).

These get confused constantly, so pin the distinction now (Module 4 covers user stories fully). User stories specify the solution features being built. Job stories are the briefs that frame the challenge to be solved. They are complementary: a single job story can spawn a hundred user stories as individual steps toward the outcome. The job story "When the ground is thawed, I want to make a hole, so I can plant seeds that bloom in spring" might produce user stories about buying shovels, hiring diggers, or renting augers. Job stories align teams across marketing, engineering, and operations; user stories direct builders.

Jobs exist at different altitudes (scopes), and choosing the altitude changes your scope of innovation. An electric kettle company assumed its customers' job was "boil water." Interviewing revealed the real job one level up: "prepare a hot beverage." Boiling water was just one step, surrounded by steps the kettle never touched (grinding, brewing, pouring, milk). Recognizing the higher-altitude job opened whole product categories (cue the espresso machine). Too high an altitude, though, and the job becomes uselessly vague ("live a good life"). Aim for the altitude where your organization can plausibly help.

JTBD interviews differ from ordinary user interviews: the aim is understanding why someone "hires" (or fires) solutions to get a job done. The best practices:

• Ask open-ended questions. Let people talk about their experiences. Interviews will flow differently person to person; that is fine, as long as your goals and key questions stay consistent so you can find patterns across conversations.
• Ask how and why. "Can you recall the last time you did X? How did you do it?" reveals behavior and context. "Why did you do it that way?" reveals unmet needs, issues, and frustrations. Avoid binary yes/no and rating questions; they end conversations rather than opening them.
• Never demo a feature or pitch an idea. Keep the interview solution agnostic. Demoing narrows the person's thinking to your concept and hides their real experience.
• Talk to the right people. Identify the main job and talk to the main job performer. Beware: the user and the buyer may be different people with different jobs. (Cat food must be stinky enough for the cat and not-stinky enough for the human. Whose job are you studying?)
• Talk to at least five people to start seeing patterns.
• Take detailed notes in the customer's own words, not just what stands out to you. You will need their words to write faithful job statements later.
• Look for workarounds. The rubber bands and spreadsheets people bolt onto current solutions are unmet needs made visible.
• Chase surprises. When a choice or rationale surprises you, dig in. Surprises often mark needs the person cannot articulate directly.

Jobs remain stable; needs and circumstances evolve. Revisit them periodically, because the solution that fit last year's circumstances may quietly be failing this year's.