I was on a flight from Lisbon to Paris recently.

Sitting on an airplane is one of those moments where I eventually get bored enough to start exploring my iPhone settings.

While I was reorganizing my phone, I had a sudden realization: Settings are typically seen as the result of design failure. The thinking goes that as designers, our goal is to create product experiences that 

 require any adjustments by the user. Consequently, offering customization options is interpreted as a failure to make firm product decisions.

I think there is a misunderstanding about what settings really are.



There certainly are moments where I find myself on the settings page of a product because it failed to deliver the experience I really wanted. But not all settings are created equal.

There’s a difference between product settings that a product 

 get right by default and preferences that designers deliberately 

First of all, remind yourself that users love settings.

Despite initially being born out of the absence of airplane WiFi, I actually enjoy discovering new settings on my iPhone that will make my life easier or improve my productivity.

Just look at your own user behaviour: 
What do you do when you set up your new computer?

You change your background image. 
You adjust your mouse speed. 
You set a default browser.

You make all of those rearrangements not because the operating system is badly designed. You make them to create a more comfortable environment. To feel more at home.

In the end, this is the feeling we all try to re-create as designers.



As a designer at Linear, I recently spent a lot of time redesigning our settings view. We understand that our users will spend a lot of time with us and so we really want to make sure that they can feel that we care about them.

During our team discussions, I realized that adding a customization layer to Linear had an additional benefit: It’s an excellent way to showcase our product and educate users about all its functionalities. 

Some users immediately explore Linear’s settings to tailor their workspace to their unique team processes. So it made perfect sense for us to add tutorials and tips directly to our settings page. Once users have grown more experienced with Linear, they want to go deeper on the customization options of their workspace — and again, the settings page is the most natural way to learn what they can adjust.

With these realizations in mind, we approached our settings redesign like an onboarding experience. We created a settings “homepage” to show users what they can do with Linear and experiment with different functionalities.

When our users come across a feature or integration that isn’t working the way they want, they typically send us screenshots of their settings page. So we decided to use this space to display tutorials and tooltips. This way, users can learn more about the product and its features by simply navigating the settings.

Come for the vision, stay for the details



In addition to workspace settings, we also provide user-level settings. You can add custom emojis or import the ones you already have in Slack. We also allow you to completely customize your theme colors and other aspects of the app.

From a business perspective, focusing on small design details like this can be seen as a distraction. But if your users don’t feel comfortable using your product, even if it’s due to small details, they quickly leave you for a more cozy place. A place that feels more like home.

Some details become annoying because they are so repetitive. Some details are simply a matter of taste - not just UX/UI. By talking to users you can spot those details and introduce small settings that improve users’ lives without changing or disrupting your product direction. As the name suggests, they are just preferences.

One of the small preferences we introduced in the Linear app is not displaying the mouse cursor pointer over links. We want to mimic the feeling you natively have on the desktop with our Mac app. Most of our users never notice it - but to some it feels really weird. So we gave them the option to make the switch if they don’t like it.

People have certain habits and preferences. 
Our job as a company is to create products that fit into people’s lives, not the other way around.

The systematic thinking in our industry is that settings are the result of design failure. As designers, our goal is to create product experiences that don’t require any adjustment by the user. So offering customization options is often seen as a failure to make firm product decisions. I think there is a misunderstanding about what settings really are.

Settings are not a design failure

Building software products is like going on a journey.

When you are on a journey, you typically look ahead. You look at the ambitious goals you set for yourself. The mountain peak you want to climb. The next milestone you want to reach.

Looking ahead keeps you on the right track. It gives you direction and serves as a reminder for why you went on your journey in the first place. But every once in a while it's worth it to stop for a second and to take a look back.

Looking back helps you to see all the progress you have made on your journey so far. It gives you a sense of accomplishment. Sometimes it's worth looking back just to enjoy the view.

At Linear, we are on a journey to bring back the magic to software. Our mountain peak is building tools for the next generation of high-impact companies - so that they can be more successful on their respective journeys.

But today, we are not here to talk about where we are going. We want to stop for a second and take a look back. We already 

