The Linear method is our approach to product building that we follow on our own team. It's helpful to know since it influences how we design the app and explains why the features work the way we do. We recommend checking out our in-depth articles on the Linear Method but here's a quick summary and visual guide to help you with understanding the app.
We tie our daily work to larger goals with the roadmap.
We work off of a common roadmap so we're aligned on the company vision and priorities. Everyone has access to it. We break this roadmap down into quarterly milestones which usually have a focus or theme tied to these larger company goals, such as improve the core user experience or scale up.
We prioritize project work and work in cycles.
Focusing on project-related tasks creates a natural bias for us to spend our time on features that improve the product or level up the user experience in meaningful ways. Without the focus it could be easy to work on issues that didn't move us toward our goals.
While projects reflect our focus and priorities for the quarter and product generally, we use cycles to figure out what specific issues to work on during the week or weeks.
Cycles are similar to sprints but they don't end in a release or have a specific goal. They're a container that helps us choose and prioritize the issues we work on in a given period of time.
On our team, we work in 1 or 2-week cycles. Most work in a cycle will be tied to projects but we do mix in bugs, quality improvements and user requests which are filed to a backlog, which usually amount to about 10-20% issues done.
Cycles don't have deliverables or end in a release. You simply do the work you can and any work not completed gets rolled over to the next one.
We don't overload cycles and we design them to be flexible.
We leave it up to individual team members to manage their time decide what issues to prioritize within the cycle. We've also set up automations in team settings to minimize actually having to update issues or do much cycle planning.
We don't expect to complete cycles 100% or plan perfectly. We expect new bugs to come up as well as unexpected or opportunistic work, too, which means issues will get moved around and the scope line will creep up. That's a tradeoff we're okay with. We're aggressive about reporting bugs or issues and try to fix bugs immediately, since it reduces technical debt, keeps product quality high, and reduces time spent answering customer support questions.
We release work continuously and summarize it weekly in a changelog.
The public changelog keeps us accountable to shipping a core feature or improvement each week without creating unrealistic or unhelpful pressure to push out features before they're ready. It's also a great way to celebrate work and share it with our community. This creates healthy balance and accountability since we don't usually set project deadlines and cycles aren't tied to releases. We share more about writing changelogs here.
We write short, to the point issues.
The only requirement is to add a title, team, and status like backlog or todo. It takes a few seconds. We don't think creating issues should be a chore or take you away from your work. We don't write user stories.
When writing issues we break them down as small as possible and assign them to a single owner. We think that's really important. If multiple people are involved, we'll break down the tasks into sub-issues and then assign those. For the most part, everyone on the team writes their own issues or if they're assigned an issue, gets to decide how to execute it.
Those are the most important things to know about the Linear method and how we work. Dive deeper into the Linear method on our website.