Linear vs Jira

Jira won project management by being able to become anything. Twenty years of plugins, custom fields, workflow schemes and permission matrices mean a Jira instance can model any process a company has ever had, including the ones it should have abandoned. The cost of that flexibility is paid by the people who do not configure it: individual contributors, who open a ticket and wait for a server round-trip, learn a workflow that differs from the team next door, and spend a measurable slice of every day fighting the tool rather than the problem.

Linear made the opposite bet. It decided what a good engineering workflow looks like, encoded it as the default, and refused most of the customisation that would let a team drift away from it. It is faster because it is local-first; it is simpler because it is opinionated; it spread because the first thirty seconds of using it make the contrast with the incumbent obvious. This note is about why that bet worked, and what it says about product management generally.

The problem Jira actually has

Jira's problem is not that it is slow, though it is. It is that it optimises for the wrong user. The admin who configures a workflow is a different person from the engineer who lives inside it, and Jira's flexibility serves the first at the direct expense of the second. Every custom field is a small tax on every ticket. Every plugin is a small inconsistency between teams. Every week of setup before a team gets value is a week in which the tool is a cost and not yet a benefit.

Two failure modes follow from that. Intake becomes chaos, because a backlog with no opinion about triage accepts everything. And scaling becomes political, because bottom-up adoption by engineers runs into top-down control by admins, and admins own the configuration.

What Linear did instead

Local-first architecture. Every action (creating an issue, changing status, assigning) happens on the client immediately and syncs to the server afterwards. The perceived speed is not an optimisation of the same design; it is a different design, and it is the single largest reason the product feels the way it does.

Encoded workflow. Cycles roll automatically. Triage is a native inbox, not a plugin. Projects have a shape. The eighty percent of what good engineering teams do by hand in Jira is simply how Linear works out of the box, which turns onboarding from weeks into an afternoon.

Keyboard-first discovery. The command palette is not a power-user feature bolted on later; it is the primary interface, and it makes the product's value discoverable in the first session.

Constraint as strategy. Linear rejects features that would compromise speed. That sounds like a slogan until you notice how many requested features it has publicly declined, and that it has shipped a product this coherent with a very small product team.

Bottom-up scaling. It started as a tool engineers chose for themselves, and added SSO, audit logs and enterprise controls only after teams inside large companies had already adopted it. The enterprise sale was a formality by the time it happened.

Design principles I take from it

Speed over flexibility: any feature that slows the core loop for the majority is not worth the edge case it serves. Encoded best practice: productise what the best teams do manually, as defaults. Build for the individual contributor, because they are the ones who bring the tool in. Treat a performance budget as a product decision, not an engineering one. And make the value visible in seconds. A product that needs a demo deck to explain itself has already lost to one that does not.

What I would measure

Time from signup to a team's first real cycle. Median latency of the ten most common actions, measured on the client. Share of teams still using the default workflow after ninety days: the number that tells you whether the opinion held. And qualitative: how a new engineer describes the tool after one week, unprompted.

The learning

Product managers do not win by saying yes to more. Linear is an argument that ruthless constraint scales faster than infinite flexibility, particularly when the users you constrain are the power users who evangelise inside their own companies. Saying no strategically is the job.