publish regular changelogs about new improvements and updates

) - so today we'll look back at our entire 2021 journey. The last 347 days to be exact.

2021 has been an exciting and productive year for us. A year full of progress and momentum. We shipped 

 over the last twelve months. Highlights include our integrations for 

. Each of them is like a small mountain peak we had to climb on our journey to get to where we are today. The graph above features the ten largest projects we worked on this year - our 2021 summits, so to speak. Their height is determined by their number of issues weighted by their respective estimates.

We created our first issue of the year on Sat, Jan 02 2021 at 10:59:31 GMT. Since then, the team created 

earlier this year which made this process way faster.

. Nov 10, 2021 was our most productive day with 45 issues marked as completed.

Of the 2489 issues we completed this year, 

 - many of them via the Linear Slack community which has 

 joined us during our journey this year, bringing the Linear team to a total of 

. We are a fully-remote company and currently work across 

No great journey has ever been completed without sufficient energy supplies. That's why we cook or bake together over Zoom at least once a quarter. In 2021, we organized 

 which included everything from Enchiladas to Japanese roll cakes.

Looking back at everything we worked on in 2021 gets us even more excited about what's coming in 2022. We have an ambitious roadmap ahead of us with a lot of exciting mountain peaks to climb. And we are looking for pioneering and passionate people to join us on that journey.

If your 2022 goals include taking up a new professional challenge, you should 

2021 has been an exciting and productive year for us here at Linear. We look back on a year of progress and momentum with dozens of new features, hundreds of fixes and improvements, and thousands of completed issues.

Linear – 2021 Wrapped

Fast growing startups are built on Linear

We launched Linear exactly one year ago to help high-performing teams who wanted a better way to build software. Linear is fast, effortless, and simple to use. It streamlines core aspects of product team workflows so that they can focus on the work that matters while our tool does the rest.

We’ve grown a lot since then as a team, and so have the companies that use Linear. The challenges they and we have faced in scaling inspired many of the features that we built for 

“We were constantly fighting our existing issue tracking tool to support EPD. We felt there was a lot of “work about work” to keep tasks and projects organized. Linear is different. It has a better model and structure for engineering orgs. Sprints, points, priority, and status are all treated as first-class properties of tasks. Search and filtering are powerful and the timeline view is one of the best I’ve seen.”


A big challenge startups face once they hit product-market fit is how to keep processes simple while their teams increase in size and their product grows more complex. Coordination is relatively easy at five, ten, and even fifteen people. Most employees are individual contributors who manage their own work and do so on small, autonomous teams. Project planning and issue prioritization is simple when you’re focused on a small feature set and handful of customers. But once a company hits that lucky spot where numbers start to go up and to the right, they go from dealing with product-market fit problems to scaling problems.

Scaling is hard. We know this ourselves, from our work on Linear and especially from our experience building products at high-growth companies like Coinbase, Uber, and Airbnb. We saw it done well and not so well.

Too often, the approach to scaling is to add layers of processes and more tooling. This ends up creating busy work and disrupting the dynamics and workflows that helped the earlier team succeed. What you actually want is a way to simplify processes, make workflows more efficient, and design ways to work together so that it doesn’t seem like you’ve added new layers even if you have.

As a distributed team, we were looking for a better tool to help us manage our product development work and reduce the cost of coordination…Then we tried Linear and suddenly all our task management problems went away. I think one of the main reasons was the speed. The team felt that they could get into the tool, find what they were looking for or figure out what they needed to do, and then get back to work.

Justin “Vegetables” Reidy, Senior Engineering Manager, Loom

The next generation of startups is being built on Linear. Some of the fastest-growing startups and industry-changing companies from around the world. We learn so much from how they use the product and their feedback on Linear.

This release brings new features that help them manage added complexity without losing the efficiency of small teams. At the core are two traditionally complex issues, triaging requests and roadmap planning.

We build in public at Linear and put care into talking to users and getting feedback. We talk to hundreds of customers each week through our 2k+ strong 

 followers, and to users who send in bug reports, requests, and questions through our in-app help modal which routes to a Front Inbox.

