Linear — The "Why" Layer
Linear is the best project tool I've used. It's also missing something important.
Product: Linear
Category: B2B SaaS — Project Management / Issue Tracking
Focus: What Linear gets right about speed, and what it gets wrong about PMs
What It Does
Linear is an issue tracking and project management tool built for software teams. It's the opinionated, fast alternative to Jira — designed around the belief that project management software should feel like a native desktop app, not an enterprise configuration exercise.
Who It's For
Primarily software engineering teams at high-growth startups and mid-size tech companies. The core user is a developer or engineering manager. PMs and designers use it too — but they're secondary users. Linear is built by engineers, for engineers.
What They're Really Optimising For
Speed. Not just product speed — the speed of the tool itself. Linear is obsessed with making issue management feel instant: keyboard-first navigation, sub-100ms interactions, no loading spinners, a UI that gets out of the way. The underlying bet is that if the tool is fast and opinionated enough, teams will actually use it — and that's the real problem they're solving. Most project management software is abandoned because it's too slow and too painful to maintain.
What's Working Well
The experience is the product. Linear's interface is genuinely fast. Cmd+K opens everything. Issues are created in two keystrokes. Cycles (sprints) auto-archive without ceremony. The keyboard-first design isn't a feature — it's the philosophy, and it permeates every part of the product. For developers who find Jira a chore, Linear feels like a tool built by people who actually use it.
Cycles force good habits without requiring discipline. Linear's sprint equivalent (Cycles) has a clean mechanic: incomplete issues roll over, completed ones archive, and the next cycle starts clean. There's no configuration burden, no sprint ceremony — it just works. This is a good example of opinionated design reducing friction: the tool makes the right behaviour the easy behaviour.
The status model is well-designed for engineering workflows. Todo → In Progress → In Review → Done maps directly to how engineers actually work. The addition of "Cancelled" and "Duplicate" as explicit states (rather than just deleting issues) keeps history intact without cluttering the active view.
Project-level views are getting genuinely useful. The Roadmap view and Projects layer give teams a way to think above the issue level — grouping work into initiatives with milestones. It's not as mature as dedicated roadmapping tools, but it's directionally right.
What's Broken or Missing
Linear is built for engineers, and PMs feel it. The tool is excellent at tracking what's being built and whether it's done. It's weak at the upstream and downstream PM work: why something is being built, what customer problem it solves, and whether it delivered value after it shipped. There's no native space for linking issues to customer feedback, business outcomes, or success metrics. PMs end up maintaining a separate doc or Notion page for the "why" while Linear handles the "what."
Roadmapping is still too close to the issue layer. Linear's Projects and Roadmap views are built up from issues — which means the roadmap reflects engineering scope, not strategic intent. A PM trying to communicate a product direction to stakeholders or executives needs to translate from Linear's issue-level view into something that makes business sense. That translation happens outside the tool, in a slide deck or a doc, every time.
Prioritisation has no business context. Linear lets you set priorities (Urgent, High, Medium, Low) but the system has no awareness of why something is high priority. There's no way to connect a priority to a customer segment, revenue impact, or strategic goal. The result is that priority labels drift over time — everything becomes High, and the signal degrades.
Integrations exist but context doesn't travel. Linear integrates with Figma, GitHub, Slack, and others. But context rarely moves between them in a meaningful way. A Figma link in an issue doesn't bring the design in. A GitHub PR closing an issue doesn't surface the commit message to the PM. Integrations check a box without genuinely bridging the tools.
One Thing I'd Change
I'd add a "Why" layer to every issue and project — a lightweight field for linking the business problem, customer evidence, or strategic goal the work is solving.
Not a free-text description (that already exists and nobody reads it). A structured connection: link to customer feedback, attach a metric you're trying to move, reference a goal from the roadmap. When the issue is closed, that connection persists — so you can ask "did this work?" six weeks later.
This would make Linear genuinely useful for PMs, not just engineers. Right now Linear tracks work. This would make it track outcomes. The data model is already there (issues have relationships, projects have milestones) — it's a product decision to extend it upward into the "why," not just sideways into the "how."
It would also differentiate Linear from Jira in a direction Jira can't easily follow. Jira is too configuration-heavy to add lightweight context fields in a way that teams actually use. Linear's speed and simplicity is the reason a "why" layer would work there — it has to stay frictionless.
What This Product Teaches Us
Opinionated design is a growth strategy. Linear made deliberate choices that exclude certain users (large enterprise, non-technical teams) in order to be genuinely great for a specific user (fast-moving engineering teams). That focus is why it has the reputation it does. Most products try to serve everyone and end up serving no one particularly well.
Speed is a feature you can't retrofit. Linear's performance isn't a result of optimisation — it's a result of architectural decisions made at the beginning. Teams building collaboration tools should think about perceived performance as a core product value from day one, not a polish task at the end.