What does Projan put into our Asana project — tasks, or whole sections?

Tasks, and subtasks under them where the work breaks down further. Each lands in the project you choose, with the acceptance criteria from the discussion written into the task and an owner attached. There's no separate document or canvas pushed to Asana — Asana gets the actionable work, nothing more.

We sequence a launch tightly — does Projan carry the order across, or do we re-link it by hand?

It carries across. Where the plan establishes that one task can't start until another finishes, Projan marks them as dependent in Asana using native task dependencies, so the order shows up on the timeline rather than living in someone's head.

Can Projan read an existing Asana task into a session, so we plan around work already on the board?

Yes. Paste an Asana task URL, or give its task ID, and Projan pulls that task in as context for the conversation. Useful when a launch builds on a workstream that's already underway and you don't want to re-describe it from scratch.

Marketing, product and ops all live in different Asana projects. Which one does the work land in?

The one you point the export at. You connect Asana once and choose the destination project when you export. If a launch spans projects you'd typically run the alignment session as one conversation and export the agreed tasks where they belong, rather than splitting the discussion three ways.

Do all three teams have to be in the Projan web app for the session to work?

No. Projan's Slack and Microsoft Teams bots run the facilitated session in a channel everyone's already in. The conversation happens where the teams talk; only the agreed tasks land in Asana afterwards.

Does Projan touch the Asana tasks we already have once it's exported?

No. It creates new tasks from the agreed plan. It doesn't reorganise, reassign or rewrite tasks already in your project — what was there before stays as you left it.

Our launches run on Asana across three teams — can Projan get everyone agreeing before the work starts?

Asana shines at coordinating work across functions — and cross-functional work is exactly where planning goes wrong, because marketing, product and ops each assume a different plan. Projan does the alignment before the tasks exist. It facilitates one conversation that gets all three teams to the same agreement, challenges the dependencies people are hand-waving past, and exports the result into Asana as tasks within a project, each with acceptance criteria and the dependencies marked. The launch starts from a plan everyone actually shares, not three overlapping ones discovered halfway through.

The kickoff meeting goes well. Marketing leaves certain the announcement lands the week of the 14th. Product leaves certain the feature flag flips the week after, once the beta cohort’s had a proper run. Ops leaves certain nothing ships until the support macros and the refund policy are signed off. Three teams, one launch, and a calendar that quietly contradicts itself — except nobody’s holding all three calendars at once, so nobody notices until the announcement’s already drafted against a date the feature won’t be ready for.

Three teams, three different plans

A launch isn’t one plan. It’s marketing’s plan, product’s plan and ops’ plan, each internally coherent and each assuming the other two will fall into line on its own timeline. They rarely conflict on the big things. They conflict on the seams — who needs what from whom, and by when. The announcement assumes the feature; the feature assumes the beta; the beta assumes support is ready to field the questions it throws up. Pull one thread and the order of the whole thing changes, but each team only sees its own thread.

Asana is very good at holding all of that once it’s decided. It’s a coordination tool — that’s the point of it. What it can’t do is conduct the argument that works out the order in the first place. By the time three teams are filling in their own sections of an Asana project, they’ve each already decided what the launch looks like, privately, and the project just records three plans sitting next to each other.

One conversation everyone’s in

Take that same launch. Instead of three teams scoping three projects, they open one Projan session together — in the channel they share, or in the web app — and Projan facilitates.

It starts with the dependency everyone’s been polite about: does the announcement go out before or after the flag flips? Marketing says before, to build anticipation. Ops points out that early announcement means support fields questions about a feature half the users can’t see yet. Projan doesn’t pick a side — it makes the trade-off explicit and asks the teams to agree one. They land on announcing the day the flag flips, not before.

Then it pushes on the soft spots. “The beta finishes the week of the 7th” — Projan asks what finishes means, and whether the go/no-go decision has an owner and a date, because right now it has neither. Ops mentions the refund policy needs legal sign-off; Projan asks whether that blocks launch or runs alongside, and the team agrees it blocks. That’s a dependency nobody had written down.

By the end there’s one plan, and every team was in the room when each piece of it was decided. The announcement task depends on the flag-flip task. The flag-flip depends on the beta go/no-go. The go/no-go has an owner and a date. The refund sign-off blocks the lot. Nobody discovers any of this in week three.

What lands in Asana

When the team exports, the agreement becomes work in your Asana project:

What the teams agreed	What Projan creates in Asana
”Announce the day the flag flips”	A task with the date and the agreed reasoning, owned by marketing
”Beta go/no-go decision, owned, dated”	A task with acceptance criteria drawn from the discussion
Breaking the go/no-go into its checks	Subtasks under it for the individual sign-offs
”Refund policy must clear legal first”	A task marked as a dependency the launch can’t start without
”Flag flips only after go/no-go passes”	A native Asana dependency between the two tasks

Tasks and subtasks, owners attached, acceptance criteria written in, and the order marked using Asana’s own task dependencies so it shows on the timeline. That’s deliberately all of it — Projan doesn’t push a separate brief or document into Asana. Asana gets the actionable launch, structured the way it agreed it.

Align in Slack or Teams, run it in Asana

The teams don’t have to leave the room they already work in to do any of this. Projan’s Slack and Microsoft Teams bots run the whole facilitated session in-channel — the dependency questions, the disagreement about the announcement date, the moment they land on a phased order. Marketing, product and ops thrash it out where they already talk to each other, and the agreed tasks land in Asana from there. The alignment happens in the channel; the work appears on the board.

Setting it up

Connect Asana once under Integrations → Asana with your Asana account, then choose the project a session should export into. Run the alignment conversation — in Slack, in Teams, or in the web workspace — and when the teams have agreed, hit Export to Asana. Tasks and subtasks appear in the chosen project, owners attached and dependencies marked. The same agreed plan can target Jira, Linear or ClickUp instead, so wiring up Asana never locks the launch into one tool.

Asana coordinates; Projan aligns

Keep Asana exactly where it is. It’s the right place to run a launch once three teams agree what the launch is. Projan isn’t trying to coordinate the work — Asana does that better. It’s doing the bit that comes first: getting marketing, product and ops to one shared plan, with the awkward dependencies surfaced and settled, before any of it becomes tasks. Asana holds the agreement. Projan is how you reach it.