Back to Details

platform-strategy

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Platform Strategy

Platform战略

Scope

适用范围

Covers
  • Internal platforms (paved roads, shared infrastructure/services) treated as products
  • External/hybrid platforms (APIs, extensions, partners) and ecosystem strategy
  • Platform lifecycle strategy (when to open vs when to close for control/monetization)
  • Platform surface-area design (interfaces, abstractions, governance) to reduce cognitive load for product teams
  • AI platform defensibility (context repositories + integrated “toolkit” experiences) when relevant
When to use
  • “Create a platform strategy for our developer platform / API.”
  • “Turn our internal platform into a product with clear users, metrics, and roadmap.”
  • “We want to open our platform to third parties—define incentives, governance, and a rollout.”
  • “We’re building an AI platform—what’s the defensible system beyond a single feature?”
When NOT to use
  • You don’t have a clear problem/job-to-be-done yet (use 
    problem-definition
    first).
  • You primarily need a product/company strategy and portfolio plan (use 
    ai-product-strategy
    ).
  • You’re selecting a vendor/tool rather than defining a platform strategy (use 
    evaluating-new-technology
    ).
  • You need an implementation design/architecture doc (use 
    writing-specs-designs
    after this).
涵盖内容
  • 被视为产品的内部平台（标准化流程、共享基础设施/服务）
  • 外部/混合平台（APIs、扩展功能、合作伙伴）及生态系统战略
  • 平台生命周期战略（何时开放vs何时封闭以实现控制/变现）
  • 平台界面设计（接口、抽象层、治理），以降低产品团队的认知负担
  • 相关场景下的AI平台防御性（上下文存储库+集成式“工具包”体验）
适用场景
  • “为我们的开发者平台/API制定平台战略。”
  • “将我们的内部平台转型为拥有明确用户、指标和路线图的产品。”
  • “我们希望向第三方开放平台——定义激励机制、治理规则及推出计划。”
  • “我们正在构建AI平台——除单一功能外，具备防御性的系统架构是什么？”
不适用场景
  • 尚未明确核心问题/待完成任务（请先使用
    problem-definition
    ）。
  • 主要需要产品/公司战略及组合规划（请使用
    ai-product-strategy
    ）。
  • 正在选择供应商/工具而非定义平台战略（请使用
    evaluating-new-technology
    ）。
  • 需要实现设计/架构文档（完成此步骤后请使用
    writing-specs-designs
    ）。

Inputs

输入信息

Minimum required
  • Platform type: internal / external / hybrid (and who “the platform owner” is)
  • Primary users/consumers (e.g., developers, data scientists, partners) and their top jobs-to-be-done
  • Current state: what exists today (surfaces, APIs, services, docs), and what’s broken/painful
  • Business intent: why now, desired outcomes (speed, reliability, revenue, ecosystem leverage), time horizon
  • Constraints: security/privacy/compliance, SLOs, regions, budgets, resourcing, dependencies
  • Decision context: who decides, what decisions are on the table (open/close, pricing, governance), target date
Missing-info strategy
  • Ask up to 5 questions from references/INTAKE.md (3–5 at a time).
  • If still missing, proceed with explicit assumptions and present 2–3 strategy options (e.g., internal-only vs partner beta vs public API).
  • Do not request secrets or credentials. Require explicit confirmation for any production changes or external outreach.
最低要求输入
  • 平台类型：内部/外部/混合（及“平台负责人”身份）
  • 核心用户/使用者（如开发者、数据科学家、合作伙伴）及其核心待完成任务
  • 当前状态：现有资源（界面、APIs、服务、文档）及存在的问题/痛点
  • 业务目标：为何此时启动、期望成果（速度、可靠性、收入、生态杠杆）、时间范围
  • 约束条件：安全/隐私/合规要求、SLOs、地域限制、预算、资源、依赖关系
  • 决策背景：决策主体、待决策事项（开放/封闭、定价、治理）、目标日期
