Does Projan write straight to Jira, or just suggest tickets?

It writes to Jira, but only once you approve. Projan drafts the epics and stories from your agreed plan and shows them to you; nothing is created in your project until you confirm the export.

What actually lands in Jira when we export?

Epics, stories, tasks and sub-tasks, with acceptance criteria written into each story from the discussion and the decision rationale kept in the descriptions. Where the plan says one piece of work blocks another, Projan links the issues natively.

Does Projan change the Jira issues we already have?

No. Projan creates new issues for you to review; it doesn't edit or reorganise your existing backlog.

We rely on Jira dependencies — do those survive?

Yes. When the plan establishes that one item depends on another, Projan creates native Jira issue links so the order of work is visible to the team in Jira itself.

Can Projan read a Jira issue we already have, going the other way?

Yes. Paste a Jira issue key or URL into a session and Projan pulls it in as context, so planning builds on work that already exists rather than starting from a blank page.

Does the team have to plan inside Projan's app?

No — that's the point. The facilitated session runs through Projan's Slack bot, its Microsoft Teams bot, or the web workspace, and exports to Jira from any of them.

Is Projan a replacement for Jira?

No. Projan is the layer above Jira that decides what belongs in the backlog and why. Jira stays your system of record for execution.

We already run delivery in Jira — so what does Projan actually add?

Jira is excellent at tracking work and silent about how that work got decided. Projan fills the silence. It runs the messy part — the debate about what to build, for whom, and what 'done' actually means — as a facilitated conversation in Slack, Microsoft Teams or its own workspace, then writes the agreed epics, stories and acceptance criteria into your Jira project with the reasoning attached. You review everything before a single issue is created. The result is a backlog whose items carry the argument that produced them, instead of a vague epic a PM wrote up at 9pm.

A sprint review is where a vague epic finally shows its teeth. Someone opens “Improve onboarding,” and three people discover they were building three different things. The acceptance criteria were never written down; the trade-offs that were argued about in a call last month live in nobody’s memory. Jira recorded that the work existed. It never recorded the thinking that should have shaped it — because Jira was never asked to.

The part Jira was never meant to do

Jira starts at the point where you already know what to build. The deciding — the bit where a team works out the actual problem, who it’s for, what’s in and out of scope, and what “done” means — happens somewhere else entirely: a call, a thread, a whiteboard that gets wiped. That deciding is lossy by default. By the time it reaches a ticket, the why has fallen out and an engineer is left reading two bullet points and guessing.

Projan owns that earlier step. It runs the conversation properly, then hands Jira a result that’s already been agreed.

What this looks like on a Tuesday

Take that same onboarding request. Instead of a PM quietly turning it into an epic and a handful of half-scoped stories, the team opens a Projan session — in the Slack channel they’re already in, or in Teams, or in the web app.

Projan facilitates. It asks what problem onboarding is actually failing to solve, and for which users. An engineer points out that self-serve setup depends on the new auth work; the PM wanted self-serve first. That tension surfaces in the session, and they agree to phase it rather than discovering the conflict two sprints in. Projan holds the thread of every decision as it’s made.

Then it exports. What was a conversation becomes:

What the team agreed	What Projan creates in Jira
”Cut time-to-first-value for new workspaces”	An epic, with the reasoning in the description
Each slice of agreed work	A story, acceptance criteria drawn from what was actually said
”Auth ships before self-serve”	A native issue link, so the dependency is visible on the board
”SSO is explicitly out for this phase”	An out-of-scope note kept against the epic

Minutes, not an evening. And every ticket traces back to the conversation that justified it.

Run it from where you already argue

The deciding doesn’t move into a new tool. Projan’s Slack and Microsoft Teams bots run the whole facilitated session in-channel — the questions, the disagreement, the agreement — and export to Jira from there. A team that lives in Slack never opens anything else; the web workspace is there when someone wants a quieter canvas. The multiplayer part stays in the conversation. Jira gets the clean output.

Setting it up

Connect Jira once under Integrations → Jira (OAuth with your Atlassian account), choose the project to export into, run a session, and hit Export to Jira — reviewing everything before it’s created. The same session can just as easily target Linear, Notion or ClickUp, so committing to Projan never means committing away from Jira.

It doesn’t replace Jira — it does the bit before Jira

Keep Jira exactly as it is. Projan isn’t competing for your board; it’s making sure what lands there is something your team actually decided, with the argument intact. Jira remains the record of execution. Projan is the record of the decision that came first.