(2023-09-26) Rachitsky How Linear Builds Product

Lenny Rachitsky: How Linear builds product. Linear.app is a story I’ve been wanting to tell for a long time.

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:

• No product managers, just a head of product. PM duties are distributed across engineering and design.
• No durable cross-functional teams. Teams assemble around a project and disperse once the project is done.
• No metrics-based goals. Just a North Star company-level metric goal.
• No A/B tests. Decisions are based on taste and opinions.
• 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.
• 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).

1. How far out do you plan in detail, and how has that evolved over the years?

In the very beginning, when it was just us three founders, we planned by the week.
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.

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’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

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.

2. How many PMs do you have?

One. We hired Nan Yu a little over a year ago when we were about 25 people

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.

3. Do you use OKRs in some form?

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.

We also don’t have metrics goals for the product or any projects, but we do have a North Star company-level metric goal.

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. (customer-driven)

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

4. Do you structure your teams around products, user types, user journeys, outcomes, or something in between? Has this changed over the years?

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.

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.

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.

5. How do your product/design review meetings work?

We’ve had a robust feature-flag system from the beginning, so we push new features to internal testing as fast as possible

6. Are product and design part of the same org? And who do PMs ultimately report to? Has this changed over the years?

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

7. What’s your primary tool for task management, and bug tracking?

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.

8. You built one of the most beloved and successful products out there today. What would you say is unique or central to your approach to product that leads to such a successful product?

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