缺失信息处理策略
  • 从references/INTAKE.md中提出最多5个问题（每次3-5个）。
  • 若仍存在信息缺失，基于明确假设推进，并提供2-3种战略选项（如仅内部使用vs合作伙伴测试版vs公开API）。
  • 不得索要机密信息或凭证。任何生产环境变更或外部沟通均需明确确认。

Outputs (deliverables)

输出成果（交付物）

Produce a Platform Strategy Pack (in chat; or as files if requested), in this order:
  1. Platform Product Charter (users, jobs, non-goals, assumptions, outcomes)
  2. Platform Surface & Interface Map (capabilities, owners, APIs/SDKs, “paved road” defaults, boundaries)
  3. Lifecycle Stage & Open/Close Strategy (stage diagnosis, stage-appropriate moves, transition risks)
  4. Moat & Ecosystem Model (compounding loops, incentives, seeding plan, investment gates)
  5. Governance & Policy Plan (what’s open/closed, SLAs, deprecation, partner rules, pricing/packaging if relevant)
  6. Metrics & Operating Model (platform-as-product operating cadence, intake, support, adoption + productivity metrics)
  7. 12‑month Roadmap (milestones, bets, sequencing, dependencies)
  8. Risks / Open questions / Next steps (always included)
Templates: references/TEMPLATES.md
生成Platform Strategy Pack（聊天界面展示；或按要求生成文件），顺序如下：
  1. Platform Product Charter（用户、待完成任务、非目标、假设、成果）
  2. Platform Surface & Interface Map（能力、负责人、APIs/SDKs、“标准化流程”默认配置、边界）
  3. 生命周期阶段与开放/封闭战略（阶段诊断、适配阶段的行动方案、转型风险）
  4. 护城河与生态系统模型（复利循环、激励机制、种子用户计划、投资门槛）
  5. 治理与政策规划（开放/封闭范围、SLAs、废弃规则、合作伙伴条款、相关定价/包装策略）
  6. 指标与运营模型（平台即产品的运营节奏、需求收集、支持、采用率+生产力指标）
  7. 12个月路线图（里程碑、关键举措、优先级排序、依赖关系）
  8. 风险/待解决问题/下一步行动（必含项）
模板：references/TEMPLATES.md

Workflow (8 steps)

工作流程（8步）

1) Define the platform as a product (users + jobs + outcomes)

1) 将平台定义为产品（用户+待完成任务+成果）

  • Inputs: Platform context, primary user groups, current pain.
  • Actions: Write the platform’s “user promise” and top 3–5 jobs-to-be-done. Add 3–5 non-goals. Choose 2–4 outcome metrics (prefer developer productivity metrics like cycle time).
  • Outputs: Draft Platform Product Charter.
  • Checks: You can describe value without naming internal components (“We reduce X minutes of toil per deploy”).
  • 输入：平台背景、核心用户群体、当前痛点。
  • 行动：撰写平台的“用户承诺”及3-5项核心待完成任务。添加3-5项非目标。选择2-4项成果指标（优先选择开发者生产力指标，如周期时间）。
  • 输出：草稿版Platform Product Charter。
  • 校验：无需提及内部组件即可描述价值（如“我们将每次部署的繁琐工作减少X分钟”）。

2) Diagnose the platform lifecycle stage (and what decisions are truly on the table)

2) 诊断平台生命周期阶段（及真正待决策的事项）

  • Inputs: Market/organization conditions, competitive context (if external), timeline.
  • Actions: Determine the most likely stage (Step 0→3) and list evidence. Clarify the “open vs close” decision(s) you must make now (not someday).
  • Outputs: Lifecycle Stage & Open/Close Strategy (draft).
  • Checks: The stage is justified with evidence, not aspiration (“we should be a platform”).
  • 输入：市场/组织状况、竞争环境（若为外部平台）、时间线。
  • 行动：确定最可能的阶段（0→3阶段）并列出依据。明确当前必须做出的“开放vs封闭”决策（而非未来某一天的决策）。
  • 输出：草稿版生命周期阶段与开放/封闭战略。
  • 校验：阶段判定需基于依据，而非主观期望（如“我们应该成为平台”）。

3) Map surface area and define boundaries (reduce decision complexity)

