When Projan exports to Notion, do I get a document or a list of tasks?

Both, out of the same session. The spec lands as a structured Notion page, and each work item the plan was broken into lands as a row in a Notion database. The page is the narrative; the rows are the things someone actually has to build.

Will Projan clean up the half-finished pages already cluttering our workspace?

No — it leaves your existing pages alone. It creates new pages and database entries from the conversation you just had. The old abandoned drafts stay where they are; Projan's job is to stop the next one being abandoned, not to tidy the last ten.

Can Projan start from a Notion page we've already written rather than a blank one?

Yes. Drop a Notion page or database-entry URL into a session and Projan reads it in as context, so the planning builds on what's already there instead of pretending it doesn't exist.

Which database do the work items go into, and what's in each row?

You choose the database when you export. Each work item becomes a row with its title and description filled from the discussion. If the database already has properties like status or priority, the entries arrive ready to slot into the views your team runs.

Does everyone have to be sitting in Notion while we plan?

No. The conversation runs wherever your team already talks — Projan's Slack bot, its Microsoft Teams bot, or the web workspace. Notion is the destination, not the meeting. Only what you agree gets written there.

Does Projan link the database rows together the way Notion relations do?

Not as native Notion relations. The work items land as database entries, and the sequencing and reasoning are written into the spec page's prose. If you want hard relation links between rows, you'd wire those up in Notion yourself afterwards.

Is this trying to replace Notion as our knowledge base?

No. Notion stays the source of truth. Projan runs the conversation that decides what's worth writing down, then writes the result into Notion. It's the step before the page exists — not a rival to the page.

Notion is where our team thinks — can Projan make the planning that happens in it actually decisive?

A Notion workspace fills up with documents that were started and never finished — the PRD with three headings, the 'planning' page that's really a list of links. Projan addresses the cause, not the symptom: it facilitates the planning conversation, presses on the vague parts, and the moment your team agrees, it writes a structured page for the spec and populates a database with the work items. Notion stays your single source of truth; Projan makes sure what lands in it is something the team decided together, not a draft someone abandoned on a Tuesday.

Open a team’s Notion sidebar and scroll. There’s the doc called “Q3 Planning” that stops after one heading. There’s “Referral feature — thoughts,” which is four bullets and a link to a competitor. There’s the PRD a PM began with real intent on a Tuesday and never returned to, because by Wednesday the thinking had moved into a call nobody minuted. The workspace isn’t short of pages. It’s short of pages anyone finished agreeing on.

The half-written-doc problem

People aren’t lazy about writing things down. The problem is that the document is the wrong place to do the thinking. You sit down to write the spec, hit the question of whether the referral reward is per-signup or per-conversion, and rather than resolve it — which needs other people in the room — you leave a placeholder and tab away. The page becomes a monument to a conversation that never happened. Do that across a quarter and the sidebar fills with good intentions, each stalled at the exact moment it needed someone else to weigh in.

Projan goes at the cause. It doesn’t help you type the doc faster. It runs the conversation the doc was waiting on, and writes only once that conversation has actually landed.

How a planning chat becomes a Notion page

Picture a small startup scoping a referral feature. The usual version: one person opens a page called “Referral spec,” types three headings, and is stuck on the reward mechanics inside ten minutes.

The Projan version: the team starts a session and Projan facilitates. Who’s the referral for — existing power users, or people on their way out the door? It catches that “give both sides a credit” quietly skips whether the referred user has to pay before the reward fires, and asks. A founder wants the reward on signup; an engineer calls that a fraud magnet and pushes for reward-on-first-payment. That gets settled in the session — not discovered three weeks later in a panic. Projan holds each decision as it’s made.

Then it writes, and two things land in Notion:

A structured page — the spec itself: the agreed reward model, who it serves, the fraud constraint that shaped it, and a flat “out of scope: multi-tier referrals” so nobody quietly reopens it.
A set of database entries — one row per work item. “Generate referral codes,” “Add reward-on-first-payment hook,” “Build the referrer’s dashboard,” each with a description pulled from what was actually said.

One conversation, a finished page and a populated backlog. Nobody had to tab away to fetch a missing decision, because the decisions came first.

Pages and databases, not just pages

This is the bit worth being exact about. Plenty of tools can pour text into a Notion page. Projan does that — the spec is a genuine structured page — but in the same export it also writes to a database. The narrative goes to the page; the work goes to the rows.

What it won’t do: it doesn’t wire those rows together as native Notion relations or roll-ups, and it doesn’t restructure an existing database’s schema. It populates entries in a database you pick, title and description filled, ready for whatever views you already run. The order of work and the reasoning behind it sit in the spec page’s prose, where a person reading it can follow why the sequence is what it is.

Plan where you talk, write where you think

A team thinks in Notion but rarely decides in Notion — deciding is messy, multiplayer and argumentative, and a document editor is a lonely room to argue in. So Projan runs the argument where the argument already lives. Its Slack and Microsoft Teams bots facilitate the whole session in-channel: the questions, the reward-on-signup disagreement, the moment everyone lands on the same answer. There’s a web workspace too, for when someone wants a quieter canvas. Wherever the session runs, the agreed output is what gets written into Notion. The talking stays where talking is good; the writing lands where your knowledge already lives.

Setting it up

Connect Notion once under Integrations → Notion — you authorise Projan and grant access to the pages and databases you want it writing into. Run a session, agree the thing, and at export choose where the spec page goes and which database catches the work items. Because the session isn’t bolted to Notion, the same agreed plan can go to Jira or Linear instead — choosing Projan never ties your output to one destination.

Projan and Notion do different jobs

Notion is where your team thinks and the home for what it knows. None of that moves. Projan isn’t a knowledge base and has no ambition to become one — it runs the conversation that decides what’s worth keeping, then writes the result into Notion so the page is something the team genuinely agreed rather than a draft someone meant to finish. Notion holds the truth. Projan makes sure the truth got decided before it landed there.