Keep it small and tied to work the team already does: a home page, a team wiki, a handful of playbooks and one decisions log. Give every page an owner and a review date. Let systems of record hold the data, and use Notion for how the team works. Keep founders out of it.
I've seen a lot of Notion graveyards. Someone on the platform or ops team spends a few weeks building a beautiful workspace, with dozens of pages, linked databases and icons on everything. The team loves it for a month. Six months later nobody trusts a page in it, and the real answers live in Slack threads and in one person's head again.
The tool isn't the problem. Notion is good at what it's good at. The problem is that most of these workspaces ask people to do homework: copy data in, log meetings, keep a tracker current. People do homework for a few weeks and then stop. A Notion system that survives asks for very little and gives a lot back.
Decide what Notion is for, and what it isn't
Most stale workspaces fail at this step. They try to be the wiki, the CRM, the portfolio tracker and the meeting archive all at once. Then every database is half-maintained and nobody knows which copy of a number is right.
Split it like this:
| Put it in Notion | Keep it in a system of record |
|---|---|
| How the team works: roles, rituals, decision rights | Portfolio metrics and their history |
| Playbooks for repeatable work | Deals, contacts and pipeline stages |
| Onboarding for new hires | Fund accounting, capital calls, LP records |
| Decisions and the reasons behind them | Meeting notes and transcripts from your note tool |
| Where each kind of data lives, and who owns it | Email and calendar history |
The left column changes slowly and is written by people. The right column changes constantly and should arrive without anyone typing it. When you copy right-column data into Notion, you create a second version that starts going stale the moment you paste it. Link to the source instead.
Portfolio data is the usual offender. Someone builds a "portfolio tracker" database with ARR and headcount columns, fills it in once, and it never gets updated again. Use a system that collects that data for you. Cura sends metric requests to portfolio companies, follows up on its own and extracts the numbers from replies and documents, with each number linked to its source. Your Notion page can point at it rather than copy from it.
Start with five pages, not fifty
A workspace your team will use fits on one screen. Here's a structure I'd start with:
Home
├── Team wiki
│ ├── Who owns what
│ ├── How we make decisions
│ ├── Our tools and where data lives
│ └── Expert, vendor and advisor contacts
├── Playbooks
│ ├── Founder dinner
│ ├── New portfolio company onboarding
│ ├── Quarterly metrics cycle
│ └── LP update
├── Decisions log
└── Onboarding (first two weeks for a new hire)
The decisions log is the page I'd fight for. Every firm makes decisions in partner meetings that nobody writes down: we stopped doing the summer offsite, we're moving the AGM to spring, platform owns the job board now. Six months later someone asks why, and nobody remembers. One line per decision, with the date, the owner and the reason, saves hours of re-arguing.
Add pages only when a question gets asked twice. If nobody has asked, nobody needs the page yet.
Make it the easiest place to find an answer
People use the wiki when it's faster than asking a colleague. So make it faster.
- Answer with links. When someone asks a question in Slack that the wiki answers, reply with the link. When the wiki doesn't answer it, answer in Slack, then add it to the wiki the same day.
- Put playbooks where the work starts. Add the playbook link to the calendar invite for the recurring event. Nobody goes looking for the founder dinner playbook; they open the invite.
- Connect your AI assistant. If your team uses Claude or ChatGPT, connect it to the workspace so people can ask "how do we run the quarterly metrics cycle?" and get the answer from your own playbook. A wiki that answers questions in chat gets used far more than one people have to browse.
- Don't ask anyone to log meetings. People who log by hand forget. Let your note-taking tool capture the meeting, and keep only the decision in Notion.
That last point matters more than it looks. The moment a workspace depends on manual logging, the gaps start, and once people notice gaps they stop trusting the whole thing.
Don't turn it into a founder portal
At some point, someone will suggest publishing part of the workspace for founders: a resource hub with templates, vendor lists and perks. It looks cheap and fast, because the content already exists.
I'd skip it. Founders don't remember the link or the login, and they won't browse a hub when they need help. They'll message the person they know. I covered the reasoning in more depth in whether platform teams need a founder portal.
Use the workspace as the platform team's internal source instead. When a founder asks in Slack for a SOC 2 auditor, the platform lead pulls the answer from the internal page and sends it in the thread, with a name to call. The founder gets help where they asked, and the team keeps one source. The narrow exception is a single public page for a one-off thing, such as directions and an agenda for an event. That's fine.
A playbook template that holds up
Every playbook should answer the same questions, in the same order, on one page:
Playbook: [name]
Owner: [one person]
Last reviewed: [date] Next review: [date]
When we run this: [trigger or cadence]
Goal: [one sentence on what good looks like]
Steps:
1. ...
2. ...
Who does what: [names or roles]
Tools and data: [links to the source, not copies]
What went wrong last time: [two or three lines]
The "what went wrong last time" section is the most valuable part, and the first thing people drop. It's what turns a checklist into team memory.
What belongs in a VC team wiki?
How the firm works, written down once: who owns what, how decisions get made, the investment process, platform programs, vendor and expert contacts, onboarding for new hires, and the firm's tools and where data lives. Leave out portfolio metrics and deal data. Those belong in a system of record, not a page.
Two pages pay off fastest. "Who owns what" ends the round of Slack messages asking who handles a portfolio data request or an LP question. And "our tools and where data lives" is the page every new hire wishes they'd had (I'd write it before anything else). If you're onboarding someone new to platform, the wiki also gives them a head start on the work in the first 90 days.
How do you keep Notion playbooks from going stale?
Give each playbook one named owner and a review date, and show the last-reviewed date at the top. Update the playbook right after you run it, while the lessons are fresh. Archive anything nobody has used in two quarters. A short, current playbook beats a long one nobody trusts.
Make the update part of the work, not a separate chore. The last step of every playbook should be "update this page", and the owner does it the same week. Once a quarter, spend 30 minutes walking the playbook list as a team: keep, update or archive. The same limits apply to databases, and the Airtable post covers where a tool like this breaks down once too many people are editing it by hand.