PO这个角色比SM和团队其它成员更至关重要。他引领整个团队的方向。
他的工作质量决定了团队的产出是否有价值，价值高低。
PO的职责
明确产品的愿景。
明确产品的发布计划。
梳理产品的backlog。
验收交付增量。
大型产品，一个PO忙不过来怎么办？
原则上，一个PO只能带一个团队。PO应是专职的。
不要一开始就铺开。由一个PO带一个团队，先完成奠基性工作。
以此为基础，扩展团队。为扩展的团队任命另外的PO。原PO仍然带领原团队，但同时该PO还得肩负协同多个PO的职责。
另一种方式，是组成一个大的、层级型PO团队。
这种大型产品，PO人选需要具有高度授权，可能是产品总监，VP层次的。
团队的划分有按特性和按组件两种模式。优先选取特性模式。
愿景与发布计划十分重要
愿景应该简洁。
一个形式是电梯演讲，能够几句话描述出来。
还有一个形式是产品包装盒。想想你要发布的产品包装盒上，产品的名字，产品有哪几个关键特性？产品还有什么更进一步的关键描述，在包装盒的一个面上能够写下来。其实就是产品的“一纸禅”。
产品的核心特性一定要简洁，应该只有少数几条。但一定要个性鲜明。现在吸引人的特性，过段时间就会成为基础特性，因为竞争对手也会具备这些特性。因此产品需要不停地琢磨新的吸引人的特性。
愿景一定要与团队共享。
产品要采取增量发布模式，不能搞爆炸式发布。可以一个季度发布一次。
对于不确定的需求，可以待发布后收集到用户反馈之后，根据反馈情况再做决定是否要研发。
backlog梳理
backlog不要搞成需求规格说明。需求规格说明会让产品的需求变得僵化，看起来所有的需求都清晰了，但实际上这不是真的。
backlog中的条目要详略得当，可估算，涌现式的，可验证的，即满足DEEP原则。
backlog由PO负责，但应该每个迭代都预留时间与团队一起梳理。可能是一个梳理的会议，也可能是每日站会后花较少的时间进行。总的时间不超过一个迭代的1/10。
backlog不要搞成圣诞老人的愿望清单，各色需求都装进来。
一个产品不要搞成多个backlog。
backlog在迭代前应该准备好。如果没准备好，应该推迟迭代启动时间。
一般当前迭代要梳理出下个迭代的需求，并留有一定余量。如果是多团队模式，可能要梳理出两三个迭代的需求来。多个团队可能会产生团队间的依赖，如果b依赖a，在a还没完成的情况下，b可以将后一个迭代的需求提前开发。
需求梳理可以用估算扑克方法，促进团队间的讨论。
也可以在墙上画上一些标有代表规模的数字的行，由大家将需求条目放在他认为合适的行上。这种估算会比较快，但会少了讨论环节，损失掉一些信息。
尽量按固定时间、可变范围来开展研发与交付。
但如果遇到了固定范围与固定总价合同，怎么办？可以分两个阶段，第一个阶段，先通过几个迭代完成关键特性的交付，取得用户反馈，拿到反馈后的需求开展第二阶段。（我理解为可以拿反馈后的需求同用户谈需求变革）
关注非功能性需求。
影响全局的非功能需求应该放在前面的迭代处理，可能会影响整体架构。
易用性需求，可以是在功能界面上通过共创、设计讨论等方式解决。
