Linear Playbook

fmfmerian Many teams like Buffer, Doist, or Zapier, set transparency as a core marketing strategy. Similarly, Linear sets its Playbook as the first link in its navbar. 10 chapters on the vision and the company culture.
At Linear we believe software can feel magical. Quality of software is driven by both the talent of its creators and how they feel while they’re crafting it.
To bring back the right focus, these are the foundational and evolving ideas Linear is built on.

Introduction

Principles and Practices

Principles

Build for the creators
Software project management tools should build with the end users – the creators – in mind. Keeping individuals productive is more important than generating perfect reports.

Opinionated software
Productivity software should be opinionated. It's the only way the product can truly do the heavy lifting for you. Flexible software lets everyone invent their own workflows, which eventually creates chaos as teams scale.

Create momentum – don't sprint
We should find a cadence and routine of working. In cycles, we decide priorities and assign responsibilities. Our goal is to maintain a healthy momentum with our teams, not rush towards the end.

Meaningful direction
Our daily work might be filled with tasks but we should understand and remind our teams of the purpose and long term goals of our work. Roadmaps, projects and milestones are all important to keep in mind as we plan our weekly schedules.

Aim for clarity
Don’t invent terms if possible, as these can confuse and have different meanings in different teams. Projects should be called projects.

Say no to busy work
Our tools should not make us the designers and maintainers of them. We should throw away or automate the busy work so you can focus on the more important work.

Simple first, then powerful
Teams at different sizes have different needs. Tools should be simple to get started with and grow more powerful over time.

Decide and move on
There isn't always a best answer. The important thing is to make a decision, and move on.

Practices

Set monthly, quarterly or/and annual roadmaps
Ambitious goals are the only way to make a significant impact. Companies should focus on them when they define their high level direction. Reserve some space on your roadmaps for unexpected and reactive work that always comes up and allow your roadmap to change if needed.

Connect daily work to larger goals with projects
All projects and work should directly correlate to these goals. Review projects and their target dates during roadmap meetings and pull from projects as you plan cycles.

Work in n-week cycles
Cycles create healthy routine and focus teams on what needs to happen next. 2-week cycles are the most common in software building. They're short enough to not lose sight of other priorities but long enough to build significant features. Cycles should feel reasonable. Don't overload cycles with tasks and let unfinished items move to the next cycle automatically.

Keep a manageable backlog
You don't need to save every feature request or piece of feedback. Important ones will resurface and low priority ones will never get fixed. A more focused backlog makes it easier and faster to plan cycles, and ensures the work will actually get done.

Mix feature and quality work
All software has bugs, more than we can ever fix. Include bugs and other fixes as part of your cycles. Invest in tooling as it is a force multiplier if done right.

Specify project and issue owners
Each project should have a named owner responsible to own delivery and write the project brief. The same goes for issues. Others should collaborate but responsibility should lie with a single person.

Write project specs
Aim for brevity. Short specs are more likely to be read. The purpose of a spec is to briefly communicate the "why", "what" and "how" of the project to the rest of the team. Ideally these short documents force teams to scope out work so priorities are clear and teams avoid building the wrong thing.

Understand your users
The more popular your product, the more feedback you'll get. Overflowing inboxes are a good sign unless they're bug reports. Don’t worry too much about organizing all the feedback. Collect it and use it as a research library when developing new features. Try to spot trends. Use feedback, even complaints, as an opportunity to get to know your users and ask them to explain why they want a specific feature so you find out their needs. Solve the problem – don’t just build the feature.

Scope issues to be as small as possible
It's hard to see visible progress when working on large tasks, which can be demotivating. Break down work into smaller parts and create an issue for each one when possible. Ideally you can complete several concrete tasks each week. It feels great to mark issues as done.

Measure progress with actual work
The clearest way to see whether something is complete or not is to show the diff in the code or design file. When the tasks are scoped small, your changes will be small and easier to review, too. Avoid massive pull requests or large design changes.

Run cross-functional teams
Designers and engineers should work together on projects, creating a natural push and pull. Designers bring their skills to explore ideas and push your team's thinking. Engineers can challenge thinking around implementation and will bring the winning ideas to reality. The best creators often have talent for both. Directly loop in other teams when building features they'll use or ask customers they interact with to use.

Write a changelog
It’s important to look back and celebrate what you achieved as a team. Consistent changelogs also communicate to the user new features, the value they get from your product, and your commitment to improving it. It's also an easy way to connect your team's individual work to the collective value they create.  Read more  on how we write ours.

