product-ops

产品与路线图管理

在 Airtable 中设置并运行产品运营工作流——路线图、客户反馈、发布、OKR、冲刺、版本发布——并根据用户的团队规模、子工作流优先级和客户类型进行调整。搭建框架前先询问范围；相同的触发条件可能意味着一个包含 3 个表的个人工作区，也可能意味着一个跨多个数据库的企业级产品组合，合适的架构取决于用户实际要协调的内容。

适用对象及其要解决的问题

三类产品形态，各自对应不同的用户画像和痛点：

• 软件产品团队——看似最显而易见的默认场景，实际上还不到真实案例的一半。 PM、PMM、工程负责人、设计师、创始人／一人兼任 PM 的团队。 首要任务：让高管和 GTM 团队了解路线图进展；将反馈与功能关联起来，并体现需求信号；逐级分解 OKR；协调产品发布；明确产能与承诺之间的关系。典型痛点：Productboard／Jira／Smartsheet／电子表格／幻灯片之间工具泛滥——“来回切换工具的工作”、“事实来源太多”、“PM 每周花 2-3 小时搜索和复制数据”、“PM 有 40% 的时间都在回答内部关于路线图的问题”；反馈_“石沉大海”_。
• 非科技行业的产品团队。 服装／时尚／消费品领域的产品经理（PLM 类型——产品线规划、BOM、技术包、样品跟踪），银行／金融科技／资本市场领域（受监管且有阶段关卡），制药／生物技术／医疗器械领域（合规要求繁重），媒体／游戏领域（发布节奏和系列产品组合），航空航天／汽车领域（APQP 及与供应商协作）。 首要任务：落实分阶段合规的产品生命周期管理；通过同步的工作区协调供应商／合作伙伴；治理 BOM 和 SKU；审查计划的 ROI／IRR／NPV 商业论证；汇总受监管的审计跟踪记录。典型痛点：老旧的 PLM／SoR 系统_“早已无人维护”_；Excel 文件泛滥且版本冲突；需要在专业工具和高管评审之间建立“转换层”；当前工具无法强制满足监管审计跟踪要求。
• 规模化多团队产品运营。 大型产品组织中的产品运营负责人、产品运营总监、PMO 总监、产品副总裁。 首要任务：汇总各小组的产品组合；在产能约束下规划并制定优先级取舍方案；跟踪跨团队依赖关系；协调数百项计划的 OKR；提供适合移动设备查看的高管仪表板。典型痛点：“周末通宵赶报告”；战略意图与运营工作之间出现组合偏移；“产品／工程以外的团队不熟悉 Jira”；“需要手动将 Jira 数据转换成高管能看懂的内容”。

贯穿这三类场景的更广泛问题：

• 工具泛滥，单一事实来源失效。 一个工作区通常可以取代 5 种以上工具——PM 工具、工程跟踪工具、电子表格、幻灯片和邮件线程。首要工作往往是整合，而不是再增加一个工具。
• 手动报告带来的繁重工作。 状态更新、高管演示文稿、每周摘要、季度业务回顾（QBR）准备——PM 的大量时间都花在制作本可由系统自动生成的报告上。自动化通常是早期收益最高的举措。
• 反馈与功能脱节。 客户信号来自各种渠道（NPS、支持工单、Slack、销售记录、应用内反馈、通话记录），却无法追溯到路线图决策——如果没有从原始信号到按需求权重排序的优先级的结构化关联，反馈就会_“石沉大海”_。
• 跨职能交接容易遗漏信息。 如果没有明确的负责人、依赖关系和共享架构，设计 → 工程 → 营销 → CS 的交接就会丢失信息。
• 理想化的 AI 与实际部署的 AI 之间存在差距。 大多数客户仍在产品运营中试点 AI，而非将其投入生产。工作流应能在 AI 可用时顺畅整合 AI，同时也能在没有 AI 的情况下正常运行。

