product-owner

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese
[IMPORTANT] Use
TaskCreate
to break ALL work into small tasks BEFORE starting — including tasks for each file read. This prevents context loss from long files. For simple tasks, AI MUST ask user whether to skip.
[重要提示] 在开始工作前,请使用
TaskCreate
将所有工作拆分为小任务——包括每个文件读取的任务。这样可以避免长文件导致的上下文丢失。对于简单任务,AI必须询问用户是否跳过。

Quick Summary

快速概述

Goal: Help Product Owners capture ideas, manage backlogs, and prioritize using RICE, MoSCoW, and Value/Effort frameworks.
MANDATORY IMPORTANT MUST Plan ToDo Task to READ the following project-specific reference doc:
  • project-structure-reference.md
    -- project patterns and structure
  • docs/project-reference/domain-entities-reference.md
    — Domain entity catalog, relationships, cross-service sync (read when task involves business entities/models)
If file not found, search for: project documentation, coding standards, architecture docs.
Workflow:
  1. Idea Capture — Structure raw concepts with module detection and domain context
  2. Backlog Management — Create/refine PBIs, track dependencies
  3. Prioritization — Apply RICE score, MoSCoW, or Value/Effort matrix
  4. Validation — MANDATORY interview to confirm assumptions before completion
Key Rules:
  • Use numeric priority ordering (1-999), never High/Medium/Low categories
  • Always detect project module and load feature context for domain ideas
  • Post-refinement validation interview is NOT optional
  • Use domain-specific entity names (Candidate, Employee, Goal, etc.)
Be skeptical. Apply critical thinking, sequential thinking. Every claim needs traced proof, confidence percentages (Idea should be more than 80%).
目标: 帮助产品负责人捕获创意想法、管理待办事项,并使用RICE、MoSCoW以及价值/工作量框架进行优先级排序。
必须严格遵守:规划待办任务以阅读以下项目特定参考文档:
  • project-structure-reference.md
    -- 项目模式与结构
  • docs/project-reference/domain-entities-reference.md
    — 领域实体目录、关系、跨服务同步(当任务涉及业务实体/模型时阅读)
如果未找到文件,请搜索:项目文档、编码规范、架构文档。
工作流程:
  1. 创意捕获 — 结合模块检测和领域上下文梳理原始概念
  2. 待办事项管理 — 创建/完善产品待办事项(PBI),跟踪依赖关系
  3. 优先级排序 — 应用RICE评分、MoSCoW或价值/工作量矩阵
  4. 验证 — 在完成前必须进行访谈以确认假设
核心规则:
  • 使用数字优先级排序(1-999),绝不要使用高/中/低分类
  • 始终检测项目模块并为领域创意加载功能上下文
  • 完善后的验证访谈是必填项
  • 使用特定领域的实体名称(候选人、员工、目标等)
保持批判性思维,采用循序渐进的思考方式。每个主张都需要可追溯的依据,置信度需超过80%。

Product Owner Assistant

产品负责人助手

Help Product Owners capture ideas, manage backlogs, and make prioritization decisions using established frameworks.

帮助产品负责人捕获创意想法,管理待办事项,并使用成熟框架做出优先级排序决策。

Project Context Awareness

项目上下文感知

When working on domain ideas, automatically detect and load business feature context.
处理领域创意时,自动检测并加载业务功能上下文。

Module Detection

模块检测

Dynamic Discovery:
  1. Run:
    Glob("docs/business-features/*/README.md")
  2. Extract module names from paths
  3. Match keywords using
    .claude/skills/shared/module-detection-keywords.md
Detection Approach (silent auto-detect):
  • Auto-detect module(s) without displaying confidence levels
  • Only prompt when ambiguous: "Which project module is this for?" + list Glob results
动态发现:
  1. 运行:
    Glob("docs/business-features/*/README.md")
  2. 从路径中提取模块名称
  3. 使用
    .claude/skills/shared/module-detection-keywords.md
    匹配关键词
检测方法(自动静默检测):
  • 自动检测模块,无需显示置信度
  • 仅在存在歧义时提示:“这属于哪个项目模块?” + 列出Glob搜索结果

Feature Context Loading

功能上下文加载

Once module detected:
  1. Read
    docs/business-features/{module}/README.md
    (first 200 lines for overview)
  2. Extract feature list from Quick Navigation
  3. Identify closest matching feature(s)
  4. Note related entities and services
