Merit · Product · Internal Explainer

Linear, explained

On 6 August, Fred approved moving Merit's new-world tracking to Linear, then asked to actually see it: he has never used it and wanted to know what it looks like and how people actually work in it, because as he put it, "I hear it's good, and that's what matters to me" is not the same as having seen it. Everything below is the real product: real screenshots from Linear's own public demo workspace, and a screen-recorded walkthrough, not a recreation.

Owner: Brian Arfi Faridhi · Last updated 7 Aug 2026 · Audience: Fred Barry, Tamer Labna

00See it live, before reading anything else

Linear runs a real, public demo workspace. No signup, no sales call. This is the single best way to answer "what does it look like."

No signup needed
linear.app/demo →
A real, live Linear workspace anyone can click through. Changes are local to your browser and reset on refresh; it does not show workspace settings or SLAs. Everything else is the genuine product.

A recorded walkthrough of the actual product

Screen-recorded directly from linear.app/demo on 7 August: open an issue, check Triage, open the command menu, look at the active cycle, look at Initiatives. About 20 seconds, real interactions, no narration added.

Recorded from linear.app/demo, 7 Aug 2026. Requires a Chromium-based browser (Edge, Chrome) to play the .webm file.

01In one minute

If you only read one section, read this one.

Linear is an issue tracker, the same category as Jira. The difference is three design choices Jira treats as optional and Linear treats as the whole product: work is planned in short, repeating cycles instead of open-ended backlogs; the entire interface is built to be driven from the keyboard, so filing or moving an issue takes seconds, not a form; and AI is a workspace member you assign issues to, not a chatbot bolted onto the side.

Those three choices are what Tamer and Fred were weighing against Merit's existing Jira, and they are why the decision came down to more than price.

Plan

Initiatives and Projects set direction and hold the target dates. This is the roadmap layer.

Do

Cycles and Issues are where work actually happens, one short iteration at a time.

See

Insights and saved Views show how each team is trending without anyone building a report.

What changed since the first version of this document

The first draft used recreated mockups because a live screenshot tool was not available at the time. It has since become available: every screen from here on is a real capture from Linear's own public demo workspace, checked by opening the image before using it, not generated. Section 06 (Linear Asks) and section 07 (Insights) are Business-tier features not exposed in the anonymous demo, so those two are described from Linear's published documentation rather than shown - flagged at each one rather than faked.

Tier badges

Some of what follows needs Linear Business, not Basic. Merit needs Business regardless, because Basic caps a workspace at 5 teams and Merit's structure needs more - see the companion cost document, section 1. Badges below are for feature awareness, not a reason to reconsider the tier.

02The building blocks

Four objects, nested inside each other. Everything else in Linear is a view onto these.

Issue

The single unit of work, same role as a Jira issue. Can be broken into sub-issues for anything too big to finish in one pass.

Project

A scoped body of work with a target date and a lead, and its own health status. Merit equivalent: "Seller Portal CSV bulk upload" or "Al Fursan National Day push."

Initiative

Groups several projects toward one outcome, with an owner and a target. Merit equivalent: "B2C SuperApp" or "Marketplace" as a whole.

Cycle

A short, repeating time-box a team runs on autopilot, functionally Merit's existing sprint rhythm. Progress and scope are tracked automatically, cycle over cycle.

What a cycle actually looks like

Linear demo workspace, Engineering team, current Cycle 70: issue list on the left grouped by status, cycle progress panel on the right showing scope, started and completed counts, a burndown-style chart, and per-assignee breakdown.
Real capture, linear.app/demo: Cycles > Current. Issues on the left, cycle health (scope / started / completed, a progress chart, per-person breakdown) on the right. This is the view a lead checks daily.

Initiatives and Projects, as real tables

Linear demo workspace Initiatives list: name, priority, owner, target date, number of projects, and health status for each initiative.
Real capture: Initiatives: name, owner, target, and how many projects sit under each.
Linear demo workspace Projects list with a health summary panel open on the right showing counts of no-update and update-missing projects.
Real capture: Projects: every active project, health at a glance, a panel Fred would actually use.

