Linear

Linear's origin story is rooted in direct observation of pain. Karri Saarinen watched engineers at Coinbase and Airbnb—two of the most innovative companies in tech—spending their days fighting with JIRA and other incumbent project management tools. These weren't small annoyances. The friction was real enough that it made talented engineers actually dislike their work. Saarinen realized that everyone on the team had gotten into engineering and design because it was fun—they'd built side projects and MySpace pages as kids because creation was thrilling. But incumbent tools were creating "big speed bumps into the day-to-day workflow." That disconnect became Linear's founding thesis: build something so fast, so beautiful, and so thoughtfully designed that it would actually make engineers *want* to use it.

Linear's approach to product development rejects a common industry orthodoxy: the speed-vs.-quality tradeoff. The team realized this false choice exists because most people conflate "speed" with "rushing and being sloppy." Instead, Linear operationalizes speed as competence. At the pinnacle of any craft—whether chess, cooking, or software—the fastest practitioners also produce the highest quality output.

Non U, the Head of Product, describes Linear's iteration cadence with striking precision: "By the time 10% [of the timeline] has passed, after a week one, you have something that works that tests some kind of key hypothesis internally." This isn't a polished prototype. It's a working artifact that immediately reveals whether the team's core assumptions are sound or dangerously wrong. Waiting until 50% completion to validate is a trap that kills products; waiting until 80% is death. Speed, in this model, is about *learning velocity*.

The team didn't need pixel-perfect designs or zero UI bugs in early versions. What mattered was working software that could answer a single question: does this actually solve the core problem? Early versions ship internally first—Linear's team uses Linear daily—then to hand-picked beta customers, expanding the feedback circle until the feature has been battle-tested across multiple user types before general availability.

Linear entered a crowded market dominated by JIRA, Monday.com, Asana, and others. The entry strategy wasn't to be incrementally better; it was to be radically more delightful. Survey data from Lenny's newsletter showed the devastating verdict: when asked which tool they'd switch to if IT allowed them, respondents overwhelmingly picked Linear. The reasons clustered around three themes: speed ("performance and speed is a massive productivity boost"), design ("Linear's design is obviously an industry benchmark"), and usability ("simple to use, yet powerful").

Growth came primarily through word-of-mouth and product evangelism. Engineers who experienced Linear felt so much less friction in their days that they naturally advocated for it. By the time Linear began targeting enterprise, it had built enough brand penetration that large companies could feel that Linear was "for us"—the company that wants to act like a startup, that values speed and elegance.

Linear's most controversial strategic bet is also its most successful: ruthlessly prioritizing individual contributors (ICs) over managers. When a large customer requests customization—say, a new field to track which customer requested a feature, or a dropdown for complex reporting—Linear asks a hard question: does this make the IC's workflow worse? If yes, the answer is no, regardless of deal size.

This isn't stubbornness; it's incentive alignment. When a manager asks an IC to fill in nine custom fields with unclear definitions, the IC doesn't. They either skip the step or pick randomly. The data becomes garbage. Reports built on garbage data have no value. By refusing to add these features, Linear made a promise: we will never make your work harder in service of someone else's reporting.

When 40% of custom field requests turned out to stem from one core need—"I have a customer and need to track what we've built for them"—Linear didn't build custom fields. Instead, they built Customer Requests: a native feature that automatically tags issues with the customer who requested them by integrating with CRM and support tools. ICs gain context without friction. Managers get the reports they need. Everyone wins.

Linear's approach to understanding what to build is equally distinctive. Non U describes a process of finding the *emotional valence* behind feature requests. He doesn't ask "what is your goal?" Instead, he digs until he understands the moment a customer felt bad. One team member had marked a December 30th ship date because it was end-of-Q4. Marketing exploded—nobody ships before New Year's. The conversation revealed the feeling: false precision creates downstream miscommunication. Linear's solution: flexible date fields ("Q4 project" or "December" instead of exact dates) that let teams commit at their comfort level.

Another example: triage management. Some teams manually routed incoming issues, which felt overwhelming despite being "on top of it." Others let tickets get lost. The emotional hooks were different but the root cause was identical—no automated system for organized triage. Linear built one, systemizing what had been manual and chaotic.

Linear has crossed into enterprise, which was once thought impossible for a tool that refuses manager-centric customization. Enterprise growth is now the company's fastest-growing segment. The inflection point came when Linear achieved enough brand recognition that large companies saw themselves in it—as organizations that desperately want to move fast but are trapped by slow tools.

The team maintains a backlog of 20-30 unexplored opportunities, continuously deepening their mental model of user needs without rushing to build. Capacity planning, for instance, sits in the backlog because while every team struggles with it and solutions are poor, Linear hasn't yet found an elegant approach. They'll keep talking to users, accumulating understanding, until they crack it.

Linear's success comes from a deceptively simple insight: most enterprise software fails because it optimizes for the wrong person. Linear optimized for the person who actually does the work, making their day marginally less terrible, a thousand times per day. In a market of bloated, slow, customization-heavy tools, that philosophy became an unassailable competitive advantage. It's not just that Linear is better; it's that using Linear *feels* better.