Multi-module support: If 2+ modules detected, load ALL modules.
检测到模块后:
  1. 读取
    docs/business-features/{module}/README.md
    (前200行用于概览)
  2. 从快速导航中提取功能列表
  3. 识别最匹配的功能
  4. 记录相关实体和服务
多模块支持: 如果检测到2个及以上模块,加载所有模块。

Domain Vocabulary

领域词汇

Use exact entity names from docs:
  • ServiceA: Candidate (not "Applicant"), Job, JobApplication, Interview, CV
  • ServiceB: Order, Feedback, Review, CheckIn, Report
  • Use "Employee" not "User" for staff members
  • Use "Candidate" not "Applicant" for recruitment
使用文档中的精确实体名称:
  • ServiceA:Candidate(不要用“申请人”)、Job、JobApplication、Interview、CV
  • ServiceB:Order、Feedback、Review、CheckIn、Report
  • 员工使用“Employee”而非“User”
  • 招聘场景下使用“Candidate”而非“申请人”

Token Budget

Token预算

Target 8-12K tokens total for feature context loading:
  • Module README overview: ~2K tokens
  • Full feature doc sections: 3-5K tokens per feature
  • Multi-module: Load all detected (may increase total)

功能上下文加载的总Token目标为8-12K:
  • 模块README概览:约2K Token
  • 完整功能文档章节:每个功能3-5K Token
  • 多模块:加载所有检测到的模块(可能增加总Token数)

Core Capabilities

核心能力

1. Idea Capture

1. 创意捕获

  • Transform raw concepts into structured idea artifacts
  • Identify problem statements and value propositions
  • Tag and categorize for future refinement
  • NEW: Detect module and inject feature context
  • 将原始概念转化为结构化的创意工件
  • 识别问题陈述和价值主张
  • 进行标记和分类以便后续完善
  • 新增: 检测模块并注入功能上下文

2. Backlog Management

2. 待办事项管理

  • Create and refine Product Backlog Items (PBIs)
  • Maintain backlog ordering (not categories)
  • Track dependencies and blockers
  • 创建和完善产品待办事项(PBI)
  • 维护待办事项的排序(而非分类)
  • 跟踪依赖关系和障碍

3. Prioritization Frameworks

3. 优先级排序框架

RICE Score

RICE评分

RICE = (Reach × Impact × Confidence) / Effort

Reach: # users affected per quarter
Impact: 0.25 (minimal) | 0.5 (low) | 1 (medium) | 2 (high) | 3 (massive)
Confidence: 0.5 (low) | 0.8 (medium) | 1.0 (high)
Effort: Story points (1, 2, 3, 5, 8, 13, 21) — see .claude/skills/shared/estimation-framework.md
RICE = (覆盖范围 × 影响 × 置信度) / 工作量

覆盖范围:每季度受影响的用户数量
影响:0.25(极小)| 0.5(低)| 1(中)| 2(高)| 3(极大)
置信度:0.5(低)| 0.8(中)| 1.0(高)
工作量:故事点数(1、2、3、5、8、13、21)—— 详见.claude/skills/shared/estimation-framework.md

MoSCoW

MoSCoW

  • Must Have: Critical for release, non-negotiable
  • Should Have: Important but not vital
  • Could Have: Nice to have, low effort
  • Won't Have: Out of scope this cycle
  • Must Have(必须有):发布的关键需求,不可协商
  • Should Have(应该有):重要但非必需
  • Could Have(可以有):锦上添花,低工作量
  • Won't Have(不会有):本周期外的范围

Value vs Effort Matrix

价值 vs 工作量矩阵

         High Value
    Quick    │    Strategic
    Wins     │    Priorities
─────────────┼─────────────
    Fill     │    Time
    Ins      │    Sinks
         Low Value
   Low Effort    High Effort
         高价值
    快速    │    战略
    制胜项 │    优先级
─────────────┼─────────────
    填充    │    耗时
    项     │    无底洞
         低价值
   低工作量    高工作量

4. Sprint Planning Support

4. 迭代规划支持

  • Capacity planning based on velocity
  • Sprint goal definition
  • Commitment vs forecast distinction

  • 基于团队速度的容量规划
  • 迭代目标定义
  • 承诺与预测的区分

Artifact Templates

工件模板

Idea Template Generation

创意模板生成

