We don't want a heavyweight ritual — how long does a session actually take?

As long as the problem needs and no longer. Projan facilitates rather than pads: it asks the questions that matter for the work in front of you and stops once the team has agreed. A tight change is a few minutes of back-and-forth, not a booked hour.

When we export, what shows up in Linear?

Issues, grouped under a Linear project. Each issue carries the scope and the acceptance the team settled on in the session, written into the description rather than left implied.

Do blocking relationships come across, or do we wire those up by hand afterwards?

They come across. Where the plan says one piece of work blocks another, Projan creates the native blocking/blocked relationship in Linear, so the order is on the board without anyone re-entering it.

Can Projan read an existing Linear issue or project as a starting point?

Yes. Paste the URL of a Linear issue or project into a session and Projan pulls it in as context, so planning extends what already exists instead of restating it from a blank page.

Does Projan touch the issues already in our cycle?

No. It creates new issues for you to look over before they land. Your current cycle, your existing issues and their states are left exactly as they are.

Our team plans in Slack between PRs — do we have to switch to a separate app?

No. The whole facilitated session can run in Slack or Microsoft Teams through Projan's bots, and the agreed work exports to Linear from the channel. Nobody has to leave the conversation to make it real.

Is this trying to become our issue tracker?

Not at all. Linear stays the tracker and the source of truth. Projan only handles the deciding that happens before an issue exists, then hands the result over.

We move fast in Linear — can Projan add rigour to planning without slowing the cycle down?

Teams pick Linear because it's fast and low-ceremony, which is also why planning sometimes gets skipped — and reappears as mid-cycle rework when scope turns out to be fuzzy. Projan adds the rigour without the drag. It runs a short, sharp facilitated conversation, challenges the soft assumptions, and exports the agreed work straight into Linear as issues under a project, with blocking relationships linked natively. You get the discipline of proper planning at the speed Linear teams expect — the thinking happens once, up front, instead of three days into the cycle.

Friday standup, mid-cycle. Someone’s halfway through the rate-limiting work and has just realised the limiter needs a config flag nobody scoped — which means a migration, which means the thing it was meant to unblock now slips a cycle. The work got picked up fast; that’s the whole point of the team. The catch is that the thinking which would have spotted the flag happened here, at standup, three days too late.

Speed has a hidden tax

A fast Linear team optimises for getting into the work. Less ceremony, less waiting, issues created and pulled the same hour. Most of the time that’s the right call. The tax lands on the changes where the scope only looked obvious — the ones where “add rate limiting” quietly contains a config decision, a backfill, a question about what happens to in-flight requests. None of that surfaces when an issue is written in thirty seconds. It surfaces mid-cycle, as rework, which is the most expensive place to find it.

The answer isn’t more process. It’s doing the thinking once, before the issue exists, and doing it fast.

A tighter loop, not a longer one

Take the rate-limiting change. Instead of one engineer typing three issues from a half-formed mental model, the team runs a short Projan session.

Projan facilitates. It asks what the limit is actually protecting — the database, an upstream API, cost — because the answer changes the design. It asks what happens when a client hits the limit: hard 429, queue, or degrade. Someone says “we’ll just use a token bucket” and Projan presses on where the bucket state lives, because in-memory means it resets on every deploy, and that’s a separate piece of work. The config flag surfaces here, in the session, not at Friday standup.

A few minutes later there’s an agreement. Projan exports it:

What the team agreed	What lands in Linear
”Rate-limit the public API with a token bucket”	An issue under a project, scope and acceptance in the description
”Bucket state needs shared storage”	A separate issue, marked as blocking the limiter
”Add the config flag and migration first”	An issue, linked as blocking the storage work
”429 with Retry-After, not a queue”	Written into the limiter issue’s acceptance, not left to guess

The cycle gets clean, ordered issues. The argument that produced them happened up front, once.

What lands in Linear

To be precise about it: Projan exports issues, grouped under a project. Each issue carries the scope and acceptance the session agreed. Where the plan establishes that one issue blocks another, Projan creates the native blocking relationship in Linear — the same blocking/blocked links you’d otherwise wire up by hand — so the order of work is real on the board, not just buried in a description. It reads the other way too: drop a Linear issue or project URL into a session and Projan pulls it in as grounding.

Plan in Slack or Teams, ship in Linear

The session doesn’t need a new home. Projan’s Slack and Microsoft Teams bots run the whole facilitated conversation in-channel — the questions, the pushback, the moment the team lands on the token-bucket decision. When it’s agreed, the issues export to Linear from there. A team that plans in Slack between PRs never breaks stride: the deciding stays in the channel, the structured output goes to the tracker.

Setting it up

Connect Linear once under Integrations → Linear with OAuth, pick the team and project to export into, run a session, and hit Export to Linear — you see the issues and their blocking links before a single one is created. Because the same agreed plan can target Jira, Notion or ClickUp just as easily, wiring up Linear never locks you to it.

Linear stays your source of truth

Projan isn’t a second tracker and has no ambition to be one. Linear remains where issues live, where cycles run, where the team sees its work. Projan handles the part that happens before an issue exists — the quick, rigorous deciding — and then gets out of the way. The board stays yours; it just fills up with work that was genuinely thought through.