How Product Work Moves

How the Product Team Works explains our responsibilities and operating principles. This page explains how an individual piece of work moves through the Product system.

The workflow is:

Intake → triage → ready → planned → in progress → testing → done → learning

Not every signal completes the entire journey. Some questions are answered without creating delivery work. Some requests need more evidence. Some ideas are deliberately deferred or rejected.

The important rule is that every meaningful signal receives a visible outcome.

How work enters Product

We create a Linear issue when someone may need to answer, decide, or act.

We begin with the type that best describes the work:

A Request is not a substitute for a Feature. If the proposed work changes what the product can do, it is a Feature.

The person reporting an issue does not need to design the solution. They should include, when available:

• what they observed,
• the affected user or workflow,
• supporting evidence,
• expected impact,
• why the timing matters.

Normal Feature and Bug validation stays on the delivery issue. We create a separate Testing issue only when the test work is independently owned or produces its own output.

Triage

Product reviews incoming work every business day. Urgent work is reviewed immediately.

Triage gives each issue one visible outcome:

• Backlog
• Ready for cycle
• Needs Evidence
• Documentation or Education
• Deferred
• Cancelled
• Already Covered or Duplicate
• Urgent Response

Triage is a decision queue. Backlog is not a commitment.

An issue can be valid and still not be worth doing now. Moving something to Backlog means we understand it and may reconsider it later. It does not promise delivery.

Prioritization

Product recommends priority using customer, product, commercial, and technical evidence.

We look at:

• the number of affected customers or users,
• the severity and frequency of the problem,
• product usage and behavioral evidence,
• revenue, retention, and strategic impact,
• technical risk and dependencies,
• the cost of waiting,
• the opportunity cost of choosing the work.

Template scores are input, not final priority. A high score also does not automatically mean that the work is ready to begin.

Urgent is reserved for immediate material outages or verified customer, data, security, privacy, compliance, revenue, or contractual risks.

When urgent work enters, we record:

• the impact,
• the owner,
• the next action,
• the next update time,
• the work it displaces.

Urgency changes the order of work. It does not create additional capacity.

Definition of Ready

An issue is Ready when it has:

• a clear problem, decision, or desired outcome,
• an owner and next action,
• an understood impact and priority,
• enough evidence for the level of risk,
• scope, acceptance criteria, or a clear decision question,
• known dependencies,
• an observable completion condition.

To enter the current cycle, it also needs credible capacity and scope small enough to complete.

Add a due date only when a real deadline exists. An optional field in a template does not make the underlying context optional for Ready.

Urgent work may begin with incomplete context. We complete the record after the immediate risk is controlled.

Planning cycles

Product uses continuous two-week planning cycles.

A Product cycle is a planning window, not a release schedule. Engineering deployment and release mechanics remain separate.

At the start of a cycle:

• add only Ready work with a clear owner and outcome,
• put planned work in To Do,
• keep later possibilities in Backlog,
• avoid using the cycle as a wishlist.

A credible plan represents what we believe we can finish, not everything we would like to make progress on.

Work in progress

Our default rule is one primary In Progress issue per owner.

A second active issue is allowed only for:

• a named dependency,
• an urgent interruption,
• a small piece of work that unblocks someone else.

The reason and next check should be visible.

On Test is still open work. It needs a tester, a next action, and active follow-up.

The goal of a work-in-progress limit is not to keep people idle. It is to finish valuable work before creating more partially completed work.

Scope changes

To add work after a cycle has started, we record:

• why it must enter now,
• its priority and owner,
• what will be removed, deferred, or reduced,
• the effect on the cycle outcome.

Urgent work can begin immediately. The trade-off is recorded once the immediate risk is controlled.

Unfinished work does not move into the next cycle automatically. We either:

• finish it,
• split it,
• reduce its scope,
• return it to Backlog,
• reassign it,
• cancel it.

We also record why the original commitment was not completed. This helps us improve future planning instead of hiding the same problem through automatic carry-over.

Blockers

When work becomes blocked:

• add the dependency,
• explain the blocker and affected outcome,
• name the person or decision needed,
• add the next action and check date,
• notify only the relevant people.

We surface blockers when they happen. We do not wait for a meeting.

A blocked issue without an owner or next check is not being managed. It is only being observed.

Testing handoff

Before moving a Feature or Bug to On Test:

• make the output available in a named environment,
• include acceptance criteria or expected behavior,
• complete developer testing,
• assign the tester,
• attach the relevant evidence,
• state known limitations.

If testing fails, the delivery issue moves back to In Progress and the failure is recorded.

Testing is not a final approval ritual. It is part of delivery and should begin from the same expected behavior used to define the work.

Definition of Done

An issue is Done when:

• its deliverable is complete,
• acceptance or success criteria are verified,
• the right owner or reviewer confirms completion,
• relevant documentation is updated,
• affected people are informed when necessary,
• any remaining follow-up has an owner and date.

The minimum completion standard depends on the type of work:

Evidence should match the impact and risk of the work. A small internal change does not need the same proof as a customer-facing capability or a high-risk data change.

Decisions and closure

For a meaningful Product decision, we record:

• the decision and date,
• the decision owner,
• supporting evidence,
• rationale and trade-off,
• affected work,
• follow-up signal and date.

Every meaningful signal receives a visible outcome:

• Accepted
• Needs Evidence
• Documentation or Education
• Deferred
• Rejected
• Already Covered or Merged

This prevents customer feedback, internal questions, and Product decisions from disappearing without an answer.

Learning after launch

Shipping closes delivery. It does not prove that the work created value.

For a meaningful launch, we define:

• what success should look like,
• which signal or metric we will review,
• who owns the follow-up,
• when the review will happen.

The result may tell us to continue, improve, simplify, expand, or stop.

Done closes delivery. Measurement and learning close the Product loop.