The Screen Had Two Jobs, But We Had Named Only One
The screen looked harmless.
It was an onboarding checklist in a B2B product. Five steps, a progress bar, a small celebration state at the end. The team showed it to me as part of a product review. They wanted to raise activation. Reasonable. Every product team wants to raise activation, and onboarding checklists are one of the industry-approved ways to look like you are doing something about it.
I asked what the checklist did for the customer.
The answer was quick: it helped a new admin finish setup without missing anything. Connect the data source, invite the team, configure permissions, run the first report. That was a real customer Job. The admin did not want to hold the whole setup sequence in working memory. The checklist performed "set up the workspace correctly without having to remember the sequence."
Then I asked what the checklist did for the business.
The answer was also quick, but weaker: it increased activation.
That was not wrong. It was just not enough. Activation is a measurement word. It names the business side after the fact. It does not explain the mechanism. So I asked again, slightly differently: how does the customer's setup Job, performed better by this checklist, perform the company's activation Job?
The room got slower.
That was the moment the checklist stopped being a UX pattern and became a product object. It had two sides. On the customer side, it performed a setup Job. On the business side, it performed an activation Job. The business Job did not happen directly. It happened only if the checklist made the customer's setup Job more complete, less anxious, and more likely to reach the first useful result.
If the checklist had merely forced five empty clicks before the product became usable, it might still have raised a dashboard number for a week. It would not have performed the customer's Job. It would have extracted compliance. The same artifact, same pixels, opposite business quality.
I had been missing this for years, or at least not saying it sharply enough. I knew products performed Jobs for customers. I knew companies had goals. But I still often treated the two sides as separate layers: product value here, business metric there, connected by a dashboard.
The cleaner model is harsher.
Every part of a product performs customer Jobs and business Jobs at the same time. The business Job is performed only through the customer Job. No exception.
That one sentence changes how you read the product.
Read the product this way and every part becomes a small machine: a screen, a price, a guarantee, a trial, a dashboard, a cancellation flow, a notification, a help article, a sales deck, a checkout button, an empty state. Each tries to perform a Job for a person and, through that, a Job for the business.
If you name only the customer side, you make nice product work with no economic discipline. If you name only the business side, you make metric theater and call it product work. The product becomes serious only when both sides are named and the causal link between them survives inspection.
The Business Job Is Not Performed Directly
A business goal is a business Job with success criteria. Increase activation. Reduce churn. Raise expansion revenue. Improve gross margin. Shorten sales cycle. Lower support load. Each names a State B the business wants to reach and the criteria by which the business will judge whether it got there.
OKRs and KPIs are not a separate species. They are compressed Job statements. The standard OKR frame says the objective names what is to be achieved and key results make progress measurable. Fine. That compression is useful. A company cannot run quarterly planning with a full essay attached to every target.
But compression deletes fields. It deletes the context that created the goal, the pressure behind it, the higher business Job above it, and the person whose movement will perform it. Those fields do not stop existing because the template is clean.
The dangerous deletion is the performer.
Teams talk as if they perform business Jobs directly. We drive revenue. We drive retention. We drive activation. We drive expansion. The verb is convenient and mostly false. The team performs product Jobs and operating Jobs. It chooses the target segment, creates value, communicates it, removes barriers, repairs chains, changes price, builds onboarding, writes docs, answers support, sells, and delivers.
Those are real Jobs. They matter. But they are not revenue, retention, activation, or expansion.
Revenue is performed when a customer buys. Retention is performed when a customer returns to perform a Job again. Expansion is performed when a customer brings the product into another Job, another team, or another budget. Lower support load is performed when the product or communication lets the customer finish their Job without needing help. Gross margin improves when the company performs the customer Job with less cost without damaging the criteria that made the customer hire it.
The business Job becomes real only after a person moves.
That person is usually a customer in market-facing goals. Sometimes it is an employee, buyer, partner, or regulator. But it is always a person or a system built around people. A company has no hands. It has no attention. It cannot feel friction, trust, anxiety, embarrassment, urgency, or relief. All of that lives in the human chain.
This is why "improve activation" is a weak product instruction. It skips the person. The stronger version is: help a new admin finish setup correctly enough that they reach the first useful report today. Now the customer Job and the business Job are tied. Activation is no longer a number floating above the product. It is the business-side consequence of a customer Job performed well.
The same rewrite works everywhere.
Reduce churn becomes help the customer keep performing the recurring Job without a break that sends them back to the old Solution. Raise expansion revenue becomes perform the next Job the same customer already has, so the product becomes useful to another role or workflow. Improve margin becomes remove waste from how we perform the customer's Job without lowering the success criteria that make them stay. Lower support load becomes make the customer's Job obvious enough, or the chain reliable enough, that they do not need to ask us to rescue it.
This is not wordplay. It is causality.
When the customer Job disappears from the sentence, the team starts pushing the business Job directly. That is where ugly product work begins: cancellation friction to "save retention," misleading discounts to "drive conversion," noisy prompts to "increase engagement," forced forms to "qualify leads," enterprise-only features that "close the quarter" while making the core product worse for the target segment.
Those moves may move metrics. They do not perform business Jobs cleanly. They perform one business Job by damaging the customer Job that made the business possible.
Every Product Part Is A Double-Entry Record
Once you see the double structure, the product becomes easier to read.
A product part has to answer two questions:
Which Job does this perform for which person?
Which business Job is performed through that person's movement?
If the first answer is missing, the part is probably extraction, decoration, or internal convenience pushed onto the customer. If the second answer is missing, the part may be pleasant craft with no economic reason to exist. Good product work holds both.
DashPass has two sides: for the customer, "order delivery repeatedly with less fee surprise"; for DoorDash, repeat ordering, habit formation, and predictable demand. The business Jobs move because a recurring customer Job becomes cheaper and calmer to perform.
Stripe Checkout has two sides: for the merchant, "accept online payments without custom checkout engineering"; for Stripe, activation and segment expansion, because more merchants reach a live payment before the chain breaks at "I don't know what an API key is."
TurboTax's W-2 import has two sides: for the filer, "file my return correctly without retyping fields and worrying I copied a number wrong"; for TurboTax, completion, trust, and paid filing. The business Job moves because the customer reaches the filed-return Job with less cognitive load and less fear.
Shop Pay and Apple Pay have two sides: for the buyer, "pay without re-entering address and card details"; for the merchant or platform, conversion and repeat purchase, because a step disappears from a chain the customer already wanted to finish.
Figma comments have two sides: for the designer and reviewer, "give and resolve feedback in context"; for Figma, team adoption and switching-cost growth, because the product becomes where the work and its discussion live.
Slack Connect has two sides: for the team, "work with an external partner without dragging the conversation back to email"; for Slack, account expansion and network exposure.
Square's tip screen has three sides: for the buyer, "choose a tip without awkward math while someone is watching"; for the merchant, staff income and checkout flow; for Square, a stronger payment surface and merchant retention.
The seven examples are one structure repeated across pricing, checkout, import, collaboration, payments, and communication. The product part earns its place by performing a customer Job; the business value rides on that performance.
The inverse is just as useful.
A cancellation flow that hides the exit may perform "reduce churn this week" on the dashboard. It does not perform the customer's Job. It creates a Tax Job: escape the product I no longer want without being tricked. The business may keep the account for one more cycle and lose the customer's trust, word of mouth, and future willingness to return. A lead form that demands ten fields before any value lands may perform "qualify prospects for sales." It also forces the customer to perform "give information to a company I do not yet trust." If the customer has not received enough value, the form breaks the chain.
The test is not whether a business metric moves. Bad product work can move a metric. The test is whether the business Job is performed through a customer Job becoming more energy-efficient against that customer's criteria.
The Product Is Where The Two Goal Systems Meet
This is where the previous chapters join.
One chapter said everything in the product flows from the target segment's Jobs. Another said errors travel down the cause-and-effect chain from market and Job to value, demand, retention, and profit. Another said every decision silently chooses a strategy: a Job and a segment.
This chapter adds the other side of the table. The company also has Jobs, and every product decision is where the two systems meet.
A feature is a choice of customer Job and business Job. A price is a choice of customer Job and business Job. A landing page is a choice of customer Job and business Job. A support policy, an enterprise plan, a free trial, a referral loop, a dashboard, a docs page, a guarantee: each is a coupling between what the customer is trying to perform and what the business is trying to perform.
That coupling can be clean, weak, or corrupt.
Clean coupling: the customer Job becomes easier, faster, safer, calmer, or more complete, and the business Job moves because of that. DashPass, Stripe Checkout, W-2 import, Figma comments.
Weak coupling: the customer Job is real, but the business does not know what business Job the artifact performs. This creates craft drift. Teams improve what they can see locally: nicer empty states, smoother microcopy, another preference setting, another report. Some of it helps. Much of it consumes attention and engineering capacity without a clear business chain.
Corrupt coupling: the business Job moves by making the customer Job worse. Dark-pattern cancellation, bait pricing, notification spam, forced sales calls before value, enterprise clutter pushed into a simple product. These are not merely "bad UX." They are business Jobs performed against the customer chain.
Most product arguments are confused because the room has not named which type of coupling it is debating. One person argues for the customer Job. Another argues for the business Job. A third argues from the implementation cost. A fourth argues from the last enterprise deal. Everyone may be locally right, and the product still gets worse.
The useful sentence is simple:
This artifact performs customer Job X for target segment Y, and through that movement performs business Job Z.
If the sentence cannot be completed, the work is not ready. It may be a fine idea. It may be visually elegant. It may satisfy a stakeholder. It may even move a metric. But the team has not yet shown the mechanism by which customer value turns into business value.
That sentence is brutal at solo scale.
A solo founder wants "replace my salary with product revenue before savings run out." Every product part has to answer the same double question. The landing page performs which customer Job? The free tier performs which customer Job and which business Job? The onboarding email performs which customer Job and which business Job? The Stripe price point performs which customer Job and which business Job?
There is no org chart to blame. The business Job and customer Job either meet inside the artifact or they do not.
B2B Adds Personal Jobs To The Coupling
B2B adds one more layer because the customer is a company, and a company moves through people with careers.
The product artifact must often perform three Jobs at once: the end customer's usage Job, the buyer's business Job, and the buyer's personal Job.
A SOC 2 report is not only compliance documentation. For IT, it performs "pass security review without creating avoidable risk." For the buyer, it can perform "defend this vendor choice if something goes wrong." For the vendor, it performs the business Job of moving the deal through procurement. The vendor's business Job is performed through the buyer's business and personal Jobs, not around them.
The same pattern appears in executive summaries, implementation plans, admin dashboards, ROI reports, and QBR decks. A dashboard that shows cost savings is not only reporting. It helps the buyer perform "show leadership the program worked." Through that, the vendor performs renewal and expansion Jobs.
This is why B2B sales that rely only on business ROI feel rational and still stall. The business Job gets the deal onto the table. The personal Job often decides whether the human moves. Personal Jobs gate the decision; business Jobs justify it.
I once heard a practitioner describe a corporate language school that sold above the market price. Price should have killed the deals if procurement were purely rational. It did not. The school sold language lessons, and it sold the HR buyer a story they could carry upward: I want to show leadership that this program improved the team with visible evidence. The lessons performed the company's business Job. The evidence performed the buyer's personal Job. The vendor's business Job was performed through both.
That is all this chapter needs from B2B. The larger machinery belongs later. The point here is the same: every product artifact performs business Jobs only through human Jobs, and B2B simply gives you more humans in the chain.
Wes Says This Makes Product Too Complicated
That is the standard. Not purity. Clarity.
Business Jobs are real. They deserve to be named. Customer Jobs are real. They are the only route by which market-facing business Jobs get performed cleanly. The product is where the two either compound or fight.
What Makes The Customer Move
Once every product part is read as a coupling between customer Jobs and business Jobs, the next question is unavoidable: what makes a customer move toward a new way of performing their Job at all?