Build Process

03

How We Start Working On A New Issue

How we turn a client request or a milestone task into a clear, ready-to-work issue in Linear.

Tasks are the small bricks that move a milestone forward.

They live in Linear as issues and can be bugs, new features, tweaks, or small experiments.

Our goal is to complete task creation and (if it’s a bug resolution) update the within 48 hours of their request (long term goal of 24 hours).

Below is how we’ll do it.

Click here for the diagram flow with all the steps

1. Strategist creates the issue

After a client call, Loom, or written request, the strategist is the one who creates the issue in Linear.

They:

  • Use the template to capture the key details from the client.
  • Link the issue to the right milestone whenever possible.

The template helps us make sure we do not forget important context that the dev will need.

2. Strategist sets the priority

The strategist then sets a Priority (Urgent, High, Medium, Low) using the rules in
How We Estimate and Prioritize Tasks.

3. Strategist assigns the task

If the task is estimated to be large (16 points) it will be assigned to the Solution Engineer. Otherwise, it will get assigned to the dev assigned to the project.

4. Dev checks if we have enough information

Whoever receives the issue first (Dev or Solution Engineer) must check:

Do we have enough information to start scoping this?

If the answer is no:

  • They’ll ask the strategist or the client for the missing details.
  • Once new info arrives, they’ll check again.

We loop on this step until the assignee is confident that:

  • the problem is clear
  • the expected outcome is clear
  • there is enough context to size the work

5. Dev does scoping and research

When the answer is yes, we move to scoping.

This is done by the dev, or by the Solution Engineer if the task is large.

This phase includes:

  1. Scoping
    • Break down what needs to happen technically.
    • Decide which parts are needed and which can wait.
  2. Research
    • Look at edge cases, integrations, and constraints.
    • Check if we need new tools, APIs, or changes to existing flows.

The goal of this phase is to turn request into a clear plan.

6. Dev creates subtasks, estimates, and due date

Once scoping and research are done, the assignee:

  • Creates subtasks
    • Splits the work into smaller issues or checklist items.
    • Makes sure each subtask is clear and actionable.
  • Provides an estimate
    • Adds points in Linear based on the estimates table.
    • For large tasks, this may mean estimating each subtask.
  • Estimates a Due Date (delivery date)
    This will help us manage expectations with our client

Only after these steps are done can the issue be considered ready to start.

Important:
The issue can move to "In Progress" only after scoping is done
and we have estimates and a realistic due date.

7. Dev updates the strategist

The assignee will:
- Share the plan, the estimate, and the estimated due date.
- Flag any risks or assumptions.

8. Strategist updates the client (if needed)

If the task is a bug resolution, the strategist will update the client as soon as we have clarity on what the bug is about and when it will be fixed.

The update should:

1. Confirms that we understood their request.
2. Share the high level steps we will take.
3. Give a clear time window for delivery or next update.

Strategist can use the below template to update the client


Hey [Name], just wanted to provide an update on what we discussed [provide details] Here is what we will do
  • What you asked for: [One line]
  • What we have done so far will do: [investigation, research, testing,…]
  • What we still need to do: [hurdles, next steps, extra info needed from them]
  • When to expect the next update: [Estimatedtime window]

If we follow this flow, every new task starts from a clear request, gets scoped properly, and moves to "In Progress" only when we actually know what we are doing.