How Linear builds beloved B2B software without the bloat

Executive overview

Most B2B tools become bloated because PMs say yes to customisation requests from middle managers, wrecking the experience for the people actually doing the work. Linear's answer is a hard policy: if a feature helps managers report on ICs rather than helping ICs do their jobs, the answer is always no.

The broader system behind this is four interlocking practices: ship a working version in the first 10% of the time budget, anchor every decision to a named real person, find the emotion customers want to avoid, and explore extreme product directions before settling on the right one.

Building for the IC, not the buyer, is the core promise Linear will never trade away.

Speed and quality are not a trade-off

• Confusing speed with sloppiness is the mistake. The right frame is competence: experts go fast because the work is second nature.
• Measure speed by when you have something testable, not when you ship. A workable version should exist at the 10% mark of any project timeline.
• No expectation that the first version is good — it only needs to validate or invalidate the key assumption.
• Engineers who get blocked by every design choice slow everything down; the team ethos is to bust through uncertainty and produce something real.
• Iterations are the product of speed. How good the final output is depends on how many cycles you could run.

Releasing progressively to learn

• Internal users are the first ring; Linear uses its own product every day, which gives it an immediate feedback loop.
• Once stable enough to avoid data corruption, features move to an early-access customer group.
• Usage (or the absence of it) is the primary signal. If nobody engages, the direction was wrong.
• The goal is to reach a real go/no-go decision at launch time — a working product that can conceivably ship, even if under-featured.

The anti-bloat policy

• Bloat comes from one specific category: customisation features requested by middle managers to make reporting easier at the cost of IC workflows.
• This category gets a hard no with no debate — Linear has pre-committed never to take a single step down that path.
• ICs disengage from tools that add friction. When they disengage, the data becomes garbage, which defeats the reporting goal anyway.
• Buyers care whether the tool makes their team more effective. Convincing them that manager-reporting features actually undermine that goal is part of the sales conversation.
• Infrastructure features (SAML, SCIM) are different and are shipped as a matter of course.

Tying decisions to real people

• Every feature debate should be anchored to a named, reachable person — first name, last name, email — not a hypothetical persona.
• When a broad feature request comes in (e.g. custom fields), dig into what people actually want; in one case, 40% were solving the same underlying problem (linking customer names to issues), which became the native "customer requests" feature.
• If a solution is beautiful but doesn't match how real workflows operate, it has no long-term staying power.
• A feature that a hundred people request in a hundred different ways is not necessarily worth building in a general form; look for dense clusters of identical use cases instead.
• Two diagnostic questions: (1) Did we think about this wrong and are now learning something about reality? (2) Is there a specific concentrated use case hiding inside this general ask?

Finding the emotion customers want to avoid

• The goal on a customer call is to feel bad in the same way the customer feels bad — not to extract goals or job-to-be-done language, but to reach the emotional moment driving the request.
• Surface-level answers ("marketing and I never align") hide the actual incident ("I entered December 30 as a ship date and my marketing team lost their mind"). The incident reveals the feeling; the feeling reveals what to build.
• Linear's variable-precision date feature (Q4, second half, specific date — whatever level you're comfortable promising) came directly from this kind of conversation.
• Schlep blindness (Paul Graham's term) is why this matters: people are so accustomed to the friction in their workflow that they don't see it as solvable. An outsider has to name it.
• Triage management — the feature that automates routing of incoming issues — came from two feelings: "I'm underwater managing this by hand" and "tickets just disappear over the wall."

Systematising creativity: explore the extremes

• Creative blocks usually come from exploring too narrow a range of options. The fix is to ask: what is the most extreme version of this along some key dimension?
• This is not a thought experiment — build the extreme version as fast as possible and feel it. It will be wrong, but it will reveal the right answer faster than careful iteration from the centre.
• Example: the draft-saving feature. The "fastest/most minimal" version felt unsafe (no confirmation prompt). The "safest" version (autosave on every keystroke) created a clutter of untitled drafts. The shipped solution was a hybrid: prompt once on a brand-new issue, then autosave silently on all subsequent edits to that draft.
• Every product has a core promise (for Linear: speed, for a ride-share: always available vs. always predictable price). Explore the extremes of that promise to find where the right answer lives.

Backlog as accumulating conviction

• At any time there are ~20–30 opportunity areas under consideration, none ready to build yet.
• The backlog entry for each area is a live document: the current best understanding of how Linear might approach the problem, visible and editable by the whole team.
• Capacity planning is an example sitting in this state: the problem is clear (managers struggle with resource allocation), all existing solutions are bad (custom spreadsheets), but the right scope and approach hasn't been cracked yet.
• A key question is not just "do we have a workable solution?" but "how much of the problem should we actually own?" Over-promising a scope the team can't deliver is its own failure mode.

B2B software teaches people how to work

• Every B2B tool embeds a set of practices — when you adopt the tool, you adopt the practices, whether or not you knew about them before.
• The most opinionated Linear features (triage rotation, the Linear method) represent practices observed consistently across high-performing teams, now available as a single button to activate.
• Buyers who want their team to "act like a startup" are buying a way of working, not just a set of features.

The double-triangle collaboration model

• The PM sits at the intersection of two triangles: engineering–product–design on one side, and sales–marketing–product marketing on the other.
• Product management is a go-to-market discipline, not just a building discipline.
• PMs typically under-invest in the sell side. The biggest lever is originating the language that marketing and sales use — PMs have the deepest understanding of how customers actually talk about their problems.
• A dedicated product marketer embedded in the PM team (not in a separate marketing function) is what drives consistent, accurate language from discovery through release notes to campaigns.
• Sales validates the messaging in the field and feeds back whether it's landing.

Deadlines as P0 events

• Don't have many deadlines. When you commit to one, it is a P0: the engineer works on nothing else, scope is cut aggressively to make it possible.
• The goal at deadline is to have a shippable product — not necessarily the full vision, but something real enough that you can make a genuine go/no-go call.
• Marketing communication windows are finite and non-recoverable. Missing a quarter's launch slot is not neutral; it's a permanent loss of that opportunity.
• No estimating required to hit deadlines — the discipline of shipping something workable at 10% of the time budget is what creates the optionality to say yes at launch.

Getting a PM job

• Figure out the hiring manager's job-to-be-done before the interview. What burning problem are they hiring this PM to solve?
• Frame yourself as the specific solution to that problem, not as a broadly excellent candidate. You vs. the field beats you vs. N interchangeable candidates.
• Ask specific questions: "What are your OKRs this quarter? How can I help you hit them?" This signals you're already thinking as a colleague.
• Request introductions to engineers or designers on the team. No other candidate will have done this; the debrief feedback will be different as a result.
• Invest deeply in the companies where you can genuinely over-deliver, because those are the jobs where success on both sides of the hire is most likely.

Lightning round

• Most recommended book: The Design of Everyday Things by Don Norman — everything you interact with is a product someone designed, and most of it can be improved.
• Favourite life motto: "The correct amount is too much minus one." To find the right level, you sometimes have to overshoot and feel what too much looks like.