How Linear builds product

? Hey, I’m Lenny and welcome to a ? subscriber-only edition ? of my weekly newsletter. Each week I tackle reader questions about building product, driving growth, and accelerating your career.

Linear is a story I’ve been wanting to tell for a long time. Not only are they the #1 most requested startup for me to include in this series, they’re also building the product that a growing number of teams are using to build their own product. And they are doing so in incredibly unique ways:

1. No product managers, just a head of product. PM duties are distributed across engineering and design.

2. No durable cross-functional teams. Teams assemble around a project and disperse once the project is done.

3. No metrics-based goals. Just a North Star company-level metric goal.

4. No A/B tests. Decisions are based on taste and opinions.

5. Job candidates go through a paid work trial. They join the team for 1-5 days and work on a real project with the team.

6. The team is completely remote. And always has been.

Linear also has more cash in the bank than they’ve ever raised in VC funding, they’ve been profitable for 2+ years (before it was cool), and have spent a grand total of $35K on paid marketing in the history of the company. Only two people have ever left the company, and their CEO, Karri Saarinen, is a designer (who rarely gives interviews). For all of these reasons, I’m thrilled to share an in-depth look at how Linear builds product. If you’d like to learn more, check out Linear.app, find Karri on X, and they’re hiring!

Karri Saarinen, co-founder and CEO

In the very beginning, when it was just us three founders, we planned by the week. We would think about the most important things to resolve and then go work on that. If you go back to the beginning of our changelog, you can see what shipped each week. Our goal was usually to figure out what was blocking us the most from getting more users on the product, and fixing things we heard from our beta users.

Today, we have about 50 people at Linear. We only have a single product team, which means that we can keep the planning process quite centralized, and there is only one roadmap for the whole product. This makes it very clear to everyone what we are working on. Additionally, everyone feels responsible for the whole product and how it all works together.

For the planning process itself, it’s a two-way approach, where we start with the founders and small leadership group to plan the direction we want to go as a company for the following 12 months. In parallel, we ask everyone on the team to share their thoughts and ideas in FigJam sessions (here’s a link to our template) or surveys to get more thoughts on areas we could improve or tackle.

FigJam session template for annual planning

Once we have the strategy in mind, we then define a high-level roadmap for the next half of the year based on that. The strategy, for example, might be “focusing on large company needs.” We don’t have complicated ways to rank or vote on projects. Instead, we believe that if the leadership team and the whole company spend time with customers and use the product regularly, the needs and opportunities become more apparent. Then it’s just a matter of sequencing and scoping.

We’ve included a high-level product roadmap for Q2 and Q3 of this year below. We had two strategic workstreams: planning and roadmapping, and issue discovery. Our other two workstreams are dedicated to high-priority user asks, so we can respond quickly to needs we hear from customers, and keep-the-lights-on projects (in the “other” workstream below). We’ll include new features and functionality alongside improvements to existing features within these workstreams. We try to plan out in detail for two quarters, then sketch out the next half, and leave a pretty extensive backlog to pull from. The roadmap (more on that below) for a given workstream will get more detailed as we break this work into projects.

High-level product roadmap

We sequence the projects based on what we think is the optimal path to tackle them. “Optimal path” means we see a reason to do X before Y, because they would support each other, or we have specific people from the team in mind who should tackle some specific project but cannot do them in parallel. We like to pair projects with individual strengths when possible. For example, when we know the project feature will need a more advanced front end, we staff with our strongest front-end people.  

Project plans start as documents or lists where we just draft ideas. We then ask the project team to write the spec for the project. Here’s an example spec for our Triage feature:

After the spec is written, we’ll add the project to the Roadmap in Linear. This is our internal working view of the “Planning & Roadmapping” workstream and how the team manages their workflow as they build.

Roadmap for “Planning & Roadmapping” features

One. We hired Nan Yu a little over a year ago when we were about 25 people. He is Head of Product and currently the only one carrying a “PM” title. The reason I phrase it this way is that we have other roles that also contribute to what is traditionally considered part of the PM role.

Our plan is not to hire PMs for every project or team. We hired Nan because we saw the need for someone to shepherd the product overall and the activities around building products. Instead of having a PM for every team or area of the product, we like to see that the broader team collectively thinks about the product and how features are delivered, not just the PMs.

We haven’t used OKRs. For goals, we like to keep it simple and sometimes have more strategic goals, like “Be the default tool for startups” or “Get xxx number of companies,” which we then use as the theme for figuring out the roadmap. I find these types of goals useful to align our team to what we are after without being too specific about how we get there. It’s also much more empowering for them.

Our very secret strategy slide