How one issue moves

anyone
Filed
Typed, forwarded from Slack, or synced from an integration.
→
a lead
Triage
Reviewed once, given a team, a priority, a cycle. See section 03.
→
the team
In the cycle
Worked, moved across states, linked to a branch and a PR.
→
automatic
Done
Closes itself when the linked pull request merges.

03Triage: how work gets in

Nothing lands on a team's board silently. Every new issue, wherever it came from, waits in one queue until a lead looks at it.

A lead reviews each item in Triage and either assigns it a team, a priority and a cycle, or declines it. This is the closest Linear equivalent to a Jira Service Desk intake queue, and it is the one place in this document worth being precise about a limit: Triage is an intake filter, not a service-desk product. It has no SLAs, no customer-facing ticket portal, and no approval chains. It does not retire the JSM question already open in the Tintash recommendation (section 6.2 there); it narrows it.

Linear demo workspace Triage view, empty state reading Nothing to triage with a Create triage issue button.
Real capture: Triage, Engineering team. This demo happens to have nothing waiting right now; when something lands here it appears as a row with a source, a suggested team, and Accept / Decline actions, same list layout as Issues.

04Views and the command menu

The two habits that make Linear feel fast to the people who use it daily.

Views

A saved, filtered list or board, for example "My issues" or "This cycle", shareable across a team. Same underlying idea as a Jira filter, applied to boards as well as lists.

Command menu

Ctrl/Cmd + K opens a searchable palette for any action: file an issue, jump to a project, reassign, change a status. Nothing requires a full page load or a form.

Linear command menu opened with Ctrl+K, showing quick actions: Create new project, Create new issue, Create issue in fullscreen, Create new issue from template, Create new label, Create new document.
Real capture: Ctrl+K from anywhere in the app. This is the single biggest reason engineers who have used both describe Linear as faster than Jira.

05AI agents available broadly

The feature that carried most of the argument in the 6 August meeting. Worth being precise about what is confirmed and what is not.

In Linear, an AI agent is a full workspace member: it can be assigned to an issue, added to a project, or @-mentioned in a comment, the same way a person would be. A human stays the primary assignee and accountable owner; the agent works alongside them and posts a plain-language summary of what it did, with the option to open its full reasoning. Third-party agents that plug in this way today, per Linear's published agents page: Cursor (drafts a branch from an issue), OpenAI Codex (takes on a full coding task), Devin (scopes an issue, drafts the PR), ChatPRD (writes requirements), Sentry/Seer (root-cause analysis on a bug), plus Factory, Charlie, Ranger and Tembo.

Linear demo workspace issue detail view: title Account balance shows zero until refresh, description, activity log, and a Properties panel on the right with status, priority, Assign, Set estimate, and Cycle fields.
Real capture: an issue's detail view. The Assign field under Properties is where a person or an agent goes; this anonymous public demo has no third-party agent connected, so it is not shown assigned here. Connecting one requires linking a real Cursor/Devin/Codex account, which only happens inside an actual Merit workspace.
What is not yet confirmed

Linear's pricing page does not list third-party agent assignment as a Business-only line item, so it reads as available on paid tiers generally - but this was not stated with full confidence in earlier drafts of this document and should not be repeated as certain until confirmed live, either in a Merit trial workspace or with Linear sales. What is confirmed and tier-independent: the AI-training data-exposure argument in the Tintash recommendation, section 4.

06Linear Asks Business

Turns a request made in Slack into a properly structured issue, instead of leaving it as a message that scrolls away.

Someone posts a request in a Slack channel; Linear Asks turns it into an issue, routed toward Triage rather than sitting unstructured in a thread. Confirmed Business-tier only on Linear's pricing page - not shown in the anonymous public demo, which does not expose Business features. It is the feature most relevant to the open question in section 6.2 of the Tintash recommendation: once engineering leaves Jira, the native link between a Jira Service Management ticket and an engineering issue breaks.

What this does not solve

