The Linear method: Opinionated software


The Linear team runs on strong opinions that might seem counterintuitive to outsiders. Here’s how those principles show up in both the product and their processes.
Share The Linear method: Opinionated software


Illustrations by Jon Han
Well-designed interfaces don’t just happen. Great product experiences are the result of great people, tools, and of course, processes. These processes are hard to get right. While some rallying cries reach the notoriety of Meta’s “Move fast and break things,” others run the risk of simply being the work about the work. But there’s a reason why product development frameworks are so prevalent: How we build is just as important as what we build.
At Figma, we’re always hearing from teams about new ways to build for more streamlined workflows, faster iterations, and ultimately better products. It’s in this spirit that we’re inviting product leaders from a range of teams to unpack the specific terms, principles, and strongly held beliefs that govern their work. While every team is different, hopefully there’s something here for you to adapt, remix, or even push against for your own workflows. For the first installment in our series, we sat down with the Linear team who put forth a series of principles to guide their own work. Here, co-founder Jori Lallo and Chief Operating Officer Cristina Cordova share why opinionated software is core to Linear’s methodology, and how other teams can adopt it.
What is opinionated software?
Linear’s founding team—including Jori, Karri Saarinen, and Tuomas Artman—had previous work experience spanning high-growth companies like Airbnb and Coinbase. Frustrated with legacy tools that siloed workflows, they set out to create a collaborative issue tracking and project management experience that more closely mirrored how startups work. “We’ve always been interested in how tools can enable us to do our jobs better,” says Jori.
At its core, opinionated software is software that’s purpose-built for specific use cases. At Linear, that use case is helping teams build better products. Unlike a general purpose tool to be adopted across many disciplines or workflows, it guides you toward a default process. “We design it so that there’s one really good way of doing things,” says Jori. “Flexible software lets everyone invent their own workflows, which eventually creates chaos as teams scale.”
What does it look like in practice?
Forming atom-level opinions
At past companies, the team saw how steep learning curves and jargon kept people from adopting certain productivity apps. Rather than coming up with new terms, the Linear team landed on straightforward units of work—like projects and teams—that are universal and easy to understand. One of the team’s firm opinions is that you shouldn’t need a handbook to start using Linear; the aim is for users to spend less time ramping up and more time building. This is why there may not be one right way to do something in Linear, but there is a default way to do something. “No one wants to waste time nitpicking the nuances of a process,” says Jori. “We try to reduce the amount of fiddling around with processes and get you into building things.”
No one wants to waste time nitpicking the nuances of a process. We try to reduce the amount of fiddling around with processes and get you into building things.
But what happens when the default approach conflicts with customer feedback? The Linear team believes there’s an art and a science to it. The team is generally more opinionated at the atomic level—deciding to add labels and due dates as issue properties, for example. As they move up the stack to broader concepts like projects, they take more cues from customer feedback, knowing that every company is structured differently.

Being strategic about product debt
“When people talk about ‘product debt,’ they often mistake it as ‘tech debt,’ which is actually just bad code,” says Jori. The Linear team thinks about it as something they can borrow against, strategically choosing to narrow a feature’s scope, “save” on quality, or optimize for the short-term, knowing they’ll have to pay down “interest”—in the way of customer feedback or resourcing—down the line.
Settings are one product experience where the team has intentionally taken on debt because “display options” or “favorites” don’t generally make or break the user experience. Over the last five years, the Linear team has only ever added functionality to settings—whether that’s features, preferences, or sections—without taking a step back to rethink the experience holistically. “The interest rate on it has been pretty low, and we can pay it back over a longer period of time,” says Jori. Until they have the time to tackle a settings redesign, the team recognizes that it’s not the perfect experience. “Shortcuts might be perceived as lower quality, but our version of that is more about decreasing scope,” says Cristina.
Shortcuts might be perceived as lower quality, but our version of that is more about decreasing scope.

Evolving strong opinions, strongly held
“We’re a startup, so we don’t build software by a recipe,” says Jori. Many teams are hesitant to think beyond a framework and change the user experience out of fear that they’ll get pushback from users. Of course, certain changes that meaningfully impact users’ workflows can be disruptive, but the Linear team advocates for experimentation and iteration. “I would hate Linear to be in a position where we can never take something away or change certain things,” says Jori. “It’s natural that there’s going to be a little bit of pushback.” Rather than shying away from making changes, the Linear team aims to give users information and tools to understand the change. And whether it’s an experience in the product or how they communicate on their marketing site, their north star is shipping things that they can be proud of—even if they have to make trade-offs along the way.

How to develop your own POV
While it’s helpful to use past experience or a popular framework as a jumping off point, every team and company is different. “Many people try to adapt things from the industry that might not actually be applicable to them, or they might not know the potential downside,” says Jori, citing common tools like OKRs. “They were developed at places that are bigger and growing faster than most companies, so you need to try to understand what's behind them and adapt pieces of them.” More than anything, the reality of high-growth companies is that doing and experimenting is often more instructive than thinking.
Read more about opinionated software and Linear's methodology here. Stay tuned for the next installment in our series about how teams build products and the principles and processes that guide their work.

Alia Fite is a writer and editor on Figma's Content & Editorial team. She has previous experience at Stripe and Dropbox.




