How did Linear actually get this big?

Hello again my friend,

At my day job, our team builds the product at beehiiv (the software). Part of that job is paying attention to how other products solve problems we might eventually face.

Sometimes the inspiration is small: how ChatGPT frames an upgrade, how Spotify Wrapped gives users something they want to share, or how Uber retries failed payments around payday. These are individual decisions you can study, adapt, and bring into your own product.

Every so often, though, I find software that feels so simple, fast, and unusually considered that it seems as if it was made specifically for people like me.

Linear is one of those products.

A few months ago, I built an AI agent to handle part of our bug-triage process. When a customer reported something broken, I used to investigate the issue manually, confirm it inside their account, create a Linear ticket, write the specifications, and eventually hand it to an engineer.

The agent now handles that first pass. It investigates the report, drafts the ticket and customer communication, and can even propose a small code fix when the problem is straightforward. A human still approves the code and messages before anything goes out, but a workflow that once required several manual steps now happens largely on its own.

I enjoyed feeling ahead of the curve for about a month.

Then Linear built nearly the same workflow directly into its product.

That is part of why I wanted to study the company more closely. In the corner of technology I work in, Linear has become the project-management tool teams ask to use. Not one of the tools in the category of “sucks, but our boss make us use it.”

That distinction matters because project management is not a new or empty category. Jira, Asana, and other incumbents had decades of development, enormous enterprise contracts, and billions of dollars behind them. Linear entered that market in 2019 with three founders and what was, at its core, a more considered place for software teams to manage their work.

By 2025, the company was valued at $1.25 billion. How?

The tempting explanation is that Linear simply built a beautiful product and engineers told one another about it. But plenty of beautiful products fail, and plenty of deeply unpleasant products become billion-dollar businesses (Salesforce, Quickbooks, etc). Product quality matters, but it does not explain the entire outcome.

Many of you are considering what AI might make possible for a venture of your own. That is the purpose of these Product Building editions: to look beneath the visible product and understand the decisions, advantages, and systems that allowed a company to break through.

Linear did not win because of one interface, feature, or perfect launch. Its founders combined experience, speed, product judgment, influential early users, and a distribution system that was easy to mistake for word of mouth.

That is what I wanted to understand.

Let’s lock in.

Before getting into the early product, it helps to understand how big Linear has actually become.

In June 2025, the company announced an $82 million Series C at a $1.25 billion valuation. Across its seed, Series A, B, and C rounds, Linear has raised ~$134M.

It’s a lot, but their path is the bigger deal. Reuters reported that Linear had ~80 employees when the Series C was announced, and that its profits were up 280% during the previous year. Linear described itself as high-growth, profitable, remote, and still operating with the deliberate constraints that shaped the company in the beginning.

Its current customer page says the product now powers more than 37,000 organizations, from ambitious startups to Fortune 20 companies. OpenAI (the people who made ChatGPT) scaled Linear to 3,000 internal users. Ramp, Vercel, Coinbase, Cash App, Scale AI, Brex, Cursor, Perplexity, Cohere, Runway, ElevenLabs, and dozens of other companies use it.

At this point, Linear is not only taking customers from small startup tools. It is moving thousand-person organizations away from some of the most established project-management systems in the world.

That is a wild outcome for a company whose original product was essentially a better place for software teams to file issues and plan their work. Jira was already enormous. Atlassian had been selling project-management software since 2002, had millions of users, and offered almost every workflow or configuration an enterprise could ask for.

Linear did not win by finding an empty market. It entered one of the oldest and most established categories in business software, then convinced many of the best product teams in technology that the existing standard was no longer good enough.

In Linear’s original April 2019 announcement, Karri Saarinen described how the founding team had designed, delivered, and scaled software at Uber, Airbnb, and Coinbase. This is a very important point I’ll come back to later.

They watched product teams grow from a handful of people to thousands. They had dealt with enormous bug backlogs, roadmaps that went stale before they were done, and tools that were disconnected from how modern software companies worked.