Linear Asks is intake, not a service desk. No SLAs, no customer-facing portal, no approval workflow. It narrows the JSM gap for internal Slack-based requests; it does not replace Jira Service Management for anything customer-facing or SLA-bound. That decision is still open and separate from this one.

07Insights Business

The view built for someone in Fred's seat, not a team lead's.

Built-in analytics on any stream of work: cycle velocity, how an initiative is trending against its target date, time spent in each status. Confirmed Business-tier only. Not reachable in the anonymous public demo, so no screenshot is shown here rather than approximating one - see it live in a real trial workspace once Merit has one.

08A day in the life

Three roles, three different relationships with the same product. This is the "journey" asked for in the meeting.

PM - Brian's role

  1. Open Triage first
    Clear anything waiting (from Slack via Asks, from teammates, from the Jira sync during the transition period) into the right team and cycle.
  2. Check Insights on active initiatives
    A trend line per initiative, not a status meeting, to see what is slipping before it is raised.
  3. File issues from wherever the conversation is happening
    Cmd+K during a call or a Slack thread, no context switch to a separate tab.
  4. Review the cycle board before it closes
    What did not make it carries over or gets explicitly dropped, not silently rolled.

Engineer - a Tintash developer's role

  1. Start from "My issues"
    A personal, always-current view of what is assigned, ranked by the team's priority.
  2. Branch straight from the issue
    The Git integration (Merit's Jira already has this live with GitLab, per the Tintash cost analysis) creates a correctly named branch and links it automatically.
  3. Status moves itself
    Opening the PR moves the issue to "In Review"; merging it closes the issue. No manual status update.
  4. Hand off to an agent where it makes sense
    Assign a bug straight to Sentry/Seer for root-cause first, or @-mention Cursor for a mechanical fix, before picking it up personally.

Admin / Ops - Fred and Tamer's role

  1. Own the Triage queue as a lead
    Nothing reaches a team without a first pass: the guardrail against scope creeping in silently.
  2. Read Insights weekly
    Velocity and blockers across every team Merit runs, in one place, without asking for a report.
  3. Run the Jira importer during migration
    Workspace settings, not engineering work. See section 09 for exactly what that screen does.
  4. Manage who is on Linear at all
    Seats added as people onboard, which is the whole basis of the ramp costed in the companion sizing document.

09Coming from Jira

What actually happens when Merit's 11 Tintash projects move, mechanically.

  1. Settings → Workspace → Import/Export
    Select Jira as the source.
  2. Choose what to bring in
    Pick issues and map each Jira project to a Linear team.
  3. Review the fetched data
    A preview before anything is committed.
  4. Map users
    Match Jira accounts to Linear workspace members.
  5. Confirm and finish
    Linear also offers a two-way sync during a transition window, for teams not cutting over all at once, relevant given Fred does not expect every team (Legal, by his own example) to move.
What Merit already knows about its own migration

From the Tintash recommendation: Linear's importer handles 7 of Merit's 11 projects cleanly, 97% of issue volume, at no extra tooling cost. The remaining 4 are discovery-type boards with no clean Linear equivalent and need manual rework. Exact fidelity of custom fields and workflows for those 4 is not published in general terms by Linear and should be checked against Merit's actual field list during the trial import, already logged as an open item, not new here.

10Glossary: Jira → Linear

For anyone translating from what they already know.

Epic
Initiative, or a Project, depending on how large the scope actually is.
Sprint
Cycle. Same rhythm, lighter to set up.
Backlog
Backlog. Same word, same idea.
Board
A team's active Cycle view, or any saved View.
Jira Service Management ticket
No direct equivalent. Closest is Triage plus Linear Asks: see section 03 and section 06 for what that does and does not cover.
Component
Project or Label, depending on how the team already uses it.
JQL filter
A saved View. Built by picking filters, not writing a query language.
Story points
Estimate. Set on the issue, optional per team.
Team (Linear-specific)
Not a Jira concept directly - closer to a project's permission and workflow boundary. Basic caps a workspace at 5; Merit needs Business. See the cost sizing document, section 1.