请据此调整措辞和优先级。小团队的创始人关注轻量级待办事项管理和反馈与功能的关联；非科技行业的 PM 关注生命周期／合规／供应商协调；产品运营负责人关注产品组合汇总和产能方案。同一技能，不同切入点。

搭建前：询问范围

产品运营涵盖软件、银行、服装、制药、媒体、航空航天、能源等众多行业，而“显而易见”的技术产品团队默认模式并不适用于一半以上的实际情况。先提出三个范围问题，再根据答案展开。不要一口气问完所有问题；先问团队规模和子工作流，只有第三个问题的答案会影响后续决策时再问。

1. 团队规模和构成。 单人 / 小型（少于 10 人）/ 中型（10-50 人）/ 大型（50 人以上）/ 企业级（多团队 / 多基地）。这决定了架构的默认形态——5 人团队和 200 人的产品组织需要的脚手架并不相同。
2. 优先处理哪个子工作流。 “路线图、客户反馈、发布协调、OKR、冲刺规划，还是其他内容？” 这决定了要加载哪个 Work 模式手册。大多数用户首先只需要其中一个，而不是全部。
3. 客户 / 用户的构成。 “你们的产品决策是跟踪具名客户和客户账户（B2B）、汇总广大用户群体的信号（消费者），还是两者兼有（混合 / B2B2C）？” 这决定了架构是否需要带有按 ARR 加权汇总的 Accounts 表、带有按量加权信号的 Cohorts / Segments 表，或两者都需要。要从实际操作角度提问——询问他们实际跟踪哪类数据，而不是抽象的商业模式标签。

仅在相关时，再根据情况深入询问：

• 是否已有工程跟踪工具？（Jira / Linear / Azure DevOps / 无。）许多产品运营方案会与 Jira 集成；这会影响同步计划，也可能引出“转换层”的定位（Airtable 作为面向高管和 GTM 的 Jira 人性化界面）。
• 是否要从单一用途的 PM 工具迁移？（Productboard / Aha / Cycle / Monday / Smartsheet / Notion / Miro。）这会涉及迁移手册；这是常见情况，并非边缘案例。
• 是否需要面向公众的界面？（客户门户、外部路线图查看器、品牌化反馈页面。）这会推动用户采用自定义应用构建层（见下文“输出”）。
• 是否受批准供应商的 AI 限制？（仅限 Gemini，不允许使用第三方 LLM。）这在企业中很常见；会影响该技能可以推荐哪些 AI 集成。

三个主要问题加上相关的分支问题，通常一轮对话就能明确脚手架需求。先听取需求，不要急于套用框架。

两种模式

设置模式：搭建基础架构

当用户提出 “设置一个路线图基础架构” / “用 Airtable 为我搭建产品运营” / “跟踪功能请求” 时，在明确范围后通过 MCP 搭建架构。步骤如下：

1. 询问范围（见上文）——仔细阅读答案；即使用户直接说 “直接搭建吧”，也不要跳过这一步。花 5 分钟了解范围，胜过之后重建一个形态错误的架构。
2. 选择架构形态，使其符合团队规模和客户构成。技能正文中列出了五种主要形态；另外还有两种小众形态，可按需使用。
3. 通过 MCP 构建架构——基础架构、类型化字段、关联记录、公式、汇总字段、示例 / 种子数据。架构是其他所有功能的基础；应投入 Agent 的精力，构建更丰富的类型化字段、命名合理且选项颜色精心设计的状态 singleSelect，以及带有汇总计数的关联记录关系。
4. 交接 UI 配置，由 Airtable 的 UI 更擅长处理的部分——视图、界面、自动化、表单、细粒度权限、同步向导。交接形式见下文“构建计划输出”。
5. 在用户需要品牌化 UI、面向公众的门户、嵌入式界面或由聊天机器人驱动数据时，构建自定义应用层。 此步骤可选；见 references/build-shapes.md。

主导架构形态

