How does Linear's cycle system differ from Scrum sprints?

Linear's two-week cycles share the same time boundary as typical Scrum sprints, but they strip away most of the ceremony. There is no sprint planning meeting with story point estimation, no velocity tracking, and no sprint review or demo. A cycle is a commitment to a set of issues. The team works through them and ships what is ready. There is no "sprint goal" or burndown chart. This makes cycles lighter and faster to plan but requires more individual discipline from PMs and engineers.

Why does Linear skip estimation entirely?

Linear's position is that estimation is a poor use of time. Story points and t-shirt sizes create an illusion of predictability without actually improving outcomes. Instead, Linear's PMs break work into tasks small enough that each one takes a day or two. When every task is roughly the same size, you do not need to estimate. You just need to count. This approach works well for experienced teams that can decompose work effectively. It may be harder for teams that are still learning to scope.

How do Linear PMs decide what to build?

PMs at Linear synthesize signal from multiple sources: their own daily product usage, customer support conversations, community feedback, and competitive analysis. They do not take feature requests at face value. Instead, they look for recurring pain points and evaluate whether addressing them fits the product's focused vision. Most requests get declined. The ones that make it through must serve a broad user base and align with Linear's opinionated approach to project management.

What makes Linear's shipping culture different from other startups?

Three things stand out. First, the quality bar is unusually high. PMs do not ship rough v1s and iterate. They ship polished experiences. Second, the team is async-first. Most decisions happen in written docs, not meetings. Third, the team is small by design. Linear has roughly 80 employees serving thousands of teams. That ratio forces focus. You cannot build everything, so you must choose carefully.

Can other teams adopt Linear's approach?

Parts of it, yes. Dropping estimation and breaking work smaller is immediately actionable for any team. Moving to async-first communication requires cultural buy-in but pays off quickly in reduced meeting load. The hardest piece to replicate is the quality bar. It requires hiring people who care about craft and creating an environment where "good enough" is not acceptable. Teams that try to adopt Linear's workflow without adopting the quality mindset will get the process but miss the point.

How a PM Ships at Linear

TL;DR: Inside Linear's opinionated shipping culture. How their PMs run cycles instead of sprints, skip estimation, use their own product for project management, and ship weekly without standups.

Linear has become the default project tracker for fast-moving product teams. But the tool itself is only half the story. The way Linear's own PMs work reveals a shipping philosophy that rejects most of what traditional product orgs take for granted: no story points, no standups, no lengthy estimation rituals. Just small teams, tight cycles, and a relentless focus on quality.

This is how PMs actually ship at Linear.

The Company

Linear launched in 2019, founded by Karri Saarinen (previously at Airbnb and Coinbase) and Tuomas Artman. By 2025, the team had grown to roughly 80 people. Thousands of product teams now use the tool daily, from early-stage startups to companies like Vercel, Ramp, and Loom.

What sets Linear apart is conviction. The company is famously opinionated about how software should be built. That opinion extends inward. Linear's own product team follows the same principles they bake into the product. If you want to understand Linear as a PM tool, understanding how its own PMs operate is the fastest way to get there.

The Workflow

Cycles, not sprints. Linear organizes work into two-week cycles, but they are not Scrum sprints. There is no sprint planning ceremony with pointed stories. There is no velocity chart. A cycle is simply a container: a list of issues the team commits to completing. If you are used to traditional sprint planning, this feels liberating and a little disorienting. There is no scorecard at the end. The question is binary: did the work ship, or didn't it?

No estimation. Linear's team does not estimate tickets. No story points, no t-shirt sizing, no planning poker. Instead, they break work into pieces small enough that estimation becomes unnecessary. If an issue feels "large," it gets decomposed until each piece can be completed in a day or two. The logic is straightforward: estimation is expensive, often wrong, and optimizes for prediction rather than execution. Breaking work smaller optimizes for actually finishing things.