We like to link to customer conversations in Linear issues so that we can keep track of requests and get back to customers when issues resolve. As we grew, we found it harder to do that. We weren’t alone as we learned a lot of our customers faced this same problem: they had Linear issues filled with links to customer conversations. Some also had started building separate Triage “teams” where they would file all new issues, then clean up, prioritize, and move them to the appropriate team.

So we built this user experience into the product in our new Triage feature. All new issues from integrations or members outside of your team now go to a special team inbox called Triage. These issues have linked attachments back to the customer support tools where they were created.

The product team can choose how they triage issues but we’ve built in a simple workflow you can follow, too. Use keyboard shortcuts or the menu to accept an issue to the backlog, escalate it to the current cycle, merge, decline, or even snooze the issue for later. Declining an issue prompts you to leave a comment explaining why and you can keep an issue in the Triage inbox while you wait for more information.

We’ve been using Triage at Linear for the last couple of weeks and find it, along with the customer support integration with Front (in beta), incredibly useful for our team. With our new integrations, you can now create Linear issues from Zendesk, Intercom, and Front. If you’re tracking feature requests (we have a separate Linear team for this), you can attach multiple customer conversations to a single Linear issue and attach any URL such as tweets or Slack posts from your community Slack group.

This makes it incredibly easy to track requests and for product teams to get back to customers directly with follow up questions. We show issue details and status updates directly in the customer support tool and re-open customer conversations once issues have closed.

Roadmaps are critical guideposts for any organization but they have a tendency to be “set it and forget it” experiences in many tools. It’s easy, almost inevitable that plans change, especially at younger, fast-paced companies and so your initial estimations go stale.

Rather than fight entropy, we designed our roadmap around the uncertainties and practicalities of product development. We generate the timeline from your project data, so you don’t have to do any extra work to lay it out in that view and the data is always in sync. The timeline updates anytime you make a change anywhere in the app to a project or its related issues. We use actual issue data and historical trends to estimate project completion dates, so you don’t just see plans but get a preview of future work based on actual velocity. This makes it easier to spot projects that need help or rescoping and to adjust plans accordingly.

At Linear we like to build in public. We publish a 

 to celebrate our progress and share it with our customers. The theme for the first half of 2021 was to improve Linear for our growing customers.

Timeline view for Roadmap with live predictions

Triage Inbox for teams that lets you create, prioritize, and assign new issues with quick actions including Snooze. Inbox now has snooze, too

Customer support integrations with Zendesk, Intercom, and Front

Private teams so you can control access to sensitive issues and projects

Fast issue input that lets you create multiple issues in a row, save drafts, and create issues in a modal so that you don’t lose context

Typescript SDK and new developer documentation at 

Issue Migration Assistant that lets you import issues in minutes from common issue tracking tools to Linear

Powerful backend search that can search the archive and also shows you recently opened issues

Auto-archive that retains statistics and automatically archives your issues, cycles, and projects at a regular cadence between 1–12 months

New integrations including Netifly, Incident.io, Codestream, and Slab

Startup performance improvements to make Linear even faster

Improvements to issue merging, issue view layout, issue grouping, GitHub notifications, and keyboard shortcuts help. A feature to delete issues.

Updates to the Zapier integration, new webhooks, and API improvements

Check out our newest release to learn more

Another milestone for us is that we’ve grown in size and continents. We added three new team members since our last launch bringing the Linear team to 11 strong working remotely in US, Sweden, Finland, Portugal, France, and Argentina. We’re hiring for engineering, design, and operations across GMT+3 and GMT-7 time zones.

 Jori and I built another company that was part of the Y Combinator’s Summer 2012 batch. There were a lot of lessons I learned from YC. However, one thing I wish I had understood better was what effective product development looks like.

Back then, we knew how to code, design and ship but we didn’t know how to prioritize effectively, set meaningful goals, or keep the momentum up week after week. While at the very beginning this is not that critical. It becomes more when you get to the stage of having a product and user to support. You need some structure to keep making meaningful progress and not going around in circles.

