In 2015, Karri Saarinen joined Airbnb as a Principal Designer.
It was the first time he had to use Jira. His reaction was immediate. He later recalled looking at it and thinking: "What is this thing? It's so messy and so complicated." He refused to use it for a while. Then, realising that boycotting the tool wasn't actually productive, he did something unusual: he built himself a better version.
Not a new product. Just a Chrome extension just a custom CSS stylesheet that loaded on top of Airbnb's internal Jira instance. Cleaner visual hierarchy. Less noise. Something he could actually look at without feeling vaguely defeated.
He shared it internally, almost as an afterthought. A hundred people at Airbnb installed it.
That was 2015. Linear wouldn't exist for another four years.
Karri Saarinen, Jori Lallo, and Tuomas Artman had known each other for years. Karri and Jori had even founded a startup together before called Kippt, a bookmarking tool that went through Y Combinator and was acquired by Coinbase. After that, the three took different paths into Silicon Valley. Karri went to Coinbase as founding designer, then to Airbnb. Jori stayed at Coinbase as a senior engineer. Tuomas went to Uber to build infrastructure.
They hadn't gone to these companies by accident. Tuomas later put it directly: "I consciously took jobs in Silicon Valley to prepare for my next startup. I wanted to learn, build up pedigree, and create a financial buffer."
In early 2018, they met for beers. The conversation that started Linear was remarkably simple: they'd all used software development tools at multiple high-growth companies, and every single one of them was bad. They thought they could build something better.
But they'd noticed something important beyond the obvious complaint. The tools weren't bad by accident. They were built for the wrong person. Jira, Asana, and their competitors had been designed for managers and procurement teams, for whoever signed the contracts. The engineers and designers who actually had to open the tool every morning had no say in the purchase decision, so no one had seriously built for them.
That was the real gap. Not a missing feature. A missing user.
In 2019, they raised a $4.2M seed round from Sequoia, partly because a partner at the firm had been hearing about the product through her Twitter network. They launched into private beta.
And then they didn't rush.
Unlike their first startup, this time they built deliberately. The early version of Linear was highly opinionated. There was no sprawling settings panel. No "customise your workflow" mode. Co-founder Jori Lallo would later describe the philosophy plainly: "We design it so that there's one really good way of doing things. Flexible software lets everyone invent their own workflows, which eventually creates chaos as teams scale."
They stayed in private beta from 2019 through to June 2020 by building carefully, mostly with friends at early-stage startups, watching how the product was used rather than reacting to every request that came in.
When Linear exited beta in June 2020, the response was immediate. Engineers were talking about the speed. Designers were sharing screenshots. Product managers were sending the link to their teams. The launch spread almost entirely through word of mouth.
As more teams started using Linear, the feature requests came in. Enterprise teams wanted more flexibility. Startups wanted more customisation. People asked for workflow modes that didn't fit Linear's model of how software development should work.
Linear said no to almost all of it.
This wasn't stubbornness. It was a carefully maintained philosophy. Jori described the distinction in a piece for the Figma blog: at the atomic level issue properties, labels, due dates, Linear is very opinionated, because those things shape how the tool actually feels to use every day. As you move up to higher-level concepts like projects and team structure, they take more cues from customer feedback, because every company is organised differently.
In other words: they weren't ignoring customers. They were selective about which feedback shaped the core product versus which feedback was asking them to become something they'd decided not to be.
Their strong opinion was that issue tracking had become an endless configuration tool because the entire category had lost its point of view. Every vendor had tried to serve every workflow for every type of team. The result was software so "flexible" it required a dedicated admin to maintain, a handbook to onboard, and recurring team meetings to agree on how to use it.
Linear's answer wasn't a better Jira. It was a deliberately smaller, sharper one.
By June 2021, two years after founding, Linear announced it was profitable. Karri shared this publicly: the company had more cash in the bank than it had ever raised. There was no marketing department behind it. No outbound sales team. No cold calling enterprise accounts.
The product was the distribution.
By 2023, they raised a $52M Series B at a $400M valuation. In 2025, an $82M Series C at $1.25B. As of today, Linear powers more than 25,000 product teams, including OpenAI, Ramp, and Vercel. They built all of this with 87 employees and only 20% of whom are in sales.
The opinionated approach that had felt like a constraint in year one became a moat in year five. The teams who chose Linear chose it precisely because it didn't try to be everything. The product had a clear perspective on how software development should work, and the people who shared that perspective became advocates, not just users.
There's a version of the Linear story that sounds like a simple rule: "Don't listen to your customers."
That's not the lesson.
The real lesson is about sequence. Linear didn't ignore customers instead they chose a specific user to build for, built a precise experience for that person, and resisted pressure to dilute it before they'd proved it. Karri has said this explicitly: "My design philosophy has always been that you should design something for someone. It's hard rather impossible even to design something really good for everyone."
Most early-stage founders do the opposite. They come out of user interviews with a list. They add to it every week. They build features to satisfy whoever they spoke to last. The product grows wider and shallower with each sprint, and by the time it launches, the original insight that made it interesting has been buried under a dozen compromises.
At BuildOrbit, we see this pattern constantly. A founder comes to us with a genuinely sharp core idea, something specific, something that would resonate with a clear type of user. And then, in the weeks before we start building, the scope expands.
"Can we also add this?" "What if users want that?" "Our angel investor thinks we should include X."
Each addition is reasonable in isolation. Collectively, they turn a focused product into a cluttered one.
The most important conversation we have with a founder before writing a single line of code is about what the product actually is. Not what it could eventually become. Not what it would need to include to serve every possible user. What is the one version of this product that solves a specific problem well enough that a user would tell a colleague about it unprompted?
That conversation is uncomfortable. It requires saying no to things that feel reasonable. But it's the same conversation that three Finnish engineers had in a bar in 2018, after years of watching great products bury themselves under their own complexity.
They built Linear for a specific someone. You can feel who that person is in every design decision in the keyboard shortcuts, the speed, the refusal to add friction they hadn't asked for. The product feels that way because it was built for a person who deeply understood what was broken about the previous generation of tools.
Before you add the next item to your v1 scope, it's worth asking: is this making the product better for your core user? Or is it making the product bigger for more users?
They're not the same thing. And the distinction, compounded across a hundred small decisions, is often the difference between a product that resonates and one that compromises its way to irrelevance.
If you're working through what your v1 should actually include or trying to get clear on what to cut before you start building that's a conversation we have with founders often at BuildOrbit. Get in touch.