That experience gave them a specific point of view. Linear would focus on speed and efficiency because people used these tools several times every day. It would automate manual work instead of adding more process for teams to manage. It would connect planning more directly to execution so roadmaps, projects, and the work being shipped did not become separate (stale) realities.

There is a strong parallel to what I described in Taking on billion-dollar companies in year one.

beehiiv’s founders had already built and scaled Morning Brew to millions of readers and a major acquisition. They understood newsletter businesses because they had operated one at a level most customers could only hope to reach. They knew which workflows sounded important but could wait, which boring problems quietly blocked growth, and which features a serious newsletter company would eventually need.

Linear’s founders had the same kind of advantage in a different market. They were not studying software development from customer-interview transcripts and trying to imagine what a high-performing team might need. They had worked inside the exact kinds of companies they wanted to serve and had felt the problems themselves.

beehiiv and Linear had two similar experience.

Every newsletter wanted to be like Morning Brew. The guys who built Morning Brew created beehiiv to give those newsletters the same tools.

Every tech company wanted to build like Uber, Airbnb, and Coinbase. The guys who built product at there created Linear to give other companies the same tools.

That is what people are often trying to describe when they talk about founder-market fit or product intuition. It is not magic. It is pattern recognition earned from living inside a problem for long enough that certain decisions become obvious before the data exists.

Of course, experience can also trap someone in the past. The fact that you solved a problem at one company does not guarantee that everyone else experiences it the same way. Linear still needed users, feedback, and a product good enough to prove the founders were seeing something real.

The difference was that they knew where to start.

Linear did not launch in April 2019 with a complete replacement for Jira, or Asana, or whatever else.

There was no public product at all. The company published its point of view, opened a private alpha, and invited teams to help shape what came next.

The earliest releases show how narrow the team was willing to be. On July 19, Linear made Cycles available to every beta team. Ten days later, it released the first version of Projects.

Neither feature was remotely complete by the standards of a mature project-management platform. Projects could have a target date, a description, a link to a product specification, and issues split across Cycles. The changelog openly called it the first release and said the team planned to keep expanding it.

That was the point.

Karri later explained the operating system behind these decisions in Building at the early stage. During Linear’s first months, the team used monthly roadmaps and selected only one to three larger projects that seemed most likely to advance its goals.

They intentionally left part of the month unplanned so they could respond to bugs and important feedback without abandoning the larger work.

Projects were scoped to take one to three weeks with one to three people. Smaller additions were expected to take hours or a day. The team designed the first versions of Cycles and Projects in roughly two weeks but put them in front of private-beta users during the first week, then spent the following weeks learning and fixing what did not work.

This was in 2019/2020, before AI. Unsurprisingly, it’s the same techniques top AI companies use to grow so incredibly well.

The Linear team ran one-week development cycles. For comparison, at the time, most companies were taking 4-6 weeks per cycle.

There was also a much smaller decision that says a lot about how they worked. Linear initially supported only Google login. The founders knew they would eventually need email authentication and other methods, but building all of them would have delayed the parts of the product they actually needed to test.

This is where “choosing less” becomes more useful than a nice quote about product taste. You literally could not enter an email to sign up. You had to do it through Google. They knew the people who’d give them a shot in the first place wouldn’t care much and would login with Google.

Linear’s output looked more refined than ours often did, but the underlying decision was similar: identify the thing that advances the product, narrow the scope until it can ship in days/weeks, and let real use make the next decision clearer.

Linear did stay in private beta for a long time, but it kept launching throughout that period.

The company’s own “Launch and keep launching” method says there is a false belief that a startup needs one singular launch. Linear announced the company before the product existed. It launched again when it raised its seed round. It launched when it opened access and added pricing. It launched again when it raised its Series A and expanded the product.

Just like how companies selling shoes, hats, or jewelry would have drops. Linear treated every release like a drop with its own hype phase.