We learned some of this as we went through YC, and later over the years working in companies like Coinbase and Airbnb. I wish I had this understanding then and would have been able to focus more on the right things.

I often get questions from early-stage founders asking for tips and advice on how to run product development in the early stages. This is the basic model we use as well as some advice on how to think about product development in the early days.

in part to make it easier for anyone to build products and give people a tool we wish we had when we were YC founders, one that was easy to use and encouraged good product development practices so we could spend more time shipping and talking to users, and less time figuring out how to manage our work.

Active YC companies get a year free of Linear. Find details on our YC deal page.

As a new startup, you operate with a non-existing, or small user base, unfinished product, and limited understanding. In those early days, it’s better to aim to move fast as possible, try things out, learn and then fix and adjust. Momentum matters more than anything.

Moving fast doesn’t mean you shouldn’t have any structure or goals. The structure aims to keep up pace and momentum week after week, maintain the team’s health and avoid going in circles. You should keep these structures and tools lightweight as possible and make sure each of them has a purpose and it aligns on delivering value to the user.

Much of the early startup process is about learning what your customers want. You should seek out users or potential users for feedback, iterate, and be flexible to meet the demands of your customers and the market.

However, your task as a founder is to find a balance between building toward your vision/intuition and building what the users want. Too vision-based products might miss user and market needs while too reactive products become Frankenstein creations without a clear purpose. You need to keep refining your product vision based on your user feedback.

Understand that users will project their needs from the context or product they currently see, not the product that you’re trying to build. It’s common for users to ask for features you should add. Whenever they do, it’s important as a product builder that you ask them questions back. What is the use case? What is the problem they’re trying to solve with this feature or solution? How would their experience of the product be different if the problem was fixed?

By pivoting the conversation away from a feature request and toward explaining the problem they are trying to solve, you move the discussion towards the pain point. In this conversation, you’ll learn whether the problem is valuable to solve or nice to have. It also allows you to explore multiple solutions to the problem, and to choose the right one within the context of your broader vision.

You may also talk to users who have a lot of feedback but who aren’t in your target demographic or aren’t it now. If you think you are building for things for early-stage startups, listening to an enterprise customer will likely set you on the wrong path and it’s unlikely that they will even become a customer.

Incorporate the feedback and let it refine your product, but don’t let user feedback alone dictate what you build. You can become too reactive to user feedback. This is why it’s good to have goals and roadmaps, that help you balance the needs of the users and the needs of the company.

Startups move so fast that it’s normal not to know what you’re working on the next day let alone the next week. Goals are important to remind you what matters for the medium or long term success of the company. You might not feel like you have enough users or historical data to make decisions on what your goals should be. That’s normal and in those situations, create a goal that propels you forward in some measurable way.

In the early days, it can be hard to hit those goals when you start from zero. The way to think about it is to walk back from that goal, what is the path there. Path to 10 users starts with 1 user, which starts with having a product that someone can find and start using.

During YC your goal is to achieve meaningful traction by demo day. Your first meaningful goal getting there could be to find 10 users to use your product, then 100, then $1000 in MRR. Successful startups often start with something small, figure it out, and then scale. And remember, there is no limit to how fast you can grow.

When you have some idea of which goals to tackle first, the next step is to figure out how. A product roadmap in a startup is a list of things you think you need to build to get where you need to be. Roadmaps are about setting direction and writing it down helps the team align on the direction. You should also realize you cannot do everything at once. The key is to think broadly but then only choose few things to do well and likely help with the goals.

In the first months of building Linear, we used monthly roadmaps. We’d brainstorm projects based on our goals and what we learned the month prior. We then selected 1–3 larger projects we saw most impactful towards our goals. This practice repeated over months helped ensure that we kept leveling up the product and didn’t get stuck only optimizing existing features. By only choosing a few larger projects, and not planning our time 100%, we left ourselves bandwidth to work on fixes and feature ideas from the user feedback.

We have a roadmap feature in Linear that you can use to build your roadmap but in the early stages, it can be as simple as one spreadsheet or document that lists the following.

