Main Jobs, Related Jobs, and the Ecosystem Map Around Your Product

A main job is the single piece of progress a customer hires your product to make happen — the job they'd fire you over if you failed. Related jobs are the adjacent progress that same customer is chasing at the same moment, usually stitched together from spreadsheets, other tools, or sheer effort. Mapping both reveals your safest next expansion.

The main job is the core progress your product is hired for; related jobs are adjacent progress the same customer seeks at the same time, often served by other tools or manual workarounds. A job ecosystem map plots both together so you can see which related jobs are underserved — those gaps are your lowest-risk expansion bets.

What a Main Job Actually Is

A main job is the specific functional and emotional progress a customer struggles to make, defined independently of any solution — "know precisely where my business stands financially," not "use accounting software." Most teams accidentally define their main job as their product category, which quietly caps how big an opportunity looks and hides real competitors.

Clayton Christensen's well-known milkshake research, later documented in Competing Against Luck, found that fast-food customers weren't buying a product category — they were hiring a milkshake to make a boring commute more interesting, or to quiet a toddler at dinnertime. The main job was "make my commute less boring," not "buy a milkshake." Once the chain understood that, it stopped competing with other milkshakes and started competing with bananas, bagels, and boredom itself.

Software teams fall into the same trap. A PM writing a job statement for accounting software often describes the job as "categorize transactions," when the real main job sits one level up: know precisely where the business stands, without doing the math yourself. Wording matters this much because a well-formed job statement names the progress, not the feature, and stays true no matter which tool eventually does the work — the exact structure for getting this right is covered in how to write a JTBD job statement.

The Main Job Test

Three quick checks separate a real main job from a disguised feature list:

• Did it exist before your product did? "Reconcile the books" predates any accounting software by centuries.
• Would it survive a switch to a completely different solution? If a customer moved from your app to a spreadsheet, the underlying job wouldn't change — only how well it's served.
• Is it phrased as customer progress, not a capability? "Prove the numbers are right" is a job; "run a reconciliation report" is a feature.

If you haven't built this muscle yet, the complete guide to jobs-to-be-done is worth reading before you start mapping anything adjacent — everything below assumes you can already write a clean main job statement.

Related Jobs: The Progress Happening Right Next to the Main Job

Related jobs are the other pieces of progress a customer pursues in the same situation as your main job — progress your product doesn't yet touch. Tony Ulwick's Outcome-Driven Innovation research names these explicitly: jobs that surface right before, during, or after the main job. They're where competitors quietly get entrenched while you're heads-down on your core feature set.

Ulwick's framework, laid out in Jobs-to-Be-Done: Theory to Practice and refined through his firm Strategyn, distinguishes several job types around any core job: the main (or "core functional") job, related jobs, consumption chain jobs — the steps involved in acquiring, learning, and maintaining a solution — and emotional or social jobs, which describe how the customer wants to feel or be seen. Related jobs are the category most teams underestimate, because they look like scope creep rather than what they are: whole, separate jobs with their own customers and their own competing solutions.

The distinction matters because "prove compliance" and "forecast cash" usually get logged as feature requests instead of what they are: full related jobs with their own success criteria. Treat them as jobs, not tickets, and the roadmap conversation changes from "should we build this feature" to "should we own this job."

Building a Job Ecosystem Map

A job ecosystem map is a single visual with your main job at the center and related jobs arranged around it, each tagged by who currently owns it and how well it's served. It turns a scattered list of adjacent customer needs into a picture of exactly where your product's edges are — and which edge is thinnest.

Five steps get you there:

1. Write the main job statement first. Use a clean, solution-independent job statement so every related job you add later is measured against a stable center, not a moving target.
2. Interview for the timeline, not the feature list. Ask what customers were doing right before they opened your product and right after they closed it. This before/during/after questioning, popularized by Bob Moesta through his Forces of Progress interviews at the Rewired Group, surfaces related jobs customers rarely volunteer unprompted. The same lens drives the emotion-curve work in the complete guide to customer journey mapping, and the two exercises pair well together.
3. Log every related job with its current owner. Tag each one: served by you, served by a named competitor, served by a manual workaround, or served by nobody at all.
4. Score importance and satisfaction for each. Ulwick's opportunity score ranks which related jobs are both big and badly served; the full formula is broken down in how the opportunity score formula works.
5. Plot proximity against how well each job is served. Jobs tightly coupled to your main job's moment of use and poorly served sit in your expansion sweet spot; jobs only loosely related, however underserved, belong on someone else's roadmap.