Each moment gave more people a reason to pay attention and produced more customers than the launch (drop) before it. Linear’s argument is that if it had waited eighteen months for one perfect public reveal, it would have had fewer customers, less feedback, and considerably less momentum. I’d agree.

The weekly changelog served a similar purpose. It was not just documentation for existing users. Every update demonstrated that the team was alive, listening, and moving. The product kept reappearing in front of the same community with a better reason to try it.

Product Hunt currently lists 11 separate Linear launches, a 4.9 rating, hundreds of reviews, and more than 3,000 followers. The company also used Twitter, Hacker News, its customer community, founder writing, funding announcements, and public product releases to keep compounding attention.

This was not traditional paid acquisition. Linear says it did not use SEO, growth hacks, or A/B testing to find its way forward. But “we did not use growth hacks” is very different from “we did not distribute the product.”

Linear distributed the progress.

By the time Linear announced its $4.2 million seed round in November 2019, the company said thousands of small and large companies had joined the waitlist and hundreds were already using the product every day.

The named customers included Pitch, Render, Albert, Curology, Spoke, Compound, Middesk, Catch, and Visly. You’re not the only one that’s never heard of them. I hadn’t either. But they were exactly the kinds of forward-looking startups Linear needed: small enough to adopt something new, technical enough to care about the difference, and connected to the startup world where good tools spread quickly.

The founders also had an unusually influential investor group. The seed round included Figma founder Dylan Field, Coinbase COO Emilie Choi, Y Combinator partner Gustaf Alströmer, Expo and Quora co-founder Charlie Cheever, and several other founders and operators across software. That’s the part that’s harder for you and me to emulate, but a good thing to be aware of.

None of this proves those investors were actively promoting Linear, and we should not pretend it does. It does show that Linear was not a random side project trying to get noticed by posting into the void. The company began inside a concentrated network of people who built software, invested in software, moved between promising startups, and paid close attention to the tools their peers preferred.

The founders’ experience at Airbnb, Uber, and Coinbase created credibility. The early customers created evidence. Sequoia and the operator-investors created another layer of legitimacy. The launches and changelogs repeatedly put that evidence back into the market.

Then the product took over inside the teams.

One engineer or product manager would introduce Linear. The rest of the team would experience how much faster it felt than the process they were used to. More of the company would adopt it. When those people joined another startup or started a company themselves, they brought their preferred way of working with them.

By June 2021, one year after its public launch, Linear said it had grown its customer Slack community to more than 2,000 people, its Twitter audience to 14,000, and its internal team to only eleven employees. The company was speaking with hundreds of customers each week through Slack, Twitter, bug reports, feature requests, and its in-app help system.

That closeness became part of the product. Linear noticed customers creating separate triage teams and attaching support conversations to issues, so it built a dedicated Triage inbox and integrations with tools like Zendesk, Intercom, and Front. It did not simply collect feedback, turn it into a feature request, and add another setting. It looked for the repeated workflow underneath the requests and built its opinion about how that workflow should operate.

This is how the product kept improving without becoming an enormous collection of unrelated customer demands.

Jira is powerful because it can support an incredible number of teams, processes, fields, workflows, permissions, and company structures. That flexibility helped it become the default for enormous organizations. It can do anything so companies like buying it. But every employee hates using it (more or less). Jira is in the category of “sucks, but our manager makes us,” like Salesforce, Quickbooks, etc.

You can rest assured that if I can see that, so could Linear’s more immediate competitors. They were not the only ones to think of “Jira, but simpler and better.”

The problem is that simplicity becomes harder to defend as the company grows, gets larger customers, and those customers want their existing processes recreated.

Sales opportunities arrive with feature lists. Every missing field becomes a reason someone cannot switch.Eventually, many challengers recreate the complexity they originally opposed.

Linear made a different bet. It treated speed, keyboard navigation, defaults, and product structure as more than interface details. They were the product’s opinion about how a software team should work.