Project description (at this stage you can have few paragraphs or bullet points to describe what do you think the project is for)

Why are you building this? (rationale why is it’s needed, how it’s supporting your goals etc)

The owner (who is responsible for building or driving this if there are multiple people)

Later, as the team grows or you feel that it’s necessary, you can expand these by writing brief 1-pagers to communicate the scope and details for the whole team.

At the early stages, scope projects. Design projects so that they can be completed in 1–3 weeks with a team of 1–3 people. Smaller fixes or additions should take only hours or a day. Shorter projects force you to prioritize the most important feature set, create quick feedback loops with customers and get into the habit of shipping continuously. Smaller teams help you move faster and reduce the overhead. When you’re early in the product building stage, you don’t know enough to predict whether a project will be impactful or not so it’s better to avoid massive projects. If there is no way to scope down the project, then break it down into stages.

For example, we shipped the first versions of

in the first couple of months of starting Linear. The MVP version of both of these features took us about two weeks to design and build. We shipped the early versions to ourselves and private beta users in the first week and started collecting user feedback immediately and fixing them in the following weeks. We’ve made a lot of improvements to Cycles and Projects since and both of them are now the major features of the product.

It’s really important to learn to prioritize and have a rationale why you prioritize something. You don’t have unlimited resources or time.

First, it’s helpful to think of new features as additive 

 Enablers enable new functionality that usually makes the product more valuable or interesting. Blockers are gaps or friction that prevents a user/customer to use your product. 

(Note: You should try to understand if the problem is truly preventing someone from using the product or nice to have

). You need to work on enablers and blockers to grow.

Secondly, it’s important to consider how timely something is. In the early stages, there are a lot of things you need to build eventually, but you should prioritize things that help you move the needle this week or month. You want to ask yourself if this is important to be done now or can it be done later. If you are successful with the idea, does it help your goals?

At Linear, we started only supporting Google Logins since that was the fastest way to build authentication and then move on to other features. We knew that eventually, we would have to support pure email and other login methods. This lets us move faster to learn about other features without spending our time building different authentication methods.

Whether you have a product roadmap or not, get your team together to discuss and decide what specific tasks the team will tackle this week.

Often with co-founders or with the team, there can be a constant stream of exciting ideas or debates. Use this one product meeting for brainstorming and discussion and then decide what is most important 

 and commit to delivering on the tasks. Then get to work. Brainstorming or debating every day can be distracting and prevent the team from making progress. In the end, only shipped features matter, half-built features or winning debates don’t help your users and therefore your company.

We always assign tasks in a cycle to a specific person. This makes it clear who is responsible for delivering the task, ideally, the person is the right person to solve it and it also makes it easy to see who is overcommitted or who has more bandwidth.

As we started getting users, we would start to add bugs to our cycles to maintain product quality. Startups often forget bugs, which if left unchecked, can create enough friction that slows down your growth.

During our first months, we set our cycles in Linear to be 1-week (which we recommend for YC or generally early for the early stage):

 discuss end decide what to do next. Assign responsibilities and get to work.

During the week as additional ideas or feedback came up, we would take notes personally, share them on Slack or add related tasks to the backlog but not start working or spend time debating them. This lets us capture learnings but remain focused on the work we decided to do earlier.

, we would review the work done, what we learned from our work, or talking to users, and then try to wrap up any open tasks if possible. The following Monday, we would start the process over again.

You and your whole team should always try to take swift action and make progress each day. Instead of thinking or talking about doing something, you decide to do it or not to do it. Then you do it today instead of tomorrow and this week instead of next week.

There will be also weeks when you won’t necessarily know what is the most important thing to do or you are not sure what decision to make in the product. Don’t become paralyzed in those moments–find a way to act instead. Trust your intuition and do something that seems to make sense. Talk to more users. You’ll gain more clarity as more feedback rolls in. If you’ve designed your operations to move fast and learn, then you can correct or revert decisions.

Startups rarely die because they made too much progress or because of a single bad decision, but they do die when they move too slow or give up

