Extracting Customer Needs, Outcomes, Success Criteria, and Constraints

Good to see you again. Previously, you mapped onboarding as a progression from purchase commitment through readiness, first value, repeated use, and ongoing Customer Success. That map becomes useful only when it is grounded in the customer’s own reason for buying—not a generic sequence of setup tasks.

This lesson focuses on turning imperfect discovery notes, sales-call summaries, CRM fields, and handoff comments into four clear inputs for onboarding:

1. the job-to-be-done;
2. the desired business outcome;
3. the success criteria; and
4. the constraints that shape the realistic path to value.

This is a core post-sale skill. It prevents the most common onboarding error: delivering the activities the vendor planned while missing the progress the customer actually needed.

---

Read discovery notes as evidence, not as a plan

Discovery notes are usually messy. A sales rep may write:

“Customer wants better reporting. They need to launch quickly. Their VP is highly engaged. Integration should be straightforward.”

This sounds informative, but it is not yet operational. “Better reporting” could mean faster executive decisions, improved forecasting accuracy, clearer pipeline accountability, or simply fewer spreadsheet exports. “Launch quickly” may mean before a board meeting, before a contract renewal, or before an internal initiative loses momentum. “Straightforward” may be optimism rather than a confirmed technical fact.

Your job is not to copy these phrases into an onboarding plan. Your job is to extract claims, identify what each claim means, and mark what still needs validation.

A useful principle is:

$$\text{Discovery evidence}\ne \text{Customer truth}\ne \text{Onboarding plan}$$

Discovery evidence is what someone said or recorded. Customer truth is your best validated understanding of the customer’s situation. The onboarding plan is the shared set of actions designed around that understanding.

Keep these layers separate. If a sales note says, “The customer expects to save 30% of reporting time,” do not immediately treat that as a committed success metric. Ask:

• Who made that estimate?
• What work is included in “reporting time”?
• What is the baseline?
• Who will measure it?
• Is it a hoped-for benefit, a commercial claim, or a jointly accepted target?

This distinction is especially important in SaaS. Sales conversations often emphasize possibility; onboarding needs enough precision to coordinate real people, data, deadlines, and change.

---

The four things you must extract

The four items are related, but they answer different questions.

Item	Core question	Example
Job-to-be-done	What progress is the customer trying to make in a specific situation?	“Enable regional sales leaders to identify stalled deals before weekly forecast reviews.”
Desired business outcome	What organizational result should that progress produce?	“Improve forecast accuracy and reduce end-of-quarter surprises.”
Success criteria	What evidence will show the initiative is working?	“By the end of Q2, forecast variance falls from 18% to below 10%, measured from CRM forecasts against closed revenue.”
Constraints	What limits, dependencies, risks, or conditions affect the path?	“Security approval is required; CRM data quality is inconsistent; sales managers can attend only one training session.”

A simple test helps distinguish them:

• If it describes work the customer needs to accomplish, it is probably a job.
• If it describes a business-level change, it is probably an outcome.
• If it describes proof that the change happened, it is a success criterion.
• If it describes what might prevent, delay, narrow, or reshape progress, it is a constraint.

The customer may initially express all four as one vague sentence:

“We need to get more value from our customer data quickly.”

Your role is to unpack it, not to treat it as complete.

---

Start with the customer’s struggling moment

Jobs-to-be-done, often shortened to JTBD, is a way to understand why someone adopts a product. The key idea is that customers “hire” a product to make progress in a particular context. They are not simply buying features.

For onboarding, the most useful unit of analysis is the struggling moment: the event or recurring situation that made the current approach insufficient.

For example, a customer does not truly buy a revenue-intelligence platform just to “use AI forecasting.” They may be trying to solve this situation:

“When our leadership team asks for a reliable forecast, regional managers spend two days reconciling spreadsheets, yet we still discover major deal risks too late.”

That situation contains the beginnings of the four-part model:

• Context: leadership forecast reviews; decentralized regional teams.
• Struggle: manual reconciliation and late risk visibility.
• Job: prepare a credible, actionable forecast.
• Desired outcome: faster decisions and fewer avoidable forecast misses.

A feature-centric interpretation would be, “Teach the customer how to use forecast dashboards.” A job-centered interpretation is, “Help regional sales leaders use live deal signals to run a credible forecasting process.” The second version tells you what onboarding must enable.