五种最常见的架构形态，覆盖绝大多数调用。每种形态都适用于 B2B、消费者或混合型变体（Accounts 表与 Cohorts 表；按 ARR 加权或按数量加权的优先级排序；同步 Salesforce 或从应用商店导入）。字段级完整详情见 references/schema-shapes.md。

• 轻量待办（1 张表）——使用 Backlog 表，并通过长文本 Notes 字段记录内联备注；使用 Airtable 原生记录评论进行串联讨论。适用于那些因为企业级 PM 工具感觉过于繁重而“拒绝放弃” Airtable 的小型工程团队。不要强加他们不会使用的路线图／反馈结构；当原生评论和长文本字段已能满足需求时，也不要搭建单独的 Notes／Discussion 表。
• 个人／小型团队（3 张表）——Roadmap（Now／Next／Later）、Customer feedback、Releases。用户希望开展产品运营，但不想过度细化时，默认采用此入门架构。添加评分（RICE），并通过计数汇总建立基础的反馈到功能关联。
• 中型团队（5–6 张表）——另加 Sprints、Sprint tasks、OKRs。三级层级（OKR → Feature → Sprint task）符合 Airtable 的标准结构。为不同利益相关者提供专属界面（Leadership／PM／Engineering）。
• 大型团队（标准 7 表架构）——另加 Team members、Customer accounts。依据 Airtable 的产品运营架构指南。建议跨 Base 同步，以汇总多个产品团队的组织级数据。
• 企业级／SAFe 架构——另加每个团队／季度的 Capacity、Dependencies、PI staging、Cut-line scenarios。在 Initiatives 中添加 Capex／opex／ROI／IRR／NPV 商业论证字段。提供跨多个季度的泳道视图，并支持基于权限的下钻。

另外两种小众架构形态，仅在需求范围答复表明适用时提供：

• 阶段门／分阶段审批（银行、制药、航空航天、CPG）——添加 Stage-Gate 表，其中包含阶段定义、关联记录 Compliance Checks、每个阶段的 Approver 字段，以及审计历史汇总。由“我们需要分阶段审批”或受监管行业相关信号触发。
• 并购控股公司（多公司组合）——添加 Acquired-Companies、Deal-Pipeline 评分和 External Onboarding Portal 界面。由“我们运营多家子公司”或并购相关词汇触发。

不要把 Airtable 的 7 表架构强加给 5 人团队；也不要向拥有 6 个产品小组的企业客户交付 3 表 MVP。选择与答复相符的架构形态。

构建层决策

设置模式技能由四个并行层组合而成（不是瀑布式流程）：

1. 架构层（始终通过 MCP） — 基础表、类型化字段、关联记录、公式、种子数据。这是基础；所有路径都要经过这一层。在为特定原生视图或 Interface 组件搭建任何基础表之前，使用 WebFetch 获取相关 support.airtable.com 文档，了解该界面当前的架构要求和行为。让架构符合官方模型，可避免“看起来没问题却无法渲染”的故障模式。
2. Airtable 原生 UX 层 — 视图（看板 / 日历 / 画廊 / 时间线 / 甘特图 / 列表）、Interface Designer 页面、自动化、表单、精细权限、同步设置向导（Jira / Salesforce / Zendesk 等）。对于 MCP 当前支持创建的内容，使用 MCP；其余内容则移交为 [click here] UI 配置步骤。边界取决于功能支持情况，而非质量选择——当 MCP 支持某个界面时，优先使用 MCP 路径。查询实时 MCP mcp.airtable.com/mcp，了解当前工具支持范围，而不是假设“ MCP 能做什么、不能做什么”的列表一成不变。
3. Airtable Portals 层（折中方案——无代码品牌化外部访问） — 通过自定义品牌登录页面，向外部协作者（客户、合作伙伴、供应商、承包商）发布 Interfaces。编辑者 / 评论者 / 只读权限；按当前用户进行行级筛选。付费附加功能（Team / Business / Enterprise）；Business+ 和 Enterprise 提供品牌化登录页面；只读门户用户不计费；每个基础表只能有一个门户。执行时应以 support.airtable.com 为准，了解当前套餐级别的具体信息，而不要在此处写死数字。 适用场景：需要在界面中体现品牌的客户反馈门户、面向合作伙伴的只读路线图预览、外部利益相关者仪表板。不支持真正面向公开且无需身份验证的受众——门户用户需通过电子邮件邀请或可分享链接登录。对于匿名 / 可被 SEO 索引的界面，请使用第 4 层。
4. 自定义应用层（REST API + Agent 构建的 UI） — 部署在 Vercel 上的 Next.js / React 应用、Slack / Discord / Teams 机器人、定时脚本、嵌入用户现有产品中的界面。当 Portals 不适用时使用：真正公开 / 无需身份验证的受众（具有营销级品牌品质的公开路线图查看器）、超出 Interface Designer 组件集的 UX（多步骤向导、嵌入式图表、动画、定制设计系统）、与客户营销网站品牌一致且使用其域名的品牌化 UX、嵌入用户现有产品的界面，或聊天驱动的工作流（Slack 反馈机器人、Teams 发布状态工作流）。