It might feel dangerous to show what you’re building but often it’s more useful. If anything, your competition might be discouraged by your speed and either forced to copy you or avoid copying you.

One way to build in public is to publish a changelog. It might seem silly to summarize your work in a changelog when you don’t have many users, but we think it’s helpful. For you and the team, it reminds you every week what happened and encourages you to ship constantly. For users, it shows the product is getting better. For investors, it shows progress. At times, when you feel things not moving as fast, you can look back at how much you achieved already.

There are other reasons why the changelog can be useful. Read more: 

People often think there needs to be a singular moment for launch. This doesn’t have to be the case and a lot of times many startups launch multiple times. It usually works better than having one massive launch. The problem with massive launches is that it takes time to prepare and they are riskier. There is also an increased risk that the launch won’t work and all the work is wasted. By launching multiple times, you are building your story and brand over time and compounding the interested people have. Each launch builds more following, which then helps your future launches.

Secondly, in the first months or years, your product is likely not a fit for everyone. It’s better to launch early, start getting users and momentum, than trying to wait for that perfect moment.

Similar to changelogs, launching keeps reminding the market about the fact your company exists and you’re making process.

: With Linear, we launched by announced the company before we had the product built. We launched when we raised seed funding and evolved the product. We launched when we opened the product for everyone and added pricing. We launched when we did a Series A and evolved the product. Each of the launches had reached more people and generated more customers than the previous ones. Had we only launched once, it would have taken us 1.5 years to get to the state and we wouldn’t have learned as much and would have as many customers as we have today.

While can use any tools or use no tool at all, we did create 

 to help startup teams to build momentum. Many YC and other successful startups use Linear today to manage cycles, organize roadmaps, and have that lightweight structure you need: 

Active YC companies get the Linear Standard Plan free for a year. Visit the YC deals page to activate it.

We knew how to code, design and ship but we didn’t know how to prioritize effectively, set meaningful goals, or keep the momentum up week after week. While at the very beginning this is not that critical. It becomes more when you get to the stage of having a product and user to support. You need some structure to keep making meaningful progress and not going around in circles.

Building at the early stage

 our focus has been on empowering builders to focus on their work of creating software. In the past year, we have come a long way and we are excited to share the latest milestones in our journey.

Today, we’re announcing that we’ve raised $13M in Series A funding led by Sequoia Capital and a slew of new product updates aimed at re-envisioning the principles and practices of building and continue developing the best in class tool for teams to create software.

Next Generation of Startups Are Being Built With Linear

Hundreds of startups today–from early teams to growth stage companies–use Linear to develop software and build magical products and customer experiences. Linear’s tool and product development methodology is becoming the standard for high-performing teams and the 1,000 people strong Linear Slack community is a hub of builders. Startups especially mention how Linear helps keep up momentum and find product-market fit faster.

“I think that one of the things that really high performing teams do is go from product feedback and into an execution plan of how we are going to get this delivered to that customer today, this week or this month. You err towards speed of execution because that’s how you find product market fit and that’s ultimately what “make something people want” means. 

Linear, in my opinion, is optimized for this and where it’s best in class

Tools like Linear have become even more critical as companies operate remotely. The tools are the new office and the way of making decisions and communicating ideas:

Linear has been super helpful in transitioning to remote

. Beforehand a lot of our conversations in person would ensure that nobody was doing the same work twice but now we need to have everything in Linear. Just to keep track of what’s going on. I can’t just roll my chair over and ask my coworker, “Hey, did you take a look at this.”

— Danielle Schugars, Software Engineer @ Render

The Linear team itself is fully remote and distributed across North America and Europe (

), and we think making a product that excels in a remote environment, means it will excel anywhere.

It’s our mission to help the next generation of startups build their companies and we’ve been especially honored to see the vast majority of our users become paying customers as we launched pricing plans this summer. This is fantastic validation of the product we have built and of course means a healthy and sustainable business for Linear.

Following this progress, to accelerate and to continue taking Linear to the next level we’ve partnered again with 

 who led our seed round last year will join our board. We admire and resonate with Sequoia’s and Stephanie’s long-term approach to company building and respect their exceptional track record of backing category-defining companies.