Write a job statement without inserting your product

A reliable job statement has four parts:

When [context or triggering situation],
[specific actor] wants to [make functional progress],
so that [they can achieve a meaningful result],
while dealing with [important constraints or pressures].

For the forecasting example:

When leadership requests the weekly forecast, regional sales leaders want to identify and challenge risky opportunities using trusted current data, so that they can commit to a credible number and direct coaching where it matters, while avoiding another manual spreadsheet-reconciliation process.

Notice what is absent: “use our dashboards,” “adopt our workflow,” or “complete training.” Those may become means to the job; they are not the job itself.

A job may also have emotional and social dimensions:

• Functional: Produce a reliable forecast from live opportunity data.
• Emotional: Feel prepared rather than exposed in a leadership review.
• Social: Be seen by executives as a credible, disciplined sales leader.

Do not force emotional or social language into every account record. But do capture it when it materially affects adoption. For example, a new operations manager who is expected to prove competence quickly may need a highly visible early win, not merely a technically successful configuration.

---

Extract the job, outcome, criteria, and constraints in four passes

Rather than trying to interpret every note perfectly in one read, use a structured extraction process.

Pass 1: Reconstruct the story

Read the notes chronologically and answer:

1. What changed, or what triggered the purchase now?
2. What did the customer do before considering this product?
3. What was not working with that approach?
4. Who felt the pain, and who is accountable for improvement?
5. What event, deadline, or internal priority makes this urgent?

This protects you from a common mistake: treating the selected product as the beginning of the story. The product is usually a response to a pre-existing struggle.

Look for phrases such as:

• “We were preparing for…”
• “Our old process could no longer…”
• “The CEO asked why…”
• “We tried spreadsheets / another vendor / an internal process…”
• “We need this before…”
• “The initiative lost momentum last time because…”

The purchase trigger is often the most compressed, valuable line in the notes. It reveals why the customer may prioritize the work now—and what could cause it to lose priority later.

Pass 2: Highlight evidence into four buckets

On the second read, sort statements into the four categories. Preserve the customer’s language first; interpret it second.

Evidence in a note	Initial category	What it may mean
“Support leadership cannot see the reasons behind repeat tickets.”	Struggle / job evidence	Need to identify patterns and prioritize operational action.
“The COO wants to lower ticket volume before adding headcount.”	Outcome evidence	Reduce avoidable demand and service cost.
“They want an initial result before the July planning cycle.”	Success-criteria and timing evidence	A deadline exists, but the exact result still needs definition.
“Security will not approve unrestricted data access.”	Constraint	Integration and data scope may be limited.
“Their last platform was abandoned after one training session.”	Constraint / risk evidence	Change-management design, not only training delivery, will matter.

At this point, do not turn every statement into a certainty. Give it an evidence status:

• Confirmed: directly stated by the accountable customer stakeholder and sufficiently specific.
• Reported: stated in notes but not yet validated with the customer.
• Inferred: a reasonable interpretation based on several facts.
• Unknown: an important field with no evidence.

This discipline makes a handoff far more credible. “Target is to reduce ticket volume by 20%” is materially different from “Sales believes the customer hopes to reduce tickets.”

Pass 3: Convert product language into customer progress

Discovery notes often describe a product request rather than the underlying need:

Product-centric statement	Better question	Possible job-level interpretation
“They need the Salesforce integration.”	What decision or workflow depends on Salesforce data?	Help sales leaders identify at-risk opportunities in time to intervene.
“They want an executive dashboard.”	What should executives be able to decide or do differently?	Enable leaders to review operational performance without manual data collection.
“They need training for 200 users.”	What must those users be able to do in real work afterward?	Enable managers to run the weekly review process independently.
“They want automation.”	Which manual work or error must disappear?	Reduce time spent routing routine requests while preserving exceptions for specialists.

This is not an argument against capturing feature requirements. Integrations, dashboards, and automation may be necessary. The point is that a feature request tells you how the customer currently imagines the solution, not necessarily what success requires.

Pass 4: Turn the interpretation into a validation-ready brief

Your final extraction should be concise enough to use in a kickoff, but rich enough to guide the onboarding design. It should make unknowns visible rather than hiding them.

A practical format is:

Customer / segment:
Primary customer actor:
Purchase trigger and context:

Job-to-be-done:
When [context], [actor] wants to [progress], so that [result].

Desired business outcome:
[Business change], measured by [KPI] from [baseline] to [target] by [date].

Onboarding success evidence:
[The first meaningful workflow or value event the customer should achieve.]

Constraints and risks:
- [Constraint]
- [Constraint]
- [Risk or assumption requiring validation]

Open questions:
- [Question]

The phrase onboarding success evidence matters. A six-month business outcome may be legitimate but too distant to prove whether onboarding is working. You need an earlier, credible signal that the customer has begun doing the value-producing work.

---

Desired business outcomes are not product usage targets

A desired business outcome is the customer’s intended organizational change. It usually belongs to a business leader or operational owner, not to the vendor.

Compare these statements:

Weak goal	Why it is weak	Stronger business outcome
“Launch the platform.”	A vendor activity, not customer value.	“Give support leaders a weekly view of repeat-ticket drivers so they can reduce preventable demand.”
“Train all users.”	Training attendance does not prove ability or impact.	“Enable team leads to resolve routine cases consistently without escalating them.”
“Increase logins.”	May be irrelevant to the customer’s actual workflow frequency.	“Ensure account managers use risk signals in every monthly customer review.”
“Improve retention.”	Too broad and rarely owned by one onboarding initiative.	“Raise renewal-risk visibility for the 50 highest-value accounts before Q3 renewal planning.”

A strong outcome is usually expressed as a change in one of these areas:

• revenue or pipeline quality;
• cost or time efficiency;
• risk, compliance, or error reduction;
• customer experience or service quality;
• employee productivity or capacity;
• operational visibility and decision quality;
• adoption of a strategic business process.

The following reading explains why a success plan begins with business context and why vague ambitions must be translated into measurable outcomes.

Make outcome statements testable

A useful outcome statement answers five questions:

1. What changes? The business result.
2. For whom or where? The scope: team, workflow, region, or customer segment.
3. From what baseline? The current state.
4. To what target? The intended state.
5. By when, and measured how? The timeframe and data source.

For example:

Reduce average first-response time for priority support cases from 6 hours to 2 hours by the end of Q3, measured weekly in the help-desk reporting system.

This is much stronger than “improve support responsiveness.” However, it may still be a proposed target. In your extraction, label it accordingly until the responsible customer owner agrees to the baseline, target, timeframe, and measurement method.

If the customer cannot provide a baseline, do not invent one. Write:

Baseline unknown; establish a four-week baseline during onboarding before setting the target.

That is not a weak answer. It is an honest and actionable one.

---

Success criteria: define proof at the right level

Success criteria are the conditions that show progress toward the outcome. They are more concrete than an aspiration and broader than a vendor task list.

A criterion can be quantitative, qualitative, or behavioral—but it must be observable and agreed.

Consider this sequence:

$$\text{Task complete}\to \text{Capability established}\to \text{Value-producing behavior}\to \text{Business outcome}$$

Using a customer-support analytics platform:

Level	Example	Is it sufficient as onboarding success?
Task complete	Help-desk integration connected	No. Necessary setup, but no demonstrated use.
Capability established	Support operations lead can create and interpret a trend report	Better, but still may not affect work.
Value-producing behavior	Lead uses a live report in the weekly operations review and assigns an owner to the largest ticket driver	Usually yes: credible early value.
Business outcome	Repeat-ticket volume declines 20% over six months	Important ultimate outcome, but too delayed to serve as the sole onboarding completion signal.

For each desired outcome, aim to capture:

• Outcome metric: What business metric should improve?
• Baseline: What is true now?
• Target: What change is desired?
• Timeframe: By what date or business cycle?
• Measurement method: What system, report, or calculation will be trusted?
• Customer owner: Who can confirm whether success has occurred?
• Early proof: What value-producing behavior should occur during onboarding?

This is how you avoid “success theater,” where everyone celebrates a completed implementation while the customer’s working behavior remains unchanged.

---

Constraints are design inputs, not excuses

A constraint is any condition that affects what the customer can realistically do, how fast they can do it, or what form the solution must take. Constraints belong in discovery because they determine whether a theoretically sound onboarding path will work in practice.

Common constraint categories include:

Category	Examples	Onboarding implication
Technical and data	Security review, API limits, incomplete data, SSO requirements	Sequence technical validation early; define fallback paths.
Time and timing	Board deadline, seasonal peak, fiscal close, contract deadline	Set a minimum credible scope for first value.
Capacity and capability	One overwhelmed admin, limited training time, low data literacy	Reduce burden, create role-specific guidance, identify backup owners.
Process and governance	Procurement rules, legal approval, change-control board	Add dependencies and accountable owners to the plan.
Change and organizational dynamics	Skeptical users, leadership turnover, prior failed rollout	Build sponsorship, early proof, and communication into onboarding.
Scope and commercial boundaries	Purchased module excludes a needed workflow; services hours are limited	Clarify what is in scope before creating expectations.

Constraints should be recorded in precise language. “Customer is busy” is not useful. Better:

The technical admin supports three concurrent software rollouts and can allocate one hour each Tuesday; SSO approval requires the information-security team, which meets biweekly.

That statement helps you design a viable cadence. It also makes the risk visible to Sales, Implementation, and Customer Success.

Separate constraints from assumptions

This distinction prevents downstream surprises:

• Constraint: “The customer requires SSO before users can access the platform.”
  A stated requirement that shapes the plan.

• Risk: “The security review may take longer than the planned launch window.”
  A possible adverse event.

• Assumption: “The customer’s identity provider supports the required SSO configuration.”
  A belief that must be tested.

• Dependency: “The security team must approve the configuration before the IT admin can enable SSO.”
  An external condition required for progress.

A mature onboarding professional can explain these differences clearly. They do not write “integration risk” and move on; they specify the dependency, owner, probability, potential impact, and next validation action.

---

Worked example: turn notes into an onboarding brief

Imagine these discovery notes from a fictional SaaS company, SignalDesk, which helps support organizations identify the operational causes of repeat customer tickets.

Discovery notes — Northstar Commerce

• VP of Customer Experience said support volume rose 28% after the company added two product lines.
• The support-operations manager exports help-desk data every Friday and combines it with product data in spreadsheets. “By the time we see the trend, it has already become a major issue.”
• The COO wants the company to avoid hiring 10 additional support agents before the holiday peak in November.
• First proposed use case: identify the top three repeat-ticket drivers and assign cross-functional owners in the weekly operations review.
• Customer previously purchased an analytics tool but stopped using it because dashboards were not trusted and no one owned the weekly review process.
• IT security requires SSO and will not permit unrestricted customer-data exports. Review is estimated at four to six weeks.
• Dana, the support-operations manager, is the day-to-day champion. The VP is executive sponsor. Product Operations must supply category definitions.
• Sales notes: “Customer expects meaningful reduction in tickets by year-end.” No baseline for repeat-ticket volume is documented.

Here is a weak extraction:

Goal: Reduce support tickets by year-end.
Plan: Connect the integration, train Dana, create dashboards, and review usage.

It repeats the notes, but it does not guide decisions. It fails to define the job, the relevant workflow, the target, the risks, or the unvalidated information.

Here is a stronger extraction.

Field	Extraction	Evidence status
Customer context and trigger	Support volume increased after expansion into two new product lines. Leadership wants to manage demand before the holiday peak rather than add 10 agents.	Confirmed in notes; exact staffing decision should be validated.
Primary job-to-be-done	When repeat-ticket patterns emerge across new product lines, the support-operations manager wants to identify the highest-impact drivers from trusted operational data and bring them to the weekly review, so that cross-functional teams can assign and resolve underlying causes before volume escalates.	Inferred from multiple notes; validate wording with Dana.
Desired business outcome	Reduce avoidable support demand and defer or reduce the need for additional support hiring before the holiday peak.	Confirmed direction; metric and target unconfirmed.
Proposed outcome metric	Repeat-ticket volume or rate, segmented by issue category and product line.	Inferred; confirm the metric most trusted by the VP and COO.
Onboarding success evidence	Dana uses connected, validated live data in the weekly operations review to identify the top three repeat-ticket drivers; each has an accountable cross-functional owner and next action.	Strong candidate; jointly validate at kickoff.
Longer-term success criterion	By year-end, repeat-ticket volume declines by an agreed target relative to an established baseline.	Target and baseline unknown.
Technical constraints	SSO is mandatory; unrestricted customer-data export is prohibited; security review may take four to six weeks.	Reported; confirm scope and approval process with IT.
Operating constraint	A prior tool failed because data was not trusted and the recurring review process had no owner.	Confirmed historical risk.
Stakeholder constraint	Product Operations must provide category definitions; without shared definitions, analysis may not be trusted.	Reported dependency.
Critical open questions	Which ticket metric will the COO use? What is the current baseline? Who owns remediation after a driver is identified? Can a limited, approved data set support the first use case during security review?	Unknown.

