# Beyond Issues: 4 Linear Features for Managing Projects More Effectively

# Beyond Issues: 4 Linear Features for Managing Projects More Effectively

When you first start using Linear, it's easy to think of it primarily as a place to create and track issues.

Create an issue. Assign it. Move it to *In Progress*. Mark it as *Done*.

That works well when the scope is small.

But as the work grows, a flat list of issues isn't always enough. Some work belongs to a larger project. Projects have meaningful stages. And sometimes, what looks like a single issue actually requires several steps before it can be considered done.

Linear has a few features that can help you organize all of this without losing sight of the actual work.

A quick note: I'm not affiliated with Linear. I've simply been using it across my last few jobs, including my current one. Along the way, I've been getting more familiar with both Linear and some of the project management concepts behind how work is organized.

Here are four features I've found particularly useful.

## 1\. Projects: Group work around a larger goal

Not every issue should live independently.

Sometimes, a collection of issues contributes to a larger outcome: launching a mobile app, redesigning an onboarding experience, or introducing a new authentication system.

That's where **Projects** come in.

A project gives related work a shared home and lets you track the larger outcome instead of looking at every issue individually.

For example:

**Project: Launch Mobile App**

*   Build authentication
    
*   Create onboarding experience
    
*   Implement navigation
    
*   Add user settings
    
*   Prepare app for release
    

Instead of only asking, *"Which issues are done?"*, you can also ask:

*"How is the project progressing?"*

## 2\. Milestones: Break a project into meaningful stages

A project can still contain dozens—or hundreds—of issues.

Milestones give you another level of organization by breaking the project into meaningful stages.

For our *Launch Mobile App* project, we could have:

**Milestone 1: Authentication**

**Milestone 2: Core Experience**

**Milestone 3: Beta Testing**

**Milestone 4: Public Launch**

Issues can then be associated with the milestone they contribute to.

This makes it easier to understand not only how much work remains, but **where you are in the journey toward completing the project**.

Instead of treating the entire project as one large block of work, milestones give the team smaller targets to work toward.

## 3\. Parent and sub-issues: Break complex issues into actionable work

Sometimes an issue isn't really an issue.

It's a small project hiding inside one.

Imagine creating an issue called:

**Implement user authentication**

At first, that might sound like a reasonable unit of work.

But then you start thinking about what "done" actually requires:

*   Create the login flow
    
*   Implement sign-up
    
*   Add password reset
    
*   Handle session expiration
    
*   Add authentication tests
    

At that point, keeping everything inside one issue makes it difficult to see what's actually complete and what still needs work.

Instead, you can use the original issue as a **parent issue** and break the implementation into **sub-issues**.

The parent captures the larger piece of work.

The sub-issues capture the individual steps required to complete it.

This gives you something similar to an **Epic-style structure** without needing to turn every multi-step piece of work into its own project.

It's particularly useful when something is too large for one issue but too small to justify creating an entire project around it.

## 4\. Views: Look at the same work from different perspectives

Organizing your work is only part of the problem.

Sometimes you simply need a better way to look at it.

That's where **Views** become useful.

You can filter your issues and save views based on the information you regularly care about.

For example:

*   Issues assigned to me
    
*   Issues currently blocked
    
*   Bugs
    
*   Work ready for development
    
*   High-priority issues
    
*   Issues belonging to a particular project
    

The underlying issues haven't changed.

You're simply creating different windows into the same work.

This becomes particularly useful as the number of issues grows. Instead of repeatedly searching or applying the same filters, you can create a view for the questions you regularly need to answer.

## Different tools for different levels of work

The useful part isn't any individual feature. It's how they work together.

**Projects** group work around a larger outcome.

**Milestones** divide that outcome into meaningful stages.

**Parent and sub-issues** break complex pieces of work into actionable steps.

**Views** let you look at all that work from the perspective you need.

You don't need all of these for every project.

But as the work gets more complex, having different levels of organization can make it much easier to understand both the bigger picture and what needs to happen next.

Sometimes an issue is enough.

And sometimes you need to zoom out.