3) 绘制平台界面范围并定义边界（降低决策复杂度）

  • Inputs: Existing services/APIs, teams, dependency graph, common failures.
  • Actions: Inventory platform capabilities; define what becomes a paved road vs optional. Specify boundaries: what platform owns vs domain teams own. Draft interface contracts (APIs/SDKs/events) and “default decisions” the platform makes for others.
  • Outputs: Platform Surface & Interface Map.
  • Checks: A domain team can build without re-deciding foundational choices (auth, logging, deployment, guardrails).
  • 输入：现有服务/APIs、团队、依赖关系图、常见故障。
  • 行动：盘点平台能力；定义标准化流程范围与可选范围。明确边界：平台负责范围vs领域团队负责范围。起草接口契约（APIs/SDKs/事件）及平台为其他团队做出的“默认决策”。
  • 输出：Platform Surface & Interface Map。
  • *校验：领域团队无需重新决定基础选项（如认证、日志、部署、防护规则）即可开展开发工作。

4) Identify the moat and the compounding loop(s)

4) 识别护城河与复利循环

  • Inputs: Unique assets, distribution, data/context advantages, ecosystem participants.
  • Actions: Propose 1–3 moat hypotheses and at least one compounding loop (“if this works, it accelerates”). Define incentives for each participant and a small seeding plan. Define “investment gates” (signals that justify more spend).
  • Outputs: Moat & Ecosystem Model.
  • Checks: The loop has measurable leading indicators (activation, retained developers, successful integrations).
  • 输入：独特资产、分发渠道、数据/上下文优势、生态系统参与者。
  • 行动：提出1-3个护城河假设及至少一个复利循环（“若此机制生效，将加速增长”）。为每个参与者定义激励机制及小型种子用户计划。定义“投资门槛”（证明值得追加投入的信号）。
  • 输出：护城河与生态系统模型。
  • 校验：循环机制具备可衡量的领先指标（如激活率、留存开发者数、成功集成数）。

5) Decide what to open, how to govern it, and how to protect the core

5) 确定开放范围、治理方式及核心资产保护策略

  • Inputs: Stage, risks, support capacity, security/compliance requirements.
  • Actions: Specify what’s open now vs later, plus governance: access control, quotas, review processes, partner rules, SLAs, deprecation/backwards compatibility, and (if relevant) pricing/packaging. Include an “abuse/quality” plan (observability, enforcement).
  • Outputs: Governance & Policy Plan.
  • Checks: “Open” surfaces have a sustainability plan (support, docs, incident response, versioning).
  • 输入：平台阶段、风险、支持能力、安全/合规要求。
  • 行动：明确当前及未来的开放范围，以及治理规则：访问控制、配额、审核流程、合作伙伴条款、SLAs、废弃/向后兼容性，及（如适用）定价/包装策略。包含“滥用/质量管控”计划（可观测性、执行机制）。
  • 输出：治理与政策规划。
  • 校验：开放界面具备可持续性计划（支持、文档、事件响应、版本管理）。

6) (If AI platform) Build defensibility as a system, not a feature

6) （若为AI平台）构建系统级防御能力，而非单一功能

  • Inputs: AI use cases, context sources, data sensitivity, required integrations.
  • Actions: Design a “Swiss‑army toolkit” system: shared context repository + multiple experiences (autocomplete, chat, agent workflows) with consistent policies. Define permissions, audit logs, eval/monitoring, and human-in-the-loop points.
  • Outputs: AI section inside Platform Product Charter + Governance & Policy Plan updates.
  • Checks: The plan improves outcomes while containing risk (least privilege, auditable access, measurable quality).
  • 输入：AI用例、上下文来源、数据敏感性、所需集成。
  • 行动：设计“瑞士军刀式工具包”系统：共享上下文存储库+多种体验（自动补全、聊天、Agent工作流），并配备一致的政策。定义权限、审计日志、评估/监控机制及人工介入节点。
  • 输出：Platform Product Charter中的AI章节 + 治理与政策规划更新内容。
  • 校验：计划在提升成果的同时管控风险（最小权限原则、可审计访问、可衡量质量）。

