Jobs to be done

Most founders pitch their product’s features. Most buyers, however, do not hire features. They hire a product to accomplish a specific outcome in a specific situation. Discovering that outcome, and building a motion around it, is what separates a tool that people adopt from a tool that people abandon.

What a job is

A job-to-be-done is the progress a customer is trying to make. It is always tied to a context.

Consider Slack. The feature is “group messaging.” The job is not “send group messages”—people could send group emails or use IRC for that. The job, for the early adopter teams Slack targeted, was “make knowledge searchable and asynchronous so that new hires can onboard without constant interruption and we can stop losing context to closed email threads.” That job lived in a specific moment: when growing startups hit the “too many emails” ceiling and remote work was becoming normal.

Or Stripe. The feature is “process credit card payments.” But the job, for its first customers (app developers at Y Combinator), was not “process credit card payments”—payment processing existed. The job was “build a business model around my app in one afternoon, without talking to a bank or learning obtuse XML schemas.” Stripe sold that job to developers before it sold it to merchants. Different market, different job, different motion.

Or Figma. The feature is “design collaboration.” The job is not “design collaboration”—InVision and other tools offered that. The job for Figma’s early adopters was “make design feedback as fast and as native as code review,” and implicitly, “unseat Photoshop and Sketch as the source of truth for design systems.” Different teams need different jobs from the same tool.

How to spot a misaligned job

Many products fail because the founder built a great product to solve the wrong job. This happens when the founder guesses at what customers want instead of watching what customers are trying to do.

Listen to why people switch. If a customer is considering leaving their incumbent, the reason is not “the new product is faster.” The reason is “the new product solves a job that the incumbent does not.” A customer unhappy with their current solution will stick with it if it is “good enough” unless a new product solves a different job or solves the same job with less friction. When you ask customers why they chose you over incumbents, listen for what job they were stuck with before. That is the real job.

Watch what customers optimize for in practice. If your motion says “saves time,” but customers use your product to “reduce error,” you are selling the wrong job. If your motion says “team visibility,” but customers celebrate because “we finally have one source of truth,” you are selling the wrong thing. Watch what they optimize for, what they measure, what change would make them stop using you. That is the job.

Segment by job, not by firmographic. Two companies of the same size, industry, and stage may hire the same product to solve completely different jobs. A Series-A startup might hire a project management tool to “keep my co-founder in sync.” A Series-C version of that same company might hire it to “keep my managers accountable for deadlines.” The product is the same. The job is different. The motion must be different too.

Building a GTM around the job

Once you know the job, the GTM flows from it. You do not target “small businesses” or “remote teams”—you target the situation that creates the job. You do not lead with features; you lead with the outcome.

Slack’s early motion: “Are you drowning in email?” The job emerges from the question. The feature (Slack) is almost incidental.

Stripe’s early motion: “Ship a business model this week.” Not “process payments.” The job is there in the frame.

Figma’s early motion (internal): “Replace Sketch, but for teams.” The job is “be the source of truth for design,” not “collaborate on designs.”

When your GTM is built around the job—the actual outcome people are trying to achieve in a specific situation—your messaging becomes focused, your customer acquisition becomes efficient, and your retention improves because users stick around for the job, not just the feature.