Linear Method
The Linear Method is the published set of product development principles developed by Karri Saarinen and the Linear team. It grew out of how Linear itself operates: a company of roughly 50 people, profitable, with net-negative lifetime burn — meaning the business has spent less in total than it has earned. The method is not a management philosophy projected from theory; it is a description of how a small team ships a product used by tens of thousands of engineering organisations.
Core principles
1. Opinionated software
Give users good defaults rather than infinite flexibility. When software accommodates every workflow through configuration, users spend their time deciding how to configure it rather than doing the work it is meant to support. Linear makes choices: a fixed data model, a fixed set of workflows, a fixed set of views. Users who want something different are encouraged to adapt to the product, not the reverse.
The practical payoff is speed. Opinionated software is faster to build, faster to learn, and faster to use. The design constraint also forces the team to decide what the product is actually for — “build for every use case” is a way of deferring that question indefinitely.
2. Cycles
Cycles are Linear’s alternative to sprints. Like sprints, they define a bounded period of focused work against an agreed priority set. Unlike sprints, they run on an automated schedule and carry no deadline-crunch dynamic. The cycle ends when it ends; incomplete work rolls forward without ceremony.
The primary function of cycles is filtration. A team with an unbounded backlog can always find a reason to work on something other than the most important thing. Cycles force a decision: what belongs in this cycle, and what does not? Everything outside the cycle boundary becomes invisible for the duration. This is the mechanism by which cycles generate focus rather than merely organising work.
3. No OKRs, no per-feature metrics
Linear does not set OKRs or attach numerical targets to individual features. Quality is measured by feel and customer empathy — does this feel right, does it solve the problem cleanly, do customers report that it works.
The objection to numerical targets is not that measurement is bad but that the wrong metrics distort priorities. A metric attached to a feature creates an incentive to optimise for the metric rather than the underlying goal. When the metric diverges from reality — as engagement metrics routinely do — the team follows the metric. Saarinen’s alternative is closer to craft judgement: the team that built the thing, in close contact with the people using it, makes the call.
4. Project-lead ownership
Engineers and designers own projects end-to-end. Project leads — who may be engineers or designers — absorb the responsibilities typically assigned to a product manager: scoping, prioritisation, customer contact, trade-off decisions. There is no separate PM layer mediating between the people building and the people deciding.
The consequence for hiring is direct: every engineer must pass a product-sensibility screen. The team cannot carry engineers who build well but cannot think through product questions, because those questions will land on them. This raises the hiring bar and constrains team size — both of which Saarinen treats as features, not costs.
5. Main quest vs side quest
Saarinen uses the YC framing: there is a main quest and there are side quests. Main quest: talk to customers, build the product, exercise. Everything else — internal process, administrative overhead, status meetings, optimisation of internal tooling — is a side quest. Side quests are not forbidden; they are named, which makes their cost visible.
The framing resists scope creep in internal operations the same way cycles resist scope creep in product work. Naming the main quest is a forcing function for declining or deferring anything that does not directly advance it.
Context
Linear reached profitability with a small team and negative net burn — a result Saarinen attributes to the method as much as to the market. The operational discipline of the method (small team, high hiring bar, no PM layer, no metric-chasing) produces a cost structure that most venture-backed software companies do not attempt. It also produces a product with a reputation for craft quality unusual in project management software.
The method is published openly at linear.app/method and functions simultaneously as an operational guide and as a positioning document — it signals to potential customers and candidates what kind of organisation Linear is.
Parallel: Nan Yu’s IC-first philosophy
Nan Yu on Speed, IC-First Product Design, and the Extreme Version Method arrives at a structurally similar position from a different starting point.
Where the Linear Method eliminates the PM layer by giving engineers project-lead ownership, Nan Yu argues that the best product outcomes come from ICs who stay close to execution — and that the standard promotion path (IC → manager) actively degrades product quality by abstracting the best people away from the decisions that matter most. Both positions treat management-layer mediation as a cost, not a feature, and both produce high hiring bars as a consequence.