对于面向外部的界面，同时展示 Portals 和自定义应用选项，由用户选择。 两者都不是普遍适用的默认方案。Portals 是一项付费附加功能；当其组件集适合工作流时，可以节省构建时间。自定义 Vercel 应用则能提供完整的设计控制权；如果用户有能力自行构建和托管，还可避免附加费用。用户比技能更了解自己的限制（预算、设计需求、工程能力、交付时间）。当用户只说 “我想跟踪 X” 或 “管理 Y”，而未指定自定义 UI 时，倾向于使用 Airtable 原生功能。如果答案并不明显，就询问用户——这是一个真实的产品问题，而不是技术细节。

有关具体模式，请参阅 references/build-shapes.md：Vercel 上的客户反馈门户、公开路线图查看器、Slack 反馈收集机器人，以及 Portals 与自定义应用之间的权衡。

工作模式：操作现有基础表

当用户针对已存在的基础表调用此技能时——“分拣本周的反馈”、“准备 Q3 发布沟通内容”、“为这些功能请求评分”——先确定用户需要哪个子工作流，再通过 MCP 执行（筛选、评分、更新），最后通过 show-airtable-link 移交结果。

主导子工作流

十种涵盖大多数调用场景的子工作流。每种工作流都在 references/sub-workflows.md 中提供了完整操作指南——需要时按需加载相关章节。

1. 路线图和组合管理 — 跨团队跟踪计划、关联 OKR、状态可见性、高管仪表板。这是最常见的调用场景。
2. 客户之声 / 反馈综合分析 — 多渠道收集（NPS、支持工单、Slack、销售记录、应用内反馈、通话记录），按产品领域和主题分类，将反馈与功能关联，并汇总需求数量以支持基于需求的优先级排序。
3. 工程跟踪工具转换层 — 上游使用 Airtable 管理战略，下游使用 Jira / Linear / ADO 跟踪执行。在史诗级别进行双向同步；Airtable 作为面向高管和 GTM 的易用界面。当已有工程跟踪工具时，这是一种常见模式。
4. 产品发布 / GTM 协调 — 发布分组、带依赖关系的 UAT / 上线跟踪、通过表单获取客户批准、跨职能任务跟踪、高管发布状态仪表板。
5. OKR 对齐和战略规划 — 计划与 OKR 的映射、按高管负责人汇总月度项目组合、适配移动设备的仪表板。
6. 替换单一 PM 工具 — 明确说明迁移过程。常见的替代对象包括：Productboard、Aha、Cycle、Monday、Smartsheet、Notion、Miro。应表述为“替换单一用途的 PM 工具”，而不只是某个竞争对手。
7. 产能 / 资源分配建模 — 产能计划与实际情况汇总、考虑依赖关系的重新规划、砍项情景、按工程师统计每季度投入天数。
8. 面向客户的路线图门户 — 面向公众或合作伙伴展示路线图，提供预览 / Beta 版可见性、投票和订阅。这是常见模式，并非边缘场景；通常正适合在此构建自定义应用。
9. 带结构化评分的创意准入 — 使用 RICE / WSJF / Lean Canvas 收集创意。重点强调强制采用结构化提交方式，以免创意收集变成_"毫无章法"_的杂乱局面。
10. 跨职能发布沟通自动化 — 自动将发布说明发布到外部渠道，向最初提交者发送反馈闭环通知，每两周发送状态提醒。