A job ecosystem map is a lightweight cousin of a full systems map. Where this map stops at "who owns this piece of progress," a systems map traces the feedback loops and second-order effects between those owners — worth building once you've picked a target, and the complete guide to systems thinking covers how.

Reading the Quadrants

Once every related job is plotted by proximity to the main job and how well it's served, four patterns tend to emerge:

• Close and poorly served — your expansion sweet spot; customers already trust you with the main job and are actively unhappy with how the related one is handled today.
• Close and well served — leave it alone; a competitor or workaround already does this job credibly, and unseating it costs more than the job is worth.
• Distant and poorly served — tempting, but usually a trap; it's underserved because it belongs to a different buyer or budget, not because nobody's tried.
• Distant and well served — ignore it entirely; it's simply not your ecosystem.

Accounting Software: Main Job and Related Jobs in Practice

For small-business accounting software, the main job is close to "know precisely where the business stands financially, without doing the math myself." The related jobs sitting immediately next to it include proving compliance to tax authorities, forecasting cash runway, getting paid faster, and reporting to investors or lenders — each currently served by a different tool or person.

Every mainstream accounting platform's expansion history is really an adjacency map made visible after the fact. QuickBooks didn't stay a ledger; it built and acquired its way into payroll, payments, and small-business lending, each one a related job that used to belong to a bank, a payroll bureau, or a spreadsheet. Xero's expansion into payments and payroll follows the identical logic: don't invent a new main job, absorb the related job already sitting beside yours.

Newer entrants read the same map from a different starting point. Ramp and Brex both began closer to the "control company spend" job than the "record every transaction" job, then expanded outward into bill pay, travel, and accounting-close automation — related jobs that traditional accounting software left half-served while it defended its core ledger. Neither company needed a new market; they needed a better answer to a job their customers already had.

None of these are new markets. They're jobs the same customer already has on the same day they use your product, currently handled by a workaround. That's precisely what makes them low-risk relative to a genuinely new main job for a genuinely new buyer.

Turning Related-Job Gaps Into Expansion Bets

The lowest-risk expansion move is building for a related job your existing customers already have, not inventing a new main job for a new audience. You keep your distribution, trust, and data; you're only closing a gap in the jobs you already touch, which is a smaller bet than opening a new market from zero.

Think of expansion moves on a risk ladder:

Not every related job deserves the next roadmap slot. Run each candidate through the same opportunity-score lens: high importance combined with low current satisfaction marks the biggest opening. A related job that's important but already served well by an entrenched competitor is a worse bet than a merely-decent job nobody has bothered to serve properly.

This is also where expansion discipline matters most. Corporate-strategy research from firms like McKinsey and BCG has repeatedly found that moves into adjacent capabilities tend to outperform diversification into genuinely unrelated markets, directionally reinforcing what the job map shows visually: proximity to a job you already serve well is itself a form of risk reduction, not just a convenience. The related jobs sitting closest to your main job on the map are usually the ones worth funding first, even when a more distant opportunity looks larger on paper.

Once you pick a related job to build for, write its job statement with the same discipline as your main job's. Vague related-job statements are exactly what get reinterpreted into the wrong feature by the time they reach a sprint — the failure mode why job statements get lost in engineering handoff addresses directly, and it applies as much to a new related job as it does to your original main job.

Keeping the Ecosystem Map Visible as You Work

Key Takeaways

• A main job is the core progress a product is hired for, defined independent of any solution; a related job is separate, adjacent progress the same customer pursues at the same time.
• Related jobs differ from consumption chain jobs (steps in acquiring or maintaining a solution) and emotional/social jobs (how customers want to feel or be seen) — Ulwick's Outcome-Driven Innovation framework treats all three as distinct categories worth tracking.
• A job ecosystem map plots related jobs around the main job, tagged by current owner and how well each is served, turning a vague sense of "adjacent opportunity" into something you can prioritize from.
• The lowest-risk expansion move serves a related job for customers you already have; a brand-new main job for a brand-new audience carries the highest risk.
• Score related jobs with importance minus satisfaction before committing a roadmap slot — a merely-decent job nobody serves well often beats an important job an entrenched competitor already owns.
• Real category history — QuickBooks expanding into payroll and lending, Ramp and Brex expanding into bill pay and travel — shows adjacency expansion, not new-market diversification, is how most software platforms actually grow.