Direction

Roadmap sets your team direction

Setting direction is one of the most important things you’ll do when building a product and company. A clear direction aligns everyone to work toward the same goals. It helps individuals make daily decisions, teams prioritize projects and all members of your organization feel motivated toward a shared purpose. Without direction, it’s harder to work together, know what to focus on and make meaningful progress.

Roadmaps are a critical tool for shaping this direction. The process of creating a roadmap forces you to articulate a vision and decide how to build toward it. The culminating roadmap sets a path of execution for the near future, slightly in front of you and ideally a bit out of reach. Anyone in your company can look at the roadmap to quickly understand what to work on and why it matters. A glance at the roadmap reveals progress clearly and can help you identify projects that need attention.

Whether you’re part of a three-person startup or one thousand employee company, a roadmap helps you and everyone you work with make better decisions more quickly and focus on more valuable work. Clear roadmaps keep teams aligned even when individuals work independently. Ambitious roadmaps push people to challenge themselves to do their best work. Visible roadmaps motivate individuals by them giving context on why their work matters and create a culture of transparency that builds trust, making collaboration easier and even spurring it serendipitously.

These are the practices to follow when building and managing a roadmap:
  • Invest in planning
  • Break it down into milestones
  • Work on substantial projects
  • Prioritize for impact
  • Review regularly
  • Stay flexible

Invest in planning
There are different ways to plan out the roadmap. You'll probably choose a small group of company leaders to build it, unless you're small enough that you can run an effective planning meeting if the full team participates. Carve out meaningful time before your first meeting together to think through company goals and what parts of the product you want to improve most. Use your product intuition. Review customer feedback and feature requests. It's also important to review company metrics such as sign up, activation, retention and revenue so you know how to make trade-offs between features and whether specific areas of the app should be prioritized higher than others.

While you'll build the initial roadmap with a small team, people like to feel included and will feel more ownership if they participate in the planning process in some way. Give everyone a chance to contribute. Let teams propose their own projects and you may even set a window of time for anyone to submit feedback and ideas. Also, talk to your customers. Reach out to customers who have asked for features you're considering prioritizing, especially if you're unclear on the customer need or scope of the project. However you plan your roadmap, it’s helpful to timebox the process and develop a repeatable structure so it becomes easier to create overtime.

Break it down with milestones
There will always be an endless list of projects to build or ideas to pursue on the roadmap. Infinite lists can be hard to prioritize and demotivating to view, so it’s helpful to break down roadmaps into milestones that are based on time, theme or goal. 

Time-based milestones give planning and execution a regular rhythm. Examples include monthly, quarterly and annual roadmaps. Shorter milestones are easier to plan and naturally encourage you to scope down projects so they fit within them. Success means realizing most of the projects.

Goal-oriented milestones tie work to specific outcomes. Examples include building a large feature, new design or toward a public launch. Success means completing enough projects to ship or meet the goal.

Thematic milestones define a focus that narrows down the list of projects. Some example themes could be to improve the core experience or drive engagement. When using thematic milestones, it’s helpful add a time or number limit to keep the list of projects manageable. Success means impact that you can see or measure.

Work on substantial projects
Ideally, the projects you choose to work on make concrete progress in some way. They may create new functionality, launch a campaign or improve an existing area of the product. Build features to completion and avoid breaking down projects into chunks so small that progress doesn’t feel meaningful. Some projects have to get done no matter what such as building tooling and documentation, so fit these into the roadmap and use them to balance out the type and intensity of work. Sometimes teams will also bundle smaller issues into a project to make it more fun. For example, you could create a project called bug week where the focus would be to work through priority bugs from the backlog.

Prioritize for impact
Use higher-level milestones to help focus work toward more meaningful projects. Prioritize foundational projects first and those that will have the greatest impact on the customer experience. Deprioritize projects that don’t improve the product for customers, help you hit company targets or increase the quality and speed of work.

Once you have a list of projects to work on, adjust the sequence as needed to juggle teammate availability as well as project intensity. Work on a couple of smaller projects after shipping a larger feature to avoid burnout. Rotate project leads so top performers don't feel overburdened and everyone gets a chance to develop project management skills. You should work on as few projects at a time both as a team and as individuals. Ship existing projects before starting new ones. Focus produces higher quality work and shipping builds execution into a habit. Order projects so new work builds on top of previous projects which will make changes feel organic and can have compounding effects. It’s also better to ship three significant projects than to end the roadmap with ten half-completed ones.

