> ## Documentation Index > Fetch the complete documentation index at: https://meta.niceshare.site/llms.txt > Use this file to discover all available pages before exploring further. # Product Thinking > Product Thinking starts with the user outcome and the business constraint, then measures change—not features shipped. Origin, Superhuman, limits. **Category**: Thinking
**Type**: Cognitive Framework
**Origin**: Drucker, 1954; Levitt, 1960; Cagan, 2008; Perri, 2018
**Also known as**: Product mindset, thinking in products not projects, outcome-oriented product work **Quick Answer** — **Product Thinking** is the habit of deciding what to build—and what to kill—by starting from a user outcome that also works for the business and the technology, then measuring whether behavior changed. Drucker named the purpose as creating a customer; Levitt named the trap as loving the railroad more than the ride; Cagan and Perri turned the habit into a public method. The working insight is simple: a shipped feature is not yet a result. ## What is Product Thinking? Product Thinking is the skill of treating every build as a bet on a change someone would miss, at a cost a market and an organization can repeat—not as a slot on a roadmap or a request to fulfill. > The build trap is when organizations become stuck measuring their success by outputs rather than outcomes. That is Melissa Perri in *Escaping the Build Trap* (2018). [Design thinking](/thinking/design-thinking) asks how a solution might feel for a person. Product Thinking asks the prior cut: is this a problem worth solving for people we can serve, can we deliver it, and did anything change after we shipped? The everyday picture is a kitchen that keeps buying gadgets. A new spiralizer arrives because it looked clever. Product Thinking starts one step earlier: Which Tuesday dinner actually gets eaten? Who would notice if this tool vanished? Can we afford to keep using it? A feature request, a “quick add,” and a civic app with twelve unused tabs are spiralizers with sponsors. [Entrepreneurial thinking](/thinking/entrepreneurial-thinking) starts from means and a loss you can afford. That is how you search when the market is still fog. Product Thinking is the later, tighter job: pick a repeatable outcome, name who it is for, and refuse to count shipment as proof. [Jobs to be done](/methods/jobs-to-be-done) names the progress someone is hiring a solution for. Product Thinking decides whether to build a product around that job, or to leave it alone. ### Product Thinking in 3 Depths * **Beginner**: A feature is not a result. The cue is a backlog item that already has a solution in the title, a “we should add,” or a family tool nobody opens twice. * **Practitioner**: Before you build, write four lines: who it is for, what would change for them, how we would know, and what we will not build. Then pick the smallest test that could falsify the bet. * **Advanced**: Most ideas fail a hidden risk. Mature practice holds value, usability, feasibility, and business viability at once, and keeps narrowing the market until a real someone would be disappointed to lose the thing. ## Origin Product Thinking began as a way to stop confusing what you make with why anyone would miss it. It is not a nickname for a job title. In **1954**, **Peter Drucker** wrote in *The Practice of Management* that there is only one valid definition of business purpose: to create a customer. Profit, he argued, is a result, not the purpose. In **1960**, **Theodore Levitt**’s “Marketing Myopia” in the *Harvard Business Review* named the corporate version of gadget-love. Railroads, he wrote, let others take customers because they assumed themselves to be in the railroad business rather than the transportation business: product-oriented instead of customer-oriented. The practitioner name is younger. In **2008**, **Marty Cagan**’s *Inspired* described how strong product teams separate discovery (what is worth building) from delivery (building it well). In a **2017** Silicon Valley Product Group note, he split the work into four risks: value, usability, feasibility, and business viability. A later note stated the product as *customer × business × technology*—any zero makes the product zero. In **2018**, Perri published *Escaping the Build Trap* and made the output/outcome split a public diagnosis. The same year, **Rahul Vohra** wrote up Superhuman’s product-market fit engine in *First Round Review*, turning **Sean Ellis**’s “very disappointed” survey into a working loop. Adjacent methods—[minimum viable product](/methods/mvp), lean loops, continuous discovery—are tools this habit can pick up. They are not substitutes for the habit. ## Key Points Product Thinking earns its keep when something is about to be added, funded, or called “done.” It fails when you treat the first requested solution as the work. A request that already contains the solution—“add a dashboard,” “we need an app”—is a guess wearing a ticket. Rewrite it as a change: who is stuck, what would be different if we succeeded, and how we would see it. Intercom’s public rule is the same cut: start with the problem. If you cannot name the problem without naming the widget, you do not have a product bet yet. You have a shopping list. Cagan’s four risks are a checklist against one-sided love. Value: will they choose it? Usability: can they figure it out? Feasibility: can we build it with the time and skills we have? Viability: does it work for sales, cost, law, and brand? [Design thinking](/thinking/design-thinking) is strong on the first two. Product Thinking refuses to call a delightful prototype “the product” if the other two are zeros. Story points, release trains, and “we shipped it” are outputs. An outcome is a change in what people do, pay, or return for. Perri’s build trap is the habit of using the easy proxy—features delivered—because the real value was never defined. Pair this with [Drucker’s effectiveness principle](/principles/drucker-effectiveness): doing the thing right is not the same as doing the right thing. A product that tries to please every persona usually pleases none enough to be missed. Levitt’s question—“what business are you really in?”—is a market cut, not a slogan. Superhuman’s first gain in fit came from dropping personas, not from adding features. [Economic thinking](/thinking/economic-thinking) prices the alternative use of the same engineers. Saying no is the product. ## Applications Use Product Thinking when a build is about to be treated as progress. Do not use it as a reason to freeze a one-off job that already has a clear spec and a hard date. A course, a tutorial, or an onboarding flow is often a pile of modules. Ask which lesson a learner would miss if it vanished, and what they can do after that they could not do before. Cut the rest. If the title of the work is already a format—“add a video,” “write a handbook”—you are still in gadget mode. In a review, refuse a ticket that only names a widget. Write the user, the change, the signal, and the four risks on one page. If value is the open risk, do not start with a feasibility spike. Use the smallest [MVP](/methods/mvp) that could falsify the bet, then keep the engineers on the outcome, not on the original sketch. A shared calendar, a meal plan, a family chat with seventeen groups: each was added because it sounded useful. Name who it is for, what Tuesday looks like if it works, and who would be disappointed if it disappeared. If nobody would notice, archive it. You are not running a startup. You are refusing a drawer of unused gadgets. A city portal, a PTA program, or a volunteer app can ship twelve tabs and still fail. Pick one job people already try to do—pay a fine, find a slot, sign up once—and measure repeat use, not ribbon-cuttings. If the only success metric is “we launched,” you are in the build trap with a press release. ## Case Study The numbered public window onto Product Thinking is not a famous launch day. It is **Superhuman**’s 2017–2018 attempt to stop guessing whether a beautiful email client was a product anyone would miss. By the **summer of 2017**, the team had a fast client in beta and no shared way to say “we are ready.” **Sean Ellis**, after comparing nearly **100** startups, had offered a blunt survey: *How would you feel if you could no longer use this product?* Companies that later grew usually had more than **40 percent** of active users answer “very disappointed.” Those that struggled usually sat under that line. Superhuman asked people who had used the product at least twice in the last two weeks. The first number was **22 percent**. Vohra did not treat 22 as a verdict to add more features. He added three questions: who the product is best for, what the main benefit is, and how to improve it. After segmenting to the people who already loved it, the score among that set was **33 percent**—a market cut, not a new widget. The team then used the “somewhat disappointed” users who already named the core benefit, and spent three quarters building toward that disappointment line. By the time Vohra wrote the method up in *First Round Review* (**13 November 2018**), the score was **58 percent**. Boundary note: a survey of early users is not a full business, and “very disappointed” is not ethics, cost, or retention. Superhuman chose a narrow, paying user. The transferable lesson is the first move. Before you inflate the product, name who would miss it. Then measure that, not the release train. ## Boundaries and Failure Modes Product Thinking fails when the work is a one-off with a known spec and a date that cannot move: a wedding, a compliance filing, a bridge that must open on Tuesday. That is project thinking, and it is the right tool for a closed job. Borrowing “outcomes” as wallpaper on a fixed deliverable only adds meetings. It also fails when there are no users yet and no way to see a change. Then you need [entrepreneurial thinking](/thinking/entrepreneurial-thinking) and a cheap test, not a product-market fit survey of an empty room. Discovery that never ships is another stall: “we need more research” can be a way to avoid a small, visible bet. The common misuse is the slogan. Teams rename the backlog “outcome-oriented,” keep counting story points, and call the launch a result. Another misuse is “the customer is always right”: copying every request is a feature factory with extra listening. A third is design-thinking theater that ships a delightful prototype the business cannot sell and the stack cannot run. Cagan’s product is a product only if none of the three factors is zero. ## Common Misconceptions The English name collides with a job title, with shipping on time, and with doing whatever users ask. A title can help. It is not the habit. Engineers, designers, teachers, and a parent choosing a household tool can practice it. Frameworks—JTBD, MVP, Kano, story maps—are optional instruments. The habit is naming the outcome, the user, and the kill criteria before the widget. That is project thinking: scope, date, and a done checklist. It is useful when the spec is already right. Product Thinking treats the spec as a hypothesis. If nobody’s behavior changed, the train still ran. The product did not. Requests arrive as solutions. The job is to recover the problem, then decide whose problem is yours. Superhuman’s first gain came from dropping personas, not from building for every beta user. Empathy without a market cut is a longer shopping list. ## Related Concepts These pages sit next to the same problem: how to decide what is worth making without confusing shipment with value. Empathizes and iterates a human solution. Product Thinking adds whether a market would miss it and whether the business can repeat it. Starts from means and affordable loss under uncertainty. Product Thinking is the tighter cut once a repeatable outcome is in view. Names the progress a person is hiring a solution for. Product Thinking decides whether to build a product around that job. Is the smallest test of a product bet. Product Thinking is the habit that decides what the test is for. Separates doing things right from doing the right things. Product Thinking applies that cut to what gets built. Prices a choice by what you give up. Saying no to a feature is that price, paid in engineers and attention. ## One-Line Takeaway Before you add a feature, name who would be disappointed if it vanished—and who would not notice.