In addition, several industry leaders are participating in this round and bringing on their insights and networks: 

They will join our existing investors including 

The additional $13M in Series A funding brings our total funding to $17.2M. The funding and the support from our new and existing investors, give us the resources really acclerate and go after defining the new standard for software development.

Building a holistic tool for product building

Issue tracking lies at the heart of any software team’s workflow which is why we focused on solving this core pain point first. However, we know that building magical products and successful companies requires a lot more than fast and easy issue tracking. To build well, teams need a meaningful direction, clear communication and seamless coordination. Solving the human side of product management which includes implementing effective processes and then scaling them as their company grows in size as well as through different stages in the product development lifecycle.

As move to towards building product building, today we launch a few of our biggest features yet:

One of the most important aspects when building any product or company is to set the direction. An effective roadmap shares a unified vision and aligns teams to build toward that. Without a clear direction, it’s hard for any company to make meaningful progress, especially startups who have finite product cycles available to test product-market fit before runway runs out.

Despite how critical roadmaps are to success, in many companies they’re not visible for everyone, up to date or connected to the execution of product and company deliverables. The Linear Roadmap solves this by generating a project-based roadmap–always up-to-date, accessible to all teammates and with clearly defined milestones–to encourage best practices in roadmap planning and execution.

2. Extensions and integrations with OAuth

When Linear opened for everyone six months ago, we quickly started seeing companies and developers building integrations and add-ons for Linear. We see Linear as a critical tool for company building and we don’t want to lock it down. Linear should be a platform that connects with more of your external and internal tools. With this launch, we’ve added OAuth in addition to our GraphQL API, to make it easier and more secure for developers to build and use integrations with Linear.

 to celebrate our progress and share it with our customers.

To help give a holistic picture of what is new in Linear, we created a new 

 page which highlights new features as well as major improvements developed in the last six months. The theme for the second half of 2020 was to improve the core experience of Linear:

Made the interface more tactile by allowing 

s that let you quickly change sorting, hide and show attributes, and switch between list and board views

 which let you create and save custom filtered views for yourself or shared with the team or the whole company

 option for more secure and controlled authentication

 to allow everyone to customize how Linear looks

See all the new features by heading to the 

We started Linear 20 months ago with a simple insight: building software is becoming increasingly complicated. The current approach is to layer more processes and cumbersome tools. We want to see a world where we unwind all of this by providing the practices and tools fit to the builder workflow and letting the team focus on the act of building.

Here’s to the next 20 months. We are grateful for all the support we have received from our customers, partners and investors. Let’s make software as a craft feel magical again.

Linear raises $13M in Series A funding from Sequoia Capital

We recently added contextual menus to Linear. This makes the app faster and easier to use for people who prefer their mouse.

One small thing that you won’t see or think about but will hopefully *feel* is a detail we designed into how sub-menus work.

You may know contextual menus as “right click” or “pop up” menus. Right click with your mouse on this post (or 

 with your trackpad) and you’ll see a short contextual menu appear on your screen with options to reload or save the page. Contextual menus were first popularized by applications such as Microsoft Word which added them so users could more easily copy and paste. You’ll find them in most web and desktop-based applications.

Contextual menus make applications faster and easier to use when navigating a page with your mouse. On Linear, we let you take almost any action on an issue from the contextual menu: set the issue status or priority, assign the issue to a different member of your team, change the estimate, mark it as blocking or a blocker to another issue, mark it as a duplicate, add the issue to a cycle or project, copy the git branch name and even archive the issue to remove it from your active issues list.

We’re learning that contextual menus are also a great tool for onboarding and teaching people how to use our popular keyboard shortcuts. You can take almost every action in Linear without lifting your fingers off of the keyboard or using a mouse at all. For instance, instead of moving your cursor to the purple plus sign and clicking on it to create a Linear issue, you can just type 