I’ll give you my favourite thing from their team.

In an interview last year, Nan Yu, Linear’s head of product, mentioned something that immediately hit for me in this interview. It was very much related to how they chose to handle these massive conglomerates who showed up with these huge lists of requests and docs saying “this is how we do it, so if you want our business, you have to build it for us to do it our way.”

In different words, he basically clarified where most companies go wrong there. It’s not the request itself, or the company, or the money. Those things are usually fine. It’s the person they’re dealing with on the other end.

Nan’s comment was (in different words) that Linear is wary when dealing with middle management that can spend money, but cannot change anything in their own business.

Middle managers or Directors can get a budget, start the process of buying new software, and make the purchase in 3-6 months. But, it would take over a year to change how 5-10 employees in their own company operate, and they can’t even do it themselves, they have to convince 2-3 layers of VPs and C-suite execs (yes, it’s kind of absurd) So they put the pressure on companies like Linear to build software to fit their needs. Linear said no. They kept doing it their way.

In a 2021 customer story, Descript founder Andrew Mason described how his team had been fighting its previous issue tracker and doing too much “work about work.” Linear treated priorities, status, sprints, and estimates as first-class parts of the system instead of asking every team to assemble them independently.

An engineering leader at Loom emphasized something simpler: speed. People could enter Linear, find what they needed, update the work, and leave. The tool did not become another place where work went to sit.

That sounds small until you consider how often someone opens an issue tracker every day. A delay of a few seconds, an unclear field, or one unnecessary step is not experienced once. It is repeated by every person, across every issue, for years.

A thousand employees having to take a few extra minutes on every single task adds up to a lot of time, and money.

People often describe Linear as having good taste, which can become a slightly annoying way of saying the interface looks nice.

That is not what built the company.

‘Taste’ in the context of minimal, easy to use, fast software is the repeated ability to make small decisions that remove friction and create delight for a specific user, while cutting the things that do not serve the core job. It is knowing which customer request reveals a real problem and which one would turn the product into something worse. It is knowing when a narrow version can teach you more than another month of planning. It’s being ahead of the data.

That judgment also appears in the company’s current approach to AI. It’s how they could create a workflow in their app that’s just as good as mine (given I’m building just for me, and they’re building for all their users).

Linear for Agents treats agents as full members of the workspace. They can be assigned to issues, added to projects, mentioned in comments, and used across several tasks at once. Instead of building one like I did, they just give you one.

That is the same product philosophy applied to a new technical era. Start with the real workflow. Decide how responsibility should operate. Put the capability where the work already happens. Do not make users reorganize their entire day around the fact that the company found a new technology.

Linear’s path is not proof that every company should ignore marketing and hope product quality creates a billion-dollar business.

The founders entered with credibility and relationships from some of the most respected technology companies in the world. The early customers were unusually influential inside the startup ecosystem. The investors included people who had built many of the products Linear’s customers admired. The company was selling collaborative software, where one enthusiastic user could introduce the product to an entire team.

Those are real advantages. But all of them point to the same conclusion. They were able to build a great product for that specific type of customer.

It then kept the team small, stayed profitable, launched repeatedly, talked to users, published the work, protected the product’s speed, and resisted the pressure to become a worse version of the incumbents it wanted to replace.

A recommendation worked because the product felt different. A launch worked because something meaningful had shipped. A changelog worked because users could see the product getting better. An influential investor mattered because the company lived up to the credibility they provided. An employee could bring Linear into another company because their previous team had genuinely preferred working that way.

That is what makes the story useful for builders.

Does the product give customers something they want to talk about? Is there a natural way for that preference to reach the next person? When customers ask for more, can you understand the problem without destroying the qualities that made them care?

Linear’s advantage was never one beautiful interface or one clever growth loop. It was the connection between founder experience, product judgment, influential early users, and smaller, repeated launches.

That is a much harder system to copy. But that’s why it works.

Thanks, as always, for reading.

Darwin