Dogfooding as compass. Every PM at Linear uses the product all day, every day. This creates a feedback loop that no amount of user research can replicate. When something feels slow, they feel it. When a workflow is awkward, they notice before anyone files a ticket. Product intuition at Linear is not abstract. It is grounded in hundreds of hours of personal usage per quarter.

Weekly shipping. The team deploys multiple times per day. Features ship when they are ready, not at cycle boundaries. Cycles provide planning structure, but they do not gate releases. This is closer to continuous delivery than to any sprint-based model. For teams exploring similar approaches, a kanban-style roadmap is the closest template equivalent to how Linear operates.

Async-first. Written proposals and Linear project docs replace most meetings. Status is visible in the tool itself. There is no daily standup. No weekly status email. If you want to know where a project stands, you open Linear and look. PMs spend their time writing specs and making decisions, not reporting progress. This aligns with what many remote-first teams are discovering about effective async workflows.

The Decisions

Saying no is the default. Linear is famous for maintaining a focused product. The team receives constant feature requests, and the answer to most of them is no. PMs must have strong conviction to add anything. Every new feature increases surface area, and surface area creates maintenance burden, feature creep, and complexity. The bar for inclusion is high: a feature must serve a broad set of users and fit the product's opinionated vision. The art of saying no is not a soft skill at Linear. It is the primary mechanism for keeping the product coherent.

Quality is non-negotiable. Ship it right or do not ship it. Linear's brand is tied to speed and polish. PMs spend significant time on details that other companies would call "nice-to-have." Transitions, keyboard shortcuts, pixel-level alignment. These are not afterthoughts. They are core to the product thesis: that developer tools should feel as good as consumer apps. A PM who ships something unpolished has not shipped.

Customer feedback is synthesized, not executed. Linear gathers signal through their own support channels and a public community. But they do not build features on request. PMs look for patterns across hundreds of conversations and distill them into product decisions. A single user asking for a feature is noise. Fifty users describing the same underlying pain point is signal.

The Craft

Writing culture. Major features start with a written spec or proposal. The document describes the problem, the proposed solution, open questions, and trade-offs. The team reads and discusses async before anyone writes code. This slows down the start of a project by a day or two. It speeds up everything that follows. Writing forces clarity. Meetings let ambiguity survive.

Design partnership. PMs and designers at Linear work as a tight pair. Design is not a service org that PMs hand specs to. It is a full partner in shaping what gets built. Linear invests heavily in design quality, and the PM/designer relationship reflects that investment. PMs are expected to have strong taste and to push back on designs that don't meet the bar, just as designers push back on specs that are unclear.

Key metric: daily active depth. The metric Linear cares about most is not signups or revenue growth. It is whether teams are using Linear as their primary work tool, every day. Active daily usage and engagement depth tell the team whether the product is actually useful or just installed. Retention follows utility. For context on choosing metrics that matter, see our breakdown of the only metrics that matter for B2B SaaS.

Tool Stack

Linear's PM team runs lean on tooling:

Linear for all project management, issue tracking, and cycle planning
GitHub for code review and version control
Figma for design work and prototyping
Slack for real-time communication (used sparingly)
Notion for longer-form documentation and knowledge management

The tool stack is deliberately minimal. Adding a new tool requires justification. Most coordination happens inside Linear itself.

Key Takeaways

Small, focused teams ship faster than large ones. Linear keeps teams small (2-4 people per project). Fewer people means fewer coordination costs and faster decisions.
Skip estimation. Break work smaller instead. If a task needs estimating, it probably needs decomposing. Small tasks are self-estimating.
Dogfooding creates genuine product intuition. Using your own product daily gives PMs signal that no survey or interview can match.
Written proposals beat meetings for decision quality. Writing forces precision. Meetings tolerate vagueness. When the stakes are high, write it down first.
Quality is a feature, not a nice-to-have. For Linear, polish is product strategy. It is the reason teams choose Linear over alternatives with longer feature lists.

For a deeper look at how Linear's approach compares to other modern PM tools, see our case study on Linear's impact on PM tooling and our detailed Linear for product teams guide.