We also don’t have metrics goals for the product or any projects, but we do have a North Star company-level metric goal. For a B2B tool like ours that takes some time for a company to adopt the tool or any new feature, setting specific metrics goals and measuring progress doesn’t seem that useful and more often can lead you astray. To me, product goals should be about how we add value for our existing customers or expand to a new customer base; in other words, how we solve our customers’ problems better.

With certain projects, we might pull up specific data or metrics to see if the data gives us any more insights, but it’s not the way we make decisions. We don’t do A/B tests. We validate ideas and assumptions that are driven by taste and opinions, rather than the other way around where tests drive decisions. There is no specific engagement or other number we look at. We beta test, see the feedback, iterate, and eventually we have the conviction that the change or feature is as good as it can be at this point and we should release it to see how it works at scale.

We only have mobile and infrastructure as specialized teams, as they require specialized skills and focus. The rest of the product team works on the projects that come out of the planning process, which could address any area of the product. We have purposely avoided product-area-specific teams (e.g. the roadmaps product team, the cycles product team, etc.), as I see it can be a way for people to get too trapped in their specific product area and potentially lose the broader context and/or start working on more minor details with diminishing returns. Naturally, some people become more knowledgeable about some parts or types of problems, and the same people might address the same area again, but it’s not a formal position.

Our product team is divided by region (U.S. and Europe). We realized early on that it’s challenging to work over many different time zones with a distributed team, so we now have Europe- and U.S.-based people run as their own distinct groups. In addition, we have people in marketing, data, sales, customer success, support, and talent/people who work closely with our product teams. 

When we do our roadmap planning, we divide the work between the U.S.- and Europe-based teams. Then within those teams, the projects get staffed with a project lead and the rest of the team. The project lead can be an engineer or designer or whoever else is part of the project. Since we don’t have any PMs other than our Head of Product, the project lead is never a PM. The role of the lead is to get the project started and communicate how it’s going. Typically, for almost any feature we build, we have small teams of one designer and two engineers. At our current size, we have about six project teams running in parallel. Once the team finishes their project, they disperse and move to another project.

When it comes to planning, we might set up themes around a certain type of customer, area, or type of features that we would like to develop, but we just don’t set the org chart based on that.

We aim to give individual project teams ownership of projects, because we believe that when a team has ownership over their work, they can create far better solutions for our users.

I, along with my co-founders Jori Lallo and Tuomas Artman and our Head of Product, each lead or sit in each project meeting acting as a sponsor to give feedback and direction as needed. One of us is ultimately responsible for the outcome. For example, we have a project team focused on new-user onboarding experience, and Jori will lead that project and the project team meetings, while also providing feedback on updates shared asynchronously from the project team in Slack.

We don’t have formal product or design reviews. It’s more ad hoc and iterative, which enables us to move faster. For example, our designers share an early design in a project-related Slack group and get informal asynchronous feedback from many different people that way. 

We’ve had a robust feature-flag system from the beginning, so we push new features to internal testing as fast as possible, sometimes in days or weeks from starting the project. At that point, everyone can try out the feature and see if something feels wrong or if they have ideas for how things could be improved. Because of these feature flags, there is no excuse to wait to ship.

We run a beta customer testing program called Linear Origins where our customers get earlier access to new features and we can get product feedback early. Sometimes this happens a month or two before we aim to launch a feature, and sometimes it happens days before. For example, we’re working on a more significant new feature release and we’re setting up calls with some of our customers to walk them through the product. If they’re interested in trying it out, we’ll enable the new feature, ask them for their feedback, and do our best to address it. While we do this with some products, we don’t view pushing features to beta as a required step to launching. We still value shipping quickly, which means not everything needs to go through the beta program, but we use it when we find it useful to get more feedback.

Yes, product, engineering, and design are all part of the product team. Product and design report to me (CEO). We have engineering managers, but engineering ultimately reports up to my co-founders: Tuomas for infrastructure and Europe engineering, and Jori for U.S. engineering. While engineering and design have their own meetings for their functions, for the most part, we talk about “Product” holistically and not engineering, design, and product separately. The org has stayed the same from the beginning. 

Well, Linear, of course. We recently shared a blog post about how we use Linear to manage incoming bug reports and feature requests directly from customers.  

As a quick overview, for bug tracking we heavily use our Triage feature, which is like an inbox for your team. Our support team, sales team, and even I often file issues into Triage, and one of our “goalie” engineers routes the request to the appropriate person or fixes it at the time. “Goalie” is a weekly rotation where an engineer helps the support team with issues, fixes bugs, and triages incoming requests.

Most of the other tasks are part of projects. The engineers and designers are creating the tasks for themselves and resolving them as they go about the project. Project teams do weekly updates on the project progress using our Project Updates features. These updates also get posted to Slack to our #product-updates channel so anyone can follow them.

One of the unique aspects to Linear is that we expect the project team to be the PM.