Reading Notes

Karri Saarinen on Linear, the Linear Method, and Craft-Driven Product Development

Source: Karri Saarinen on Linear, the Linear Method, and Craft-Driven Product Development

Four questions [Adler frame]

Q1. What is it about? How Linear was built — the product philosophy, organisational structure, and growth model behind a B2B project-tracking tool that became the default for early-stage startups. Saarinen argues that craft, taste, and focus compound into a competitive position that metrics-driven development cannot easily replicate. The episode covers the Linear Method as a published product philosophy, the absence of PMs as a deliberate structural choice, a paid work trial as the terminal hiring step, and a cohort-based wait-list strategy for finding product-market fit.

Q2. How is it argued? Saarinen reasons from personal experience at Airbnb and Coinbase, and from the observed failures of incumbent tools. His argument is structural rather than empirical: he does not cite A/B tests or activation metrics; he appeals instead to what makes a product trustworthy over a long relationship and what organisational conditions allow engineers and designers to notice and fix quality problems. The argument is practitioner testimony, not controlled experiment.

Q3. Is it true? Linear’s commercial outcome supports the broad thesis — profitable at under 50 employees, net negative lifetime burn. The claim that fewer, broader-scope people outperform larger specialised teams is directionally consistent with small-team productivity research but depends heavily on hiring quality that most companies cannot replicate. The no-PM structure works at 50 people with founder-led product direction; whether it scales beyond 100–200 is an open question Saarinen himself flags. The claim that opinionated software reduces cognitive overhead is well-grounded in cognitive load theory [?source], though it trades flexibility for opinionation in ways that may not suit all teams.

Q4. What of it? The Linear model is a coherent alternative to the Ramp/high-velocity/metrics-first model — not better in the abstract, but better for a specific product (long-retention B2B SaaS), a specific team composition (high-calibre generalists), and a specific competitive position (quality against legacy incumbents). The cohort wait-list strategy is a replicable growth tactic for early-stage B2B. The paid work trial is a strong signal-to-noise improvement in hiring that more companies could adopt.


Glossary

Linear Method. Linear’s published product philosophy: a set of principles for building software that emphasises speed, focus, opinionated defaults, and quality. Published as a public document to explain why Linear makes the product choices it does.

Opinionated software. Software that provides a single well-considered workflow rather than unlimited configurability. The argument: flexibility forces users to spend time deciding how to use the tool rather than using it. An opinionated default is the designer’s best solution; users adopt it rather than construct their own.

Cycles. Linear’s equivalent of sprints. A bounded, automatically scheduled time period in which the team commits to a defined set of work. Automated scheduling removes the overhead of manual setup. Called “cycles” rather than “sprints” because nothing is being sprinted toward — the cadence is continuous, not a race.

Craft. In Saarinen’s usage, craft is not about perfecting things before shipping. It is the discipline of shipping early (internally or to opted-in customers), noticing what is wrong, and fixing it quickly. Craft emerges from iteration speed and close attention, not from up-front polish.

Paid work trial. The final step of Linear’s hiring process. The candidate joins as a mini-contractor, receives a vague problem statement, scopes it, builds a solution in the Linear codebase, and presents it. The trial evaluates how a candidate operates in an environment of ambiguity and ownership, not just skill.

Product-market fit as spectrum. Saarinen treats PMF not as a binary (“I have it or I don’t”) but as a graduated position within specific customer segments. A company can have strong fit with early-stage startups and weak fit with Fortune 500 at the same time. The question is always: “How strong is the fit, and with whom?”

Product sensibility. The ability to form and articulate opinions about how a product should work, grounded in reasoning about users and context — not just preference. Saarinen tests for this in every engineering hire: can the candidate explain why a decision was right or wrong, not just whether they liked it?


Craft and iteration speed

Saarinen challenges the folk model of craft as upfront perfection. The concern with a perfection mindset is that it can block shipping: nothing is ever fully ready. Linear’s actual practice is almost its opposite: push things into the product as early as the first week after design explorations exist.

The sequence:

  1. Design explorations reach a rough state of direction.
  2. The feature ships internally — visible only to the team.
  3. A small cohort of opted-in customers gains access. The experience may be “a little janky” and incomplete; this is disclosed. Feedback shapes the next iteration.
  4. General release receives the full attention to polish.

Saarinen’s framing: “Craft is about always pushing things out very quickly, but then also fixing them, improving them very quickly.” The two commitments — speed and quality — are not in tension if the ship-fix cycle is tight.

The Andreas example illustrates how craft emerges from ownership rather than review. An engineer, not asked, noticed that the diagonal hover zone on sub-menus was broken (a common implementation shortcut). He built a dynamic safe-zone calculation that mirrors macOS behaviour. This happened because the engineer owned the feature end-to-end, had time to notice the friction, and worked in a culture that valued fixing it.

The corollary: formal review stages can suppress this kind of initiative. Linear does not require sign-off on every shipped change. The expectation is that engineers and designers will try things, observe, and iterate — with a full review before general release.


The Linear Method

Saarinen created the Linear Method to share the thinking behind product decisions — “here’s why we make some choices, because this is the way we think.” It serves both as external communication and as internal alignment.

Opinionated software. Productivity software should tell users how to work, not ask them to decide. Teams that configure their own workflow spend time on the tool rather than on the work. Linear provides a single well-considered default. The design principle: design for someone, not for everyone. A general solution is an over-diluted solution.