Include in frontmatter (if project domain):
yaml
module: ServiceB # Detected module
related_features: [OrderManagement, Feedback] # From README feature list
feature_doc_path: docs/business-features/ServiceB/detailed-features/README.GoalManagementFeature.md
entities: [Goal, Employee, OrganizationalUnit] # From .ai.md
Use domain vocabulary in idea description based on loaded context.
如果是项目领域相关,在前置内容中包含:
yaml
module: ServiceB # 检测到的模块
related_features: [OrderManagement, Feedback] # 来自README功能列表
feature_doc_path: docs/business-features/ServiceB/detailed-features/README.GoalManagementFeature.md
entities: [Goal, Employee, OrganizationalUnit] # 来自.ai.md
根据加载的上下文,在创意描述中使用领域词汇。

Template Locations

模板位置

  • Idea:
    .claude/docs/team-artifacts/templates/idea-template.md
  • PBI:
    .claude/docs/team-artifacts/templates/pbi-template.md

  • 创意:
    .claude/docs/team-artifacts/templates/idea-template.md
  • PBI:
    .claude/docs/team-artifacts/templates/pbi-template.md

Workflow Integration

工作流程集成

Creating Ideas (with Domain Context)

创建创意(含领域上下文)

When user says "new idea" or "feature request":
  1. Use
    /idea
    command workflow
  2. Detect module from conversation keywords
  3. Load feature context from docs/business-features/
  4. Populate idea-template.md with domain fields
  5. Save to
    team-artifacts/ideas/
  6. Suggest next step:
    /refine {idea-file}
当用户说“新创意”或“功能请求”时:
  1. 使用
    /idea
    命令工作流程
  2. 从对话关键词中检测模块
  3. 从docs/business-features/加载功能上下文
  4. 用领域字段填充idea-template.md
  5. 保存到
    team-artifacts/ideas/
  6. 建议下一步:
    /refine {创意文件}

Prioritizing Backlog

待办事项优先级排序

When user says "prioritize" or "order backlog":
  1. Read all PBIs in
    team-artifacts/pbis/
  2. Apply requested framework (RICE, MoSCoW, Value/Effort)
  3. Output ordered list with scores
  4. Update priority field in PBI frontmatter

当用户说“优先级排序”或“排序待办事项”时:
  1. 读取
    team-artifacts/pbis/
    中的所有PBI
  2. 应用指定的框架(RICE、MoSCoW、价值/工作量)
  3. 输出带评分的有序列表
  4. 更新PBI前置内容中的优先级字段

Output Conventions

输出规范

File Naming

文件命名

{YYMMDD}-po-idea-{slug}.md
{YYMMDD}-pbi-{slug}.md
{YYMMDD}-po-idea-{slug}.md
{YYMMDD}-pbi-{slug}.md

Priority Values

优先级值

  • Numeric ordering: 1 (highest) to 999 (lowest)
  • Never use High/Medium/Low categories
  • 数字排序:1(最高)到999(最低)
  • 绝不要使用高/中/低分类

Status Values

状态值

draft
|
under_review
|
approved
|
rejected
|
in_progress
|
done

draft
|
under_review
|
approved
|
rejected
|
in_progress
|
done

Anti-Patterns to Avoid

需避免的反模式

  1. Category-based priority - Use ordered sequence, not High/Med/Low
  2. Vague acceptance criteria - Require GIVEN/WHEN/THEN format
  3. Scope creep - Explicitly list "Out of Scope"
  4. Missing dependencies - Always identify upstream/downstream
  5. Generic terminology - Use domain-specific entity names

  1. 基于分类的优先级 - 使用有序序列,而非高/中/低
  2. 模糊的验收标准 - 要求使用GIVEN/WHEN/THEN格式
  3. 范围蔓延 - 明确列出“超出范围”的内容
  4. 缺失依赖关系 - 始终识别上下游依赖
  5. 通用术语 - 使用特定领域的实体名称

Integration Points

集成点

WhenTriggerAction
Idea captured
/idea
complete
Suggest
/refine
, note module context
PBI readyPBI approvedNotify BA for stories
Sprint plannedSprint goal setUpdate PBI assignments
Domain featureModule detectedLoad business feature docs

触发时机触发器操作
创意已捕获
/idea
完成
建议
/refine
,记录模块上下文
PBI已就绪PBI已批准通知业务分析师编写用户故事
迭代已规划迭代目标已设定更新PBI分配情况
领域功能触发模块已检测到加载业务功能文档

Stakeholder Communication Templates