另有一种可选的 Agent 状态模式；当用户明确在构建由 Agent 驱动的工作流时，值得介绍：

11. Agent 活动日志模式 — 当用户描述由 Agent 驱动的工作流（定期分类处理、多步骤计划、Agent 长时间运行）时，介绍可选的 Agent activity log 模式，并组合使用 agent-activity-log 技能来搭建和运行日志。不要内联重新实现其架构。它与 Airtable 作为持久化 Agent 基础层的角色天然契合。

references/sub-workflows.md 中还提供了约 12 种较少见的子工作流参考（与 PLM 相邻的流程、外部合作伙伴路线图跟踪、ERP 前置暂存中心、实验生命周期中心、研发参与者管理、高管功能投票、SKU 合理化、销售赋能战卡、并购收购入职、阶段关卡治理、SAFe / PI 规划编排、带级联关键结果汇总的成果导向型路线图）。当需求涉及这些场景时再加载。

组合使用

此技能会与 4 个同级技能配合使用；不要重复实现它们负责的内容。

• show-airtable-link — Setup 模式下，每份构建计划都必须以一个 base 链接结尾；Work 模式下，每项涉及记录的操作都必须以记录 / 表 / 页面链接结尾。必须组合使用。完成工作后，通过 show-airtable-link 返回可点击的链接，并传递工具调用已证实可访问的最具体 URL。
• agent-activity-log — 当用户描述由 Agent 驱动的产品运营工作流（定期整理反馈、多步骤规划、Agent 长期运行、“Agent 应该先提出变更供我审批”、“记录 Agent 如何得出这项优先级”）时，介绍可选的 Agent activity log 模式，并组合使用此技能来搭建和运行它。传入工作流中涉及记录的表（Roadmap、Customer feedback、Releases、OKRs 等），以便正确搭建每个目标的关联记录字段。不要在此处重新实现架构。
• airtable-filters — 当 Work 模式操作需要筛选记录（待处理队列、“查找 P0 功能”、容量汇总）时，通过此技能组合使用筛选语法，而不是重新推导。
• airtable-overview — 仅当用户对基本数据模型概念（base / 表 / 记录 / 界面页面）感到困惑时加载。大多数用户用不到；默认加载会浪费 token。

基于权限的行为

MCP 用户的身份验证决定了用户实际可以打开哪些 URL。遵循工具调用已证实的访问范围：

• 页面受限用户（通过 Airtable 权限模型仅能访问界面的用户）— 只传递界面页面 URL。用户无法打开的 tbl_* URL 对他们来说是无效链接。
• 表级访问权限 — 表 URL 可以安全使用。
• 工作区级访问权限 — 工作区 URL 可以安全使用。

基本规则：如果工具调用没有证实访问范围，就不要提供该链接。如有疑问，降低一个具体级别。show-airtable-link 技能会在传递 URL 时强制执行此规则。

构建计划输出

根据适用的层级选择以下 3 种输出格式之一。选择与用户实际需求匹配的格式——不要过度构建（用户只是想_“跟踪我的项目”时，不要创建自定义应用），也不要构建不足（用户想要“面向客户的门户”_时，不要只列出 UI 操作步骤）。

在列出下面任何 Configure in Airtable 或 Configure Portal 区块中的项目之前，先检查 mcp.airtable.com/mcp 上的实时 MCP 是否支持相应功能——如果 MCP 现在可以创建原本需要交接的界面（视图、Interface 页面、Automation、Form 等），则改用 MCP 路径。MCP 的能力边界变化很快；今天需要通过 UI 交接的内容，明天可能就能由 MCP 驱动。

