A Linear "Issue" Is Not a "Problem" — A 3-Layer Structure That Separates Problems and Tasks

TL;DR

If you throw “X isn’t done yet”-style problems into Linear issues, you end up in Backlog hell. Linear’s “issue” is not the Japanese sense of “イシュー (problem / question)” — it’s a “unit of work that can be marked done.” Push problems into Project + Document, keep tasks in Issues, and once you run that 3-layer structure, the workflow finally starts moving.

A Linear “Issue” Is Not a Problem

In Kazuto Ataka’s Issue Driven, “issue” means “the question worth solving.” A Linear “issue,” by contrast, means “a unit of work to be tracked.” Bug fixes, feature work, configuration changes — anything whose done/not-done state can be determined is what Linear’s issue refers to.

If you start using Linear without noticing this conceptual collision, you end up with things like:

• “Overcome ADHD”
• “We have a serious lack of high-quality input”
• “Haven’t established a methodology for high-productivity development”

These are problems, not issues. They have no completion criterion, so the day you set their status to “Done” never comes. Result: everything piles up in Backlog, a pile of Canceled accumulates, and the Todo → In Progress → Done workflow is left abandoned, never running even once.

A 3-Layer Structure: Project + Document + Issue

If you want to manage both problems and tasks inside Linear, the following structure aligns most closely with Linear’s design philosophy.

graph TD
    P[Project<br/>Problem theme] --> D[Document<br/>Background, hypothesis, notes]
    P --> I1[Issue<br/>Concrete action starting with a verb]
    P --> I2[Issue<br/>Concrete action starting with a verb]
    P --> I3[Issue<br/>Concrete action starting with a verb]

Rule: every issue title must start with a verb.

• Bad: “Overcome ADHD”
• Good: “Read chapter 1 of the ADHD book XX and take notes”

Done this way, “is it done?” becomes self-evident.

How to Sort Through Existing Issues

If you already have a pile of problem-style issues, here’s how to clean up.

Step 1: Cancel the ones you no longer care about. Don’t overthink — go on instinct.

Step 2: Promote “X isn’t done yet”-style ones to Projects. Group similar themes together to create 3 to 5 Projects, and copy the contents of those issues into a Document inside each Project. Cancel or archive the original issues.

Step 3: Keep as issues only the ones you can convert into actions. Rewrite the title to start with a verb and link it to the appropriate Project. You don’t need to convert all of them — converting 3 to 5 is enough.

The granularity of Projects might look like this:

• Development productivity — tools, methodology, agent integrations
• Personal products — things I want to build
• Personal growth and learning — input, technical catch-up
• Life and health — habit improvements

A good rule of thumb is to keep at most 7 active Projects at any time. More than that and visibility breaks down.

Operational Flow

Daily (5–10 minutes)

1. From Backlog, pick at most 3 issues you can plausibly do today and move them to Todo.
2. When you start, move only one to In Progress.
3. When it’s done, move it to Done and pull the next one into In Progress.

The single most important point is keeping WIP (work in progress) at one. If you have ADHD tendencies, having multiple In Progress at once leaves all of them half-finished.

Weekly (15–20 minutes)

1. Open the Project list and skim each Project’s Document.
2. From the “candidate next moves,” pick just 1 or 2 and turn them into issues attached to the Project.
3. Set unneeded issues and Projects to Done or Archive.

This “problem review” corresponds to Ataka’s “issue first.” Once a week, return to upstream problems and derive this week’s tasks from them.

Features You Don’t Need at First

Cycle: introduce this only after the workflow (Todo → In Progress → Done) is reliably running. Adding it from the start makes the configuration itself stressful.

Label: unnecessary for now. If you must use one, #today (things to do today) is enough on its own. Combined with a Saved View, it lets you build a “today screen.”

Sub-issue: use this only when an issue won’t fit in 2 hours and needs splitting. Don’t use it to express problem hierarchy — that’s the Project’s job.

Conclusion

flowchart LR
    A[Recognize a problem] --> B[Write it in a Project]
    B --> C[Deep-dive in the Document]
    C --> D[Break into Issues<br/>starting with a verb]
    D --> E[Todo → In Progress → Done]
    E --> F[Weekly: return to the problems]
    F --> C

If you turn Linear into “a dump for problems,” it becomes no different from a memo pad. Linear’s essential value lies in running the workflow. Push problems off into Project + Document, and keep issues for “things you’ll move your hands on today” only. Just start by writing 3 verb-starting issues and moving one of them into In Progress.

That’s all.