7) Define metrics + operating model (platform-as-product)

7) 定义指标+运营模型（平台即产品）

  • Inputs: Target outcomes, resourcing constraints, stakeholder map.
  • Actions: Define a metric stack (north-star + input metrics) and an operating cadence (intake, prioritization, roadmap reviews, documentation, support/on-call, feedback loops). Ensure a PM/owner exists for internal platforms.
  • Outputs: Metrics & Operating Model.
  • Checks: Metrics tie to user outcomes (not vanity counts like “# of services migrated” alone).
  • 输入：目标成果、资源约束、利益相关者图谱。
  • 行动：定义指标体系（北极星指标+输入指标）及运营节奏（需求收集、优先级排序、路线图评审、文档更新、支持/On-Call、反馈循环）。确保内部平台配备PM/负责人。
  • 输出：指标与运营模型。
  • 校验：指标需关联用户成果（而非仅 vanity指标，如“迁移服务数量”）。

8) Sequence the roadmap and quality-gate the pack

8) 规划路线图优先级并对战略包进行质量校验

  • Inputs: All draft artifacts.
  • Actions: Create a 12‑month roadmap with 3 horizons (Now / Next / Later). Add dependencies, resourcing, and rollback/exit paths. Run references/CHECKLISTS.md and score with references/RUBRIC.md. Always include Risks / Open questions / Next steps.
  • Outputs: Final Platform Strategy Pack.
  • Checks: A stakeholder can make a decision (owner, date, next actions) and understand trade-offs.
  • 输入：所有草稿成果。
  • 行动：创建包含3个阶段（当前/近期/远期）的12个月路线图。添加依赖关系、资源需求及回滚/退出路径。使用references/CHECKLISTS.md检查，并通过references/RUBRIC.md评分。必含风险/待解决问题/下一步行动。
  • 输出：最终版Platform Strategy Pack。
  • 校验：利益相关者可做出决策（负责人、日期、下一步行动）并理解权衡关系。

Quality gate (required)

质量校验（必填）

  • Use references/CHECKLISTS.md and references/RUBRIC.md.
  • Always include: Risks, Open questions, Next steps.
  • 使用references/CHECKLISTS.md及references/RUBRIC.md。
  • 必含内容：风险、待解决问题、下一步行动。

Examples

示例

Example 1 (internal platform): “Use 
platform-strategy
to create a platform strategy for an internal ML platform used by 40 engineers. Goal: cut model deployment cycle time from 2 weeks to 2 days. Constraints: PII present; SOC2; 2 platform engineers; 6‑month horizon.”
Expected: platform-as-product charter + paved-road interfaces + productivity metrics + governance for AI data.
Example 2 (external ecosystem): “Use 
platform-strategy
to define an API platform strategy for opening our analytics product to partners. We want 20 high-quality integrations in 12 months without breaking core reliability.”
Expected: stage diagnosis + open/close decisions + incentives + governance/versioning + roadmap.
Boundary example: “We should become a platform like Apple—make us a platform strategy.”
Response: out of scope without specific users/jobs and a plausible compounding loop; ask intake questions and/or start with 
problem-definition
.
示例1（内部平台）：“使用
platform-strategy
为40名工程师使用的内部ML平台制定战略。目标：将模型部署周期从2周缩短至2天。约束条件：包含PII数据；需符合SOC2标准；配备2名平台工程师；6个月时间范围。”
预期输出：平台即产品章程 + 标准化流程界面 + 生产力指标 + AI数据治理规则。
示例2（外部生态系统）：“使用
platform-strategy
为分析产品开放API平台制定战略。我们希望12个月内完成20个高质量集成，且不影响核心系统可靠性。”
预期输出：阶段诊断 + 开放/封闭决策 + 激励机制 + 治理/版本管理 + 路线图。
边界示例：“我们要成为像苹果一样的平台——为我们制定平台战略。”
回应：若无明确用户/待完成任务及可行的复利循环，则超出范围；请提出输入问题或先使用
problem-definition
。