Cycles. Infinite backlogs are cognitively and operationally corrosive. Cycles impose a finite horizon: for this period, these things are the work. New requests do not automatically displace existing commitments; the team has an answer when asked why something was not done (“we decided to do X; something changed and we did Y instead”). Automated scheduling removes the ritual overhead of sprint planning.

No feature-level metrics goals. Linear tracks company-level metrics (weekly active users) but does not set numerical targets for individual features. Reasons: Linear is a multi-part system used by heterogeneous teams; a metric optimised in isolation can degrade system coherence; and the product is a trust relationship, not a transaction. The substitute: problem clarity. The team articulates the problem it is solving and evaluates success by whether customers agree the problem is solved. Data is used to understand, not to decide.

No A/B testing. Follows from the above. Saarinen describes the decision process as “magic and science.” The science is deep customer understanding — weekly calls, shared Slack channels with customers, everyone reading and answering support questions. The magic is the judgment that emerges from that understanding: the team makes informed decisions by intuition rather than by metric movement. Saarinen’s framing: “The data didn’t make that choice for us.”

Focus as default. Main quest vs. side quest. Any proposal that does not advance building the product and serving customers is a side quest and should be declined. The YC rule Saarinen cites: talk to customers, build the product, exercise. Anything else is probably wrong. He applied this to the decision of when to do podcasts: he waited until the scale and story were interesting enough to warrant the time.

Quality in hiring over quantity. Linear has never more than doubled headcount in a year. The core belief: a smaller team of high-calibre, broad-scope people outperforms a larger team of specialists. Specialists hand off; generalists own. Ownership produces the conditions for craft.


Hiring without PMs

Linear has one PM (head of product) at ~50 employees. The structural choice: project teams are engineering and design only. The lead can be either discipline; it is a project assignment, not a title.

Why this works. A PM who is not building the feature is not looking at it all day. Engineers and designers who own a feature end-to-end see opportunities the PM would not see — and have the authority to act on them. The Andreas sub-menu example is the proof of concept. The trade-off: engineers and designers must do PM-type work (scope, communicate timelines, write specs, run meetings). Not everyone wants to do this; Linear hires for people who do.

Product sensibility in engineering interviews. Saarinen cannot interview engineers on PM concepts formally — their vocabulary and frameworks differ. Instead, he probes through project retrospectives: Why was this decision made? Do you think it was right? What would you have done differently? The quality of the answer scales with product sensibility. A weak answer: “I didn’t like it.” A strong answer: reasons grounded in user context, edge cases, or trade-offs. “When you see someone who really thinks about this stuff, it’s very clear — they can just talk about it forever and go deeper and deeper.”

The paid work trial. Every hire at Linear completes a paid work trial. The candidate receives a vague problem statement (“there’s this feature that needs to be built — build it”), accesses the codebase, scopes, builds, and presents. Trial length varies by role. Access is broad: Slack, Notion, one-on-ones with teammates.

What the trial evaluates:

  • Comfort with ambiguity and self-directed scoping.
  • Ability to make progress in a short time — a startup prerequisite.
  • How the candidate thinks and operates, not what they can recite.

What the candidate evaluates:

  • What the code base looks like in practice.
  • How the team communicates.
  • Whether the company is what it claimed to be.

Saarinen notes that almost no candidate has declined the trial; the majority report that it gave them substantially better confidence in the decision they were making.


Growth model

The cohort wait-list strategy. Linear announced in April 2019 with a wait list. Within a month, Saarinen and the co-founders used the product themselves. By June, they began inviting users from the wait list — initially ten per week. The wait-list signup included a short survey: what tools do you use today, why do you want Linear, what is your company size? Saarinen read surveys in a spreadsheet and emailed invites manually from his personal account.

The rationale for slow cohorts: if everyone is invited at once, everyone hits the same bugs at the same time. The feedback is redundant and the fix cycle is inefficient. Inviting small cohorts means each cohort surfaces a concentrated set of problems; fixing those before the next cohort means the next cohort encounters a better product.

By June 2020 (one year after the private beta), Linear had several hundred companies. At public launch, Linear introduced pricing. One company did not subscribe; all others converted to paid.

PMF as spectrum. Saarinen refuses the binary (“do we have it or not?”). He tracks fit by segment: early-stage startups (primary), mid-sized growth companies (active work), enterprise (future). The goal in the first two years: become the default for startups. Once that segment was captured, the team expanded attention to larger companies. Concurrent to the expansion, crypto companies became early adopters, then AI companies — Saarinen watches these cluster patterns and adjusts accordingly.

Following the pull. Saarinen cites Eric Yuan (Zoom) on early growth: when one customer type is working extremely well, focus entirely on getting more of that customer type before expanding. Zoom concentrated on universities. Linear concentrated on YC graduates and growth-stage startups. The pattern: notice a cohort that pulls, go deep before going broad.

Brand as acquisition. Saarinen connects brand directly to acquisition economics. A strong brand converts customers who go directly to the product (as Airbnb captured direct traffic) without requiring paid search or SEO. The brand is built by how every touchpoint is designed — the product, the website, the announcement copy, the way customers are treated. It is not a logo decision; it is an accumulation of choices over time. Linear’s announcement succeeded in part because it was written in the voice of practitioners, not a corporate press release, which made it legible to the exact audience it was targeting.

Linear links to Product Taste as an underlying capability: the team’s shared taste for quality propagates from product decisions through brand perception.