Review regularly
Create a routine around reviewing the roadmap and evaluating progress toward projects. You might include roadmap review in weekly team meetings as well as check in directly with project leads. Create an environment that actively encourages project leads to share honestly and ask for help, not just report a status or expected completion date. It's also helpful for company leaders to run less regular check-ins where you look at the progress made on the roadmap as a whole, reprioritize upcoming projects and make other changes based on new information or feedback from customers. A great plan isn't helpful unless you're following through on it and you won't know how well you're doing that without regular reviews.

Stay flexible
The roadmap should feel substantial without being impossible. A balanced roadmap leaves up to a third of total work hours to be spent on bugs, fixes and backlog items. Do your best to estimate projects and expect that it will take longer than you think–it always does. It’s also better to be ambitious and err toward adding too many projects to the roadmap, not too few. A couple more projects than practical will motivate the team to ship. Too few projects can lead you into a trap of working at the speed of the schedule, slowing down momentum.

It’s also helpful to look at roadmaps as living documents that can be updated. Circumstances will change and sometimes you'll need to move a project, add a project or delay one. Just don’t change or shuffle projects too frequently or you'll risk veering away from the original direction or losing momentum.

How we set roadmaps at Linear
We work in quarterly roadmaps. Each quarter has a clear theme to focus the work and help us choose which projects to work on e.g. Q4 2020 Core User Experience.

We choose the focus by reviewing the business needs, product goals and customer feedback and then select projects that fall under that goal. We make sure to keep some breathing room in the roadmap, too. Ideally, the roadmap reflects 60-80% of the possible work and leaves room to work on issues from the backlog, fix bugs and handle unexpected needs.

We spend a couple of weeks at the beginning of each quarter creating the roadmap. There isn’t a strict process but it usually takes a couple of meetings over the course of ±2 weeks to finalize. Between meetings, we discuss feedback and ideas in Slack or over Zoom calls. Once we've settled on the projects for the quarter, we prioritize them in chronological order and assign project owners to the first set of projects. If there isn’t a clear owner, then we leave the project unassigned until closer to the start date since it's too difficult to predict who will be free or when previous projects will close.

We assign a lead to every project. They’re responsible for creating a project spec, leading project team meetings and writing the changelog post. Individual project team members create their own issues within a project though the lead is responsible for making sure the project ships.

We kick off our weekly company meeting with a roadmap review. We go through the list of projects one-by-one in chronological order and each project owner updates the team on the status. If a blocker or issue comes up, we might discuss it quickly or resolve it after the meeting.

Throughout the quarter, it's common for projects to take longer or get moved up or down in the timeline as more urgent or opportunistic work surfaces. This is expected and okay. We also don’t like putting specific release dates on individual projects. We can find an estimated completion date by viewing the graph in the project details sidebar and get a general sense of momentum from reviewing cycles and changelogs. Sometimes a due date is helpful or required, such as for launches where we have to work with external parties or when timeboxing the work helps narrow the scope. It’s easy to keep delaying a launch to tweak the homepage, for instance, but slightly nicer pixels don’t translate to added value for a customer or the company so it's better for the team to focus on product feature work instead. We have to admit, though, we had a lot of fun polishing pixels for the latest release and spent more time than we probably needed to on the Big Sur logo. It was time well spent.

Set useful goals

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

Prioritize enablers and blockers

It’s really important to learn to prioritize work well and to be able to explain clearly why you did or did not prioritize something. You don’t have unlimited resources or time, especially in the earlier stages of building a company, so you must use it well.

First, it’s helpful to think of new features as additive enablers or removing blockers. 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. Before building a feature, you should try to understand if the problem is truly preventing someone from using the product or a nice to have in their user experience. Growth at a company comes from investing your energy and effort on the right enablers and removing cirtical blockers.

Secondly, it’s important to consider how timely something is to build. There will always be more to build than you have the resources to do so. In the early stages, there are a lot of features that you will need to build eventually. 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 at completing the project or task, does it help you achieve your higher-level goals? Also figure out if there are compounding effects to building it now and how it adds complexity or costs (e.g. more customization support).

For example, we launched Linear in beta with Google Logins support only since that was the fastest way to build authentication. We then moved on to other features instead of expanding authentication options. We knew that eventually, we would have to support pure email and other login methods to bring in more users and larget customers, but it wasn't necessary to get our beta user community up and running. This lets us move faster on other features.

Scope projects down