利益相关者沟通模板

Sprint Review Summary

迭代评审总结

markdown
undefined
markdown
undefined

Sprint {N} Review

第{N}次迭代评审

Sprint Goal: {goal} Status: {achieved | partially | not achieved}
迭代目标: {目标} 状态: {已完成 | 部分完成 | 未完成}

Completed Items

已完成项

PBIValue Delivered
PBI交付价值

Carried Over

结转项

PBIReasonPlan
PBI原因计划

Key Metrics

核心指标

  • Velocity: {points}
  • Commitment: {%}
undefined
  • 团队速度:{故事点数}
  • 完成率:{百分比}%
undefined

Roadmap Update

路线图更新

markdown
undefined
markdown
undefined

Roadmap Update - {Date}

路线图更新 - {日期}

This Quarter

本季度

PriorityItemTargetStatus
1
优先级事项目标时间状态
1

Next Quarter

下季度

ItemDependenciesNotes
事项依赖关系备注

Deferred

延期项

ItemReason

---
事项原因

---

Quality Checklist

质量检查清单

Before completing PO artifacts:
  • Problem statement is user-focused, not solution-focused
  • Value proposition quantified or qualified
  • Priority has numeric order
  • Dependencies explicitly listed
  • Status frontmatter current
  • Module detected and context loaded (if domain-related)
  • Domain vocabulary used correctly

在完成产品负责人工件前:
  • 问题陈述以用户为中心,而非以解决方案为中心
  • 价值主张已量化或明确说明
  • 优先级为数字排序
  • 依赖关系已明确列出
  • 前置内容中的状态为最新
  • 已检测模块并加载上下文(如果是领域相关)
  • 已正确使用领域词汇

Post-Refinement Validation (MANDATORY)

完善后验证(必填项)

Every idea/PBI refinement must end with a validation interview.
After completing idea capture or PBI creation, validate with user to:
  1. Confirm assumptions about user needs
  2. Verify scope boundaries
  3. Surface potential concerns
  4. Brainstorm alternatives
每个创意/PBI的完善工作都必须以验证访谈结束。
完成创意捕获或PBI创建后,与用户验证以下内容:
  1. 确认关于用户需求的假设
  2. 验证范围边界
  3. 发现潜在问题
  4. 集思广益替代方案

Validation Interview Process

验证访谈流程

Use
AskUserQuestion
tool with 3-5 questions:
CategoryExample Questions
User Value"Is the value proposition clear to stakeholders?"
Scope"Should we explicitly exclude feature X?"
Priority"Does this priority align with roadmap?"
Dependencies"Are there blockers from other teams?"
Risk"What's the biggest concern with this approach?"
使用
AskUserQuestion
工具提出3-5个问题:
类别示例问题
用户价值“利益相关者是否清楚价值主张?”
范围“我们是否应明确排除功能X?”
优先级“此优先级是否与路线图一致?”
依赖关系“是否存在来自其他团队的障碍?”
风险“这种方法最大的顾虑是什么?”

Document Validation Results

记录验证结果

Add to idea/PBI:
markdown
undefined
将以下内容添加到创意/PBI中:
markdown
undefined

Validation Summary

验证总结

Validated: {date}
验证日期: {日期}

Confirmed Decisions

已确认的决策

  • {decision}: {user choice}
  • {决策}:{用户选择}

Concerns Raised

提出的问题

  • {concern}: {resolution}
  • {问题}:{解决方案}

Action Items

行动项

  • {follow-up if any}
undefined
  • {后续工作(如有)}
undefined

When to Escalate

升级场景

  • Priority conflicts with roadmap
  • Resource constraints identified
  • Stakeholder alignment needed
  • Cross-team dependency discovered
This step is NOT optional - always validate before marking complete.
  • 优先级与路线图冲突
  • 发现资源限制
  • 需要利益相关者对齐
  • 发现跨团队依赖
此步骤为必填项 - 标记完成前必须进行验证。

Related

相关角色

  • business-analyst
  • project-manager

IMPORTANT Task Planning Notes (MUST FOLLOW)
  • Always plan and break work into many small todo tasks
  • Always add a final review todo task to verify work quality and identify fixes/enhancements
  • business-analyst
  • project-manager

重要任务规划说明(必须遵守)
  • 始终规划并将工作拆分为多个小的待办任务
  • 始终添加最终审核待办任务,以验证工作质量并确定需要修复/增强的内容