Receber por email
← Voltar para o catálogo

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.

288estrelas
Atualizado há 4 meses

Ver no GitHub ↗ Licença: NOASSERTION

Como adicionar

/plugin marketplace add borghei/Claude-Skills

O comando exato pode variar conforme o repositório. Confira o README no GitHub.

Para o autor da skill

Cole no README do seu repo

Mostra que sua skill está catalogada na Skillteca, gera backlink e tráfego rastreável.

[![Skillteca](https://www.skillteca.com.br/api/badge/notion-pm/svg)](https://www.skillteca.com.br/skills/notion-pm)

Skills relacionadas

Ver todas de DevOps e Infra →

Alerta por categoria

Receba novas skills de DevOps e Infra toda segunda

1 email curto, só com as skills novas de DevOps e Infra. 4 minutos de leitura, sem spam, cancela com 1 clique.

Você confirma o email no primeiro envio. Sem spam. Cancela com 1 clique.

Ler descrição completa

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:
  3. PRDs
  4. OKRs (with quarter as a property)
  5. Roadmap
  6. Decisions
  7. Customer Research
  8. Sprint Reviews (or Cycle Reviews if on Linear)
  9. 1:1s
  10. Define the relations between them (see references/notion-database-design-for-pm.md).
  11. Create a Teamspace home page with a curated set of linked database views.
  12. Establish naming conventions; pin them in a "Team conventions" page.
  13. Set permissions: full access for product team, edit for engineering, view for everyone else.
  14. 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

Compartilhar X LinkedIn