We find many Linear users prefer keyboard shortcuts for their speed but it can take some time to learn all of them. It’s also easy to forget the less-used keyboard shortcuts such as the one that lets you move an issue between teams (

). Previously you had to open the command menu with (

) and then type out a search query to find a keyboard shortcut you forgot or type 

 and then search our long list. Now you can simply right-click to take the action with the mouse or remind yourself of the keyboard shortcut.

How we built the contextual menu in Linear

In the first iteration of our menu, to access an item in a sub-menu you would have to move the cursor out in a straight line from the selected item onto the sub-menu, then move down from the top of the sub-menu to the item you wanted to click. You basically have to make an upside down L shape with your mouse.

The original design had a couple of problems:

. It feels more natural to move the cursor in a diagonal line from the selected menu item to the sub-menu item you want to click. If you did that, though, the sub-menu would disappear before you could select the sub-menu item.

 At Linear we care a lot about speed. It may only take a fraction to 1–2 seconds longer to move your mouse in an upside down L shape but the seconds add up when you’re taking the action multiple times. Some product and engineering managers take hundreds of interactions a day on Linear. Add in the time required to recoup after a menu disappears on you and the related frustration and it starts to feel like an important interaction to improve.

If you think about it, there’s no real reason why we build contextual menus that require this longer path when there’s an alternative. The shortest distance will always be the Euclidian, or diagonal, distance compared to the Manhattan distance, the distance taken when following the lines of a grid.

Adding safe areas to contextual menus is not a new problem. 

 have all implemented mechanisms to handle contextual menus better on their web apps. Native operating systems have followed these design pattern for many years. However, it’s a detail that’s often overlooked early in a web application’s development.

There are a few ways of approaching how to build contextual menus that let users scroll easily to the sub-menu items. We thought the best way would be to draw a triangle between the mouse cursor and the sub-menu to create a safe space where the mouse could move without triggering the sub-menu to close. So we built a component to do just that.

The safe area lets you move the mouse along the shortest path without closing the sub-menu

Here’s how to build a React component that creates a “safe area”:

The component gets a reference to the sub-menu as its only prop so that it can measure its size and position on the screen.

 that listens to the mouse movement. It’s used like this:

Now we have all the information we need to calculate what area to render between the cursor and the sub-menu. We need to figure out the position and size of the triangle as well as align the corners of the triangle correctly.

The most interesting bits in the snippet above are perhaps the functions that calculate left, right, width and 

 is a cool css property that lets you define a region of the component that should be drawn to the screen. In this case we use a 

Not too bad! It only took about 40 lines of code all in all. Hopefully people using Linear will feel the difference.

here’s a gist with the full implementation

Invisible details - Building contextual menus

At Linear, we believe software can feel magical. Well designed tools and practices encourage momentum and level up execution in our teams. Linear is now open for sign ups at

This past year, we’ve been working on refining Linear with our early adopters. We’ve spent hours talking to company founders, managers, designers and engineers. The common theme across conversations has been how broken the current ways of working are in the software industry, the subpar quality of the tools we use to build software, and how much change a product like Linear can bring.

Engineers and creators feel that their time is drained with continuous stand-ups, retros and reviews. Teams are hindered by slow and confusing tools. These practices and tools don’t seem to improve the quality of our work but they do make us dread our jobs. 

At Linear, we believe that the quality of software is driven both by the talentof its creators and how they feel while they’re crafting it. Teams that can focus their time and energy on the work itself build magical, high quality software.

Our tools and practices need to do their best to nurture this kind of environment and not take it away. They should be fast, integrated, save time, help to coordinate and most importantly, not get in the way of practicing our craft. This is why we’ve prioritized building an elegant, fast, and considerate product for software building teams.

Linear Method — Our practices for building quality software

Blog|Updates from the Linear team

Settings are not a design failure

Linear – 2021 Wrapped

Fast growing startups are built on Linear

Building at the early stage

Linear raises $13M in Series A funding from Sequoia Capital

Invisible details - Building contextual menus

Practices for Building — Linear is now open for all

Startups, Write Changelogs

Linear’s Next Chapter: Announcing our $4.2M Seed Round

Subscribe to our newsletter