At the early stages, it's especially important to 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. They also get you into the habit of shipping continuously, which creates quick feedback loops with customers. Smaller teams help you move faster and reduce the management and communcation 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 Cycles and Projects 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.

Building

Generate momentum

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.

Write tasks not user stories

At Linear, we don’t write user stories and think they’re an anti-pattern in product development. We write short and simple issues that describe the task in plain language instead.


The point of writing an issue is to communicate a task. It needs to be clear enough so that the assignee can perform it and also give enough context so that teammates who need to know understand what work is being done. So the goal when writing issues should be to do this as effectively and quickly as possible.


Why user stories are obsolete

User stories evolved over twenty years ago as a way to communicate what a customer wanted into product requirements that a software team could deliver. Fast forward to today and a lot of things have changed about how we build software. Customers are tech-savvy enough to articulate basic product requirements. We’ve developed standards for common features such as shopping carts, todo lists, and notifications so there is no need to explain how they should work. The best product and engineering teams understand their users deeply and are familiar with how their product should work.

User stories have become a cargo cult ritual that feels good but wastes a lot of resources and time. They’re a roundabout way to describe tasks, obscuring the work to be done. User stories are time-consuming to write and read and can silo engineers into a mechanical role where they code to the issue requirements instead of thinking about the user experience holistically at the product level. One reason user stories are complicated and difficult to scope is because they bring what should be product-level details into the task level. And frankly, they don’t match how we communicate about software in real conversations.

A better way to write issues

Write clear, simple issues that describe tasks in plain language. Write your own issues. Discuss the user experience at the product and feature level, not the task level. Instead of spending time creating user stories, spend it talking to users and thinking through features before building them.

Describe concrete tasks or problems
An issue should describe a task with a clear, defined outcome. This could be a piece of code, design, document, or action to be taken. If it’s not a task, then it doesn’t belong in the issue tracker. Maybe it’s a project idea that needs to be fleshed out in a document or conversation or a larger feature that should be broken down into smaller, tangible pieces of work.

There will be exceptions to this rule. For example, before working on a feature you’ll spend time exploring the design and technical approach. You can create placeholder issues in these instances to break down later (e.g. Explore design) or frame it as a deliverable (e.g. Write project spec).

Write clearly and directly
Write short and simple issue titles that directly state what the task is. The title should be easy to scan, since most people will read it on a list or board in the context of other issues. Descriptions should be optional–not required–and can include relevant thoughts or context as well as links to deeper discussions. Write only as much as you need to share to perform the task and communicate relevant information to the team.

When sharing a feature request or bug report, quote user feedback directly instead of summarizing it. Often, a customer describes the pain point more authentically than you could summarize it and it’s faster to copy and paste, too. Link to the customer conversation so that if more information is needed, it’s easy to get.

Write your own issues
Everyone on the team should write their own issues. It’s faster and easier for the person who understands how to do the work to write issues describing it. It also sets up your team to do a better job. When you write your own issues, it forces you to think through the problem at a deep level. This creates space to come up with even better approaches and makes it easier to spot shortcuts or missing parts in the plan. The practice also reframes how you approach work entirely. Instead of building to mark a task done or check off a list of requirements, your focus is on the product or project deliverable.

In some cases, it makes more sense to write issues for others such as when filing a bug report. This should be encouraged with the caveat that issues are written slightly differently. When writing the issue, frame it as an ask or describe the problem. Let the assignee come up with the solution and then rewrite the issue as a task.

Keep user experience discussions at the product level
Discuss the customer experience at the product level when you spec out projects and build your roadmap. Engage the full team in these conversations–designers, engineers, and customer-facing folks–so that everyone has a deep understanding of the user needs, limitations, and product requirements. Then delegate the work to project teams and expect them to deliver. They’ll understand the user experience intuitively, so you don’t need to clarify it at the task level.
✨ ProTip: How we work at Linear
We discuss a feature or project deeply before deciding on an implementation plan. The project owner writes specs and gathers feedback until we feel like we have the right approach. Only then do we start writing code. It’s not uncommon to take a couple weeks to think through a feature before building it but once we’ve come up with the right plan, it’s straight into execution mode. The project owner delegates the work, starting with individuals writing up their own issues.

Build with users

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.

Vision vs Feedback
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.

Solve the problem not the feature
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.

Build for the right users
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.

Launch and keep launching

There is a false belief 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.

For example, when we launched Linear we 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.

Build in public

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:  Startups Write Changelogs 

More from  Linear  Light Bulb