notion-pm
Notion expert for product management workflows. Covers database design for PRDs, OKRs, Roadmaps, and Decisions; property types (relation, rollup, formula); view design (Board, Timeline, Calendar, Gallery, Table); page architecture; Notion-flavored Markdown blocks; Notion REST API patterns; and sync patterns with Jira, Linear, and GitHub.
What this skill does
# Notion for Product Management Master-level expertise in using Notion as the documentation and operational backbone for a product team: PRDs, OKRs, roadmaps, decision logs, sprint reviews, 1:1 notes, customer research, and sync patterns with Jira, Linear, and GitHub. Covers Notion's database model, view design, formula and rollup patterns, page architecture, and REST API. ## Overview Notion's PM value comes from its database model: every meaningful PM artifact (a PRD, an OKR, a roadmap row, a decision) becomes a row in a typed database, with relations to other databases. This unlocks linked views (one source of truth, many surface presentations), rollups (aggregate child progress into a parent), and a queryable API. The job of a Notion PM expert is to design these databases up front, restrain ad-hoc page creation, and tie the workspace into Jira/Linear/GitHub so the artifacts stay current without manual maintenance. ### When to Use - Standing up a new product team's documentation workspace - Designing a PRD, OKR, Roadmap, or Decisions database from scratch - Refactoring an existing Notion workspace that has grown into a sprawl of unrelated pages - Building roadmap or status views aggregated from underlying issue trackers - Authoring Notion REST API calls (page creation, database queries, block updates) - Setting up two-way sync between Notion and Jira/Linear/GitHub - Establishing governance: ownership, review cadence, archive strategy ## Concepts ### Workspace Hierarchy | Level | Purpose | Example | |---|---|---| | **Workspace** | Top-level account, billing scope, SCIM/SAML | "Acme Inc" | | **Teamspace** | Permission boundary for a team or function | "Product", "Engineering" | | **Page** | A document or container | "Onboarding wiki" | | **Database** | Typed collection of pages (rows = pages with properties) | "PRDs DB", "OKRs DB" | | **Database row** | A page whose parent is a database | "PRD: Self-Serve Signup" | | **Linked Database** | A view of another database, embedded in a page | A "This Quarter" view of the PRDs DB | | **Block** | A unit of content inside a page (paragraph, heading, callout, toggle, image, embed) | "Heading 2", "Callout", "Synced Block" | ### Property Types (the heart of database design) | Type | Use | Notes | |---|---|---| | `title` | The row's name; every database has exactly one | Renders as the page title | | `rich_text` | Long-form text | Supports markdown formatting | | `select` | Single-value tag from a closed list | E.g. PRD status: Draft / Review / Approved / Shipped | | `multi_select` | Multi-value tags | E.g. PRD area: API, Web, Mobile | | `status` | Special select with three groups: To-do, In progress, Complete | First-class in views | | `date` | Date or date range | Supports reminders | | `people` | Reference to workspace member(s) | Owner, reviewer | | `files` | Attached files or URLs | Specs, mocks | | `checkbox` | Boolean | Approved? | | `url`, `email`, `phone` | Typed contact data | Customer DB | | `number` | Numeric with optional format (percent, currency) | Confidence, RICE score | | `formula` | Computed from other properties | E.g. RICE = (R*I*C)/E | | `relation` | Link to row(s) in another database | PRD → OKR, PRD → Roadmap Item | | `rollup` | Aggregate property of related rows | "Sum of estimates from linked Linear issues" | | `created_time`, `last_edited_time` | System | Always present | | `created_by`, `last_edited_by` | System | Always present | | `unique_id` | Auto-incremented short ID with prefix | E.g. PRD-001, DEC-042 | ### Views Every database can present multiple views, each with its own filter, sort, group, and property visibility: - **Table** — spreadsheet-like; default editing view - **Board** — Kanban grouped by a select/status property; great for PRD status, OKR confidence - **Timeline** — Gantt-like; great for Roadmaps when there is a date-range property - **Calendar** — month view; great for launches, reviews, sprint ceremonies - **Gallery** — card view with the cover image; great for customer research notes or design reviews - **List** — minimal, dense; great for backlog-style browsing ### Notion-Compatible Markdown / Block Types Notion is not strictly Markdown, but Markdown extensions are recognized in many contexts. Key blocks used in PM artifacts: - Headings: `#`, `##`, `###` - Callouts: `> [!NOTE]`, `> [!WARNING]`, `> [!TIP]` (in Markdown imports; native block in UI) - Toggle blocks: collapse-expand sections (great for "Open questions", "Out of scope") - Synced blocks: a single block reused across pages (Definition of Done, glossary) - Code blocks: fenced with language for syntax highlighting - Linked databases: a view of another DB embedded inline - Mentions: `@person`, `@page`, `@date` - Bookmarks: a URL becomes a rich preview card - Embeds: Figma, Loom, GitHub Gist, YouTube - Math: `$equation$` inline; `$$equation$$` block ## Core Workflows ### 1. Workspace Setup for a Product Team 1. Create a Teamspace named `Product`. 2. Create the foundational databases as direct children of the Teamspace: - PRDs - OKRs (with quarter as a property) - Roadmap - Decisions - Customer Research - Sprint Reviews (or Cycle Reviews if on Linear) - 1:1s 3. Define the relations between them (see `references/notion-database-design-for-pm.md`). 4. Create a Teamspace home page with a curated set of linked database views. 5. Establish naming conventions; pin them in a "Team conventions" page. 6. Set permissions: full access for product team, edit for engineering, view for everyone else. 7. **HANDOFF TO**: PMs to start populating PRDs and OKRs. ### 2. PRD Database Design A PRD is a row in the PRDs database. Properties: | Property | Type | Purpose | |---|---|---| | `Title` | title | PRD name | | `Status` | status | Draft / In Review / Approved / In Build / Shipped / Killed | | `Owner` | people | Driving PM | | `Author` | people | Original drafter | | `Reviewers` | people | DRI, Eng lead, Design lead | | `Target Date` | date | Aspirational launch | | `Priority` | select | P0 / P1 / P2 / P3 | | `OKR` | relation → OKRs | Which OKR(s) this serves | | `Roadmap Item` | relation → Roadmap | Which roadmap item this delivers | | `Linear Project` | url | Link to the Linear Project tracking the work | | `Jira Epic` | url | If using Jira | | `Tech Lead` | people | Engineering DRI | | `Design Lead` | people | Design DRI | | `Approved On` | date | Set when status → Approved | | `Shipped On` | date | Set when status → Shipped | | `Document` | (page body) | The PRD itself, with the template from `assets/notion-prd-template.md` | Build views: - **My PRDs** (filter: Owner is me) - **In Review** (filter: Status = In Review; sort by Target Date) - **This Quarter** (filter: Target Date in this quarter, group by Status) - **All by Owner** (group by Owner, hide killed) ### 3. OKR Database Design | Property | Type | Purpose | |---|---|---| | `Title` | title | KR or Objective name | | `Type` | select | Objective / Key Result | | `Parent Objective` | relation (self) | For KRs, link to parent Objective | | `Quarter` | select | Q1 2026, Q2 2026, ... | | `Owner` | people | Single accountable owner | | `Status` | status | Not started / On track / At risk / Off track / Hit / Missed | | `Confidence` | select | 10 / 7 / 5 / 3 (Wodtke scale) | | `Target` | rich_text | The measurable target | | `Current` | rich_text | Current value (updated weekly) | | `Progress` | number (percent) | Manual or formula | | `PRDs` | relation → PRDs | PRDs that contribute to this KR | | `Notes` | rich_text | Context, blockers | Views: - **This Quarter by Objective** (group by Parent Objective) - **My OKRs** (filter: Owner is me) - **At Risk / Off Track** (filter on Status) ### 4. Roadmap Database Design | Property | Type | Purpose | |---|---|---| | `Title` | title | Initiative name | | `Horizon` | select | Now / Next / Later (or Q1 / Q2 / Q3 / Q4) | | `Status` | status | Discovery / Defining / Building / Shipped
Related in Design
contribute
IncludedLocal-only OSS contribution command center. Auto-refreshes the user's in-flight PR and issue state on invoke so conversations start with full context — no need to brief Claude on what's in flight. Helps the user find issues to contribute to on GitHub, builds per-repo dossiers of what each upstream expects (CLA, DCO, branch convention, AI policy, draft-first, review bots, issue templates), runs deterministic gates before any external action so AI-assisted contributions don't reach maintainers as slop. State is markdown-only: candidate files at ~/.contribute-system/candidates/, repo dossiers at ~/.contribute-system/research/, append-only event log at ~/.contribute-system/log.jsonl. No database, no cloud calls. Use when the user asks about their PRs / issues / contributions, wants to find new work to take on, claim an issue, build/refresh a repo's dossier, or draft a Design Issue or PR. Trigger with "/contribute", "what's my PR status", "find a contribution", "claim issue X", "draft a Design Issue for Y", "refresh dossier for Z".
architectural-analysis
IncludedUser-triggered deep architectural analysis of a codebase or scoped subtree across eight modes — information architecture, data flow, integration points, UI surfaces, interaction patterns, data model, control flow, and failure modes. This skill should be used when the user asks to "diagram this codebase," "map the architecture," "show the data flow," "give me an ERD," "trace control flow," "find the integration points," "verify the layout pattern," "audit the UX architecture," or any similar request whose primary deliverable is mermaid diagrams plus cited reports under docs/architecture/. Dispatches haiku/sonnet sub-agents in parallel for per-mode exploration, then verifies every citation mechanically before any node lands in a diagram. Not for one-off prose explanations of code (use code-explanation) or for high-level system design from scratch (use system-design).
mcp
IncludedModel Context Protocol (MCP) server development and tool management. Languages: Python, TypeScript. Capabilities: build MCP servers, integrate external APIs, discover/execute MCP tools, manage multi-server configs, design agent-centric tools. Actions: create, build, integrate, discover, execute, configure MCP servers/tools. Keywords: MCP, Model Context Protocol, MCP server, MCP tool, stdio transport, SSE transport, tool discovery, resource provider, prompt template, external API integration, Gemini CLI MCP, Claude MCP, agent tools, tool execution, server config. Use when: building MCP servers, integrating external APIs as MCP tools, discovering available MCP tools, executing MCP capabilities, configuring multi-server setups, designing tools for AI agents.
react-native-skia
IncludedDesign, build, debug, and optimise high-polish animated graphics in React Native or Expo using @shopify/react-native-skia, Reanimated, and Gesture Handler. Use when the user wants canvas-driven UI, shaders, paths, rich text, image filters, sprite fields, Skottie, video frames, snapshots, web CanvasKit setup, or performance tuning for custom motion-heavy elements such as loaders, hero art, cards, charts, progress indicators, particle systems, or gesture-driven surfaces. Also use when the user asks for fluid, glow, glass, blob, parallax, 60fps/120fps, or GPU-friendly animated effects in React Native, even if they do not explicitly say "Skia". Do not use for ordinary form/layout work with standard views.
plaid
IncludedProduct Led AI Development — guides founders from idea to launched product. Six capabilities: Idea (discover a product idea), Validate (pressure-test the idea against fatal flaws, problem reality, competition, and 2-week MVP feasibility), Plan (vision intake + document generation), Design (translate image references into a design.md spec), Launch (go-to-market strategy), and Build (roadmap execution). Use when someone says "PLAID", "plaid idea", "help me find an idea", "product idea", "idea from my business", "idea from my expertise", "plaid validate", "validate my idea", "pressure-test", "is this idea good", "find fatal flaws", "validate the problem", "plan a product", "define my vision", "generate a PRD", "product strategy", "plaid design", "design from image", "translate image to design", "create design.md", "extract design tokens", "plaid launch", "go-to-market", "launch plan", "GTM strategy", "launch playbook", "plaid build", "build the app", "start building", or "execute the roadmap".
nextjs-framer-motion-animations
IncludedAdds production-safe Motion for React or Framer Motion animations to Next.js apps, including reveal, hover and tap micro-interactions, whileInView, stagger, AnimatePresence, layout and layoutId transitions, reorder, scroll-linked UI, and lightweight route-content transitions. Use when the user asks to add, refactor, or debug Motion or Framer Motion in App Router or Pages Router codebases, especially around server/client boundaries, reduced motion, LazyMotion, bundle size, hydration, or route transitions. Avoid for GSAP-style timelines, WebGL or 3D scenes, heavy scroll storytelling, or CSS-only effects unless Motion is explicitly requested.