纯 Airtable（最常见——用户想要原生体验）：

✅ Built (via MCP):
  - [Base name] with [N] tables, [N] fields, linked records, [N] seed records
  - View in Airtable: [base link]

🎨 Configure in Airtable:
  - [Specific Kanban / calendar / gallery view] — [click here]
  - [Specific interface page for the right stakeholder audience] — [click here]
  - [Specific form / automation] — [click here]

Airtable + 门户（用户想为客户 / 合作伙伴 / 供应商提供品牌化的外部访问，而不想构建自定义应用）：

✅ Built (via MCP):
  - [Base + schema]
  - View in Airtable: [base link]

🌐 Configure Portal:
  - Enable Portal on the [Customer feedback intake / Partner roadmap] interface — [click here]
  - Customize branded sign-in page (logo + background) — [click here]
  - Invite first portal guest(s) — [click here]

🎨 Configure in Airtable:
  - [Admin interface page for internal triage] — [click here]
  - [Automation tying portal events to internal workflow] — [click here]

Airtable + 自定义应用（用户想要面向公众的路线图、营销级品牌、嵌入式界面，或基于聊天界面的机器人）：

✅ Built (via MCP):
  - [Base + schema]
  - View in Airtable: [base link]

🛠️ Custom app:
  - [Next.js portal at vercel-deploy-url]
  - Reads / writes [tables] via Airtable REST API
  - PAT scoped to [scopes]
  - Source: [github-repo-link]

🎨 Configure in Airtable:
  - [Admin interface page for triage] — [click here]
  - [Automation tying app to base events] — [click here]

挑选最重要的 1–3 个 UI 交接事项；不要罗列所有可能的视图。用户进入 base 后可以继续索取更多内容。

反模式（不应默认采用的做法）

以下是反复出现的失败模式：默认采用数据并不支持的假设。

• 不要默认套用科技产品团队的模式。 行业多样性才是常态。银行、服装、制药、媒体、航空航天、能源等行业都会在 Airtable 中开展产品运营。先广泛探询，再假设“产品”指的是“软件产品”。
• 不要假设用户有 Jira。 有 Jira 的用户占相当一部分，但不是多数。先构建架构，再将工程跟踪工具集成作为后续分支询问。
• 不要假设用户用 Slack。 在医疗保健、汽车、欧盟企业以及许多大型非科技组织中，Microsoft Teams 更常见。
• 不要一上来就谈功能标志或实验。 这些工作流通常由专用平台（Statsig、LaunchDarkly）承载，在实际的产品运营 Airtable 设置中基本不存在。应聚焦路线图、反馈、发布、OKR 和产能。
• 不要假设用户能使用 Claude 或 OpenAI。 获批供应商的大模型限制确实存在（例如仅限 Gemini，或某些企业禁止使用第三方大模型）。在推荐绑定特定供应商的 AI 集成前，先询问。
• 不要低估轻量级场景。 一种真实的典型情况是：5 人团队只有一张待办事项表——向他们强推标准的 7 表架构就是矫枉过正。
• MCP 目前支持什么，就用它做什么；其余部分则交由 [click here] UI 步骤处理。 执行时查询实时 MCP，而不是假设它能或不能创建什么。这里的界限取决于能力（并且正在逐步缩小），而非质量选择——不要把交接描述成“UI 做得更好”。
• 除非用户确实需要，否则不要推动他们使用 REST API 层。 原生 Airtable 能很好地处理大多数产品运营场景。用户需要面向公众、带品牌、可嵌入或由聊天驱动的应用时，自定义应用层才是正确选择——而不是用户想要“一个路线图数据库”时。

不确定该走哪条路径时，就先询问。两个范围界定问题只需花十秒；重建错误的架构则要花一小时。