This is the difference between a CRM summary and a usable onboarding foundation.

The extracted job tells you that a dashboard alone is insufficient. The customer needs trusted data plus an operational review-and-action loop. The prior failure tells you that adoption risk is organizational as well as technical. The security requirement tells you that the first-value path may need a limited-data pilot or a carefully sequenced approval plan.

The customer-success-plan view below shows where this information ultimately goes: context, outcomes, milestones, metrics, stakeholders, risks, and accountable actions should reinforce one another.

---

Questions that improve weak discovery notes

Extraction is not a one-time administrative task. Its purpose is to prepare better validation conversations during post-sale handoff and kickoff.

Use questions that expose evidence, rather than questions that invite generic opinions.

To clarify the job

• What happened that made the current process unacceptable now?
• Walk me through the last time this problem occurred. What did the team do?
• Who performs this work today, and who depends on its output?
• What workaround would the customer return to if they stopped using the product?
• What decision or action should become easier after the workflow is in place?

To clarify the desired business outcome

• What would be different in the business if this initiative works?
• Why does that result matter this quarter or this year?
• Who has to see the result for the initiative to be considered worthwhile?
• Is the objective to increase revenue, reduce cost, reduce risk, improve experience, or make a decision faster?

To clarify success criteria

• What metric would convince you that progress is real?
• What is the current baseline, and where does that number come from?
• What target is meaningful enough to justify the investment?
• By when must the result be visible?
• What should the customer be doing during onboarding that would demonstrate an early win?

To clarify constraints and risks

• What approvals, data, systems, or people must be available before the first use case can go live?
• What competing initiatives could take attention away from this work?
• What failed in previous attempts, and why?
• What would make this project lose internal priority?
• What must not happen during implementation because of security, compliance, brand, or operational risk?

These questions should not become an interrogation script. Use them to follow the customer’s story. If the answer to one question reveals that the real issue is adoption ownership rather than software configuration, follow that thread.

---

A quality check before you use the extraction

Before a kickoff or handoff, review your brief against this checklist.

The job-to-be-done is credible when:

• it identifies a specific customer actor;
• it includes a real context or triggering situation;
• it describes progress in the customer’s work, not use of your feature;
• it explains why that progress matters.

The desired outcome is credible when:

• it is a business result rather than a vendor activity;
• it has an accountable customer owner;
• its metric, baseline, target, and timeframe are known—or explicitly marked unknown;
• it is narrow enough to shape an initial onboarding scope.

The success criteria are credible when:

• they identify observable evidence;
• they distinguish setup completion from value-producing behavior;
• they include both an early proof point and, where relevant, a longer-term business measure;
• the customer can reasonably agree that the evidence represents progress.

The constraints are credible when:

• they are specific enough to change the plan;
• they name dependencies and owners where possible;
• historical failures are treated as meaningful risk evidence;
• assumptions and unknowns are not disguised as facts.

A final warning: resist the urge to manufacture precision. “Reduce tickets by exactly 22.5% in 90 days” looks sophisticated but is harmful if no customer stakeholder supplied the baseline, target, or timeline. High-quality onboarding combines rigor with intellectual honesty.

---

Key takeaways

Discovery notes are raw evidence, not an onboarding plan. Your task is to extract and validate four distinct elements:

• A job-to-be-done explains the progress a specific customer actor needs to make in a real context.
• A desired business outcome describes the organizational change that makes the initiative worthwhile.
• Success criteria define observable proof, including an early value-producing behavior and, where possible, a measurable business result.
• Constraints reveal the technical, organizational, timing, capacity, and governance conditions that shape a viable path to value.

Use customer language, preserve uncertainty, and mark information as confirmed, reported, inferred, or unknown. That makes your onboarding plan more trustworthy—and gives you the questions needed to create genuine alignment after the sale.

Next, you will use these inputs to define an onboarding completion criterion based on realized customer value, rather than a list of setup tasks completed.