How Linear builds product

It’s simple: spend time with customers and use the product.

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.

Just say “No!” to A/B tests.

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.

Linear, praised for its “design”, and they don’t even have formal design reviews!

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.

Simple. Lean. Just take all the cruft, process, etc., away. You can always add it back — in fact, if you’re not adding it back, you didn’t take enough away.

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

This idea of thinking about product “holistically” is spot-on IMO.

There’s more, but the article is paywalled.

However, this nugget (from a screenshot) is the industry hot take I want.

Anyone who has built things knows that a lot of ideas and opportunities emerge when you actually start building something. A good example of this is when an engineer on our team, Andreas, built the context menus. We didn't ask or spec it for him to figure out how we can make sure the context menu doesn't close if the user hovers their mouse a few pixels off. He just felt it was needed. These kinds of details are almost impossible to spec or plan for if you're not there building it or if the people building it don't have ownership.

My take is that this is one of the reasons why so much of the software we have today seems fine on paper but doesn't actually work well in practice. We as an industry optimized the process too much and created a Henry Ford-style feature factory where each role is very specific and production speed is more important than craft. (The other reason is A/B testing.)

It's worth noting that there are downsides to this approach. It means that engineers and designers do have to play the role of the PM, which includes communicating, talking to users and stakeholders. This means that engineers and designers are not purely coding or designing, which can sometimes feel like it slows things down. Personally, I believe often it's better to go slow to go fast, meaning we generally get projects done right the first time, with minimal fixes later. The second downside is that it's harder to hire for these roles, as many people don't have experience working this way.