产品愿景
产品愿景（Product Vision）是对未来产品切实可行的构想，建议用一句宣传语来简明地向所有人传递产品愿景。
例如：“针对中型公司的市场和销售部门，CRM-Innovator是一款基于网页服务的产品，提供销售跟踪、商机发现、销售支持等功能以改善客户关系，不同于其他产品，我们产品具有巨大的成本优势。”
用户画像
用户画像（Persona）是真实用户的虚拟代表，建立在一系列真实的市场数据和用户调用数据之上的目标用户模型。建立persona的目的是为了让PO与团队成员在产品设计的过程中能够抛开个人喜好，将焦点关注在目标用户的动机和行为上进行产品设计。PO为具体和特定的人物做产品设计要远远优于为脑中虚构的东西做设计，也更来得容易。有了共同的认知基础，PO和团队在实现产品的时候也更容易对优先级和实现手段达成一致。可以参考书籍《创建定性用户画像》。
注意，persona要建立在真实的数据之上。当有多个persona时，需要考虑用户画像的优先级，通常建议不要同时为三个以上的persona设计产品，这样容易产生需求冲突。而且，persona也是在不断修正和调整之中的。
Persona的内容包括：
- 姓名
- 照片
- 年龄
- 家庭状况
- 收入
- 工作
- 擅长
- 活动场景
- 目标和动机
- 喜好和厌恶
- 人生态度等
从为什么开始，作为PO和交付团队，我们首先要思考：
为什么要开发这个产品？想要达到什么目标？
然后，这个产品的潜在用户有哪些？他们的用户画像是怎样的？这类用户的数量有多少？
再次，这个产品能给潜在用户分别带来什么样的影响和帮助？用户使用这个产品的前后会有什么变化？分别能解决用户的什么痛点？目前有任何替代解决方案吗？他们使用本产品的频率会有多高？他一般在什么情况下使用本软件？
最后，为了带给用户有效的影响和变化，我们应该做哪些功能？
用户故事
用户故事（User Story）是一个方便的格式用来表达多种类型的产品Backlog条目，特别是特性的期望业务价值。制作用户故事的方式是让业务人员与技术人员都能理解需求。用户故事结构很简单，并且为会话提供一个很好的占位符。此外，用户故事可以在不同程度的粒度上编写以及很容易逐步细化。
用户故事可以分为不同的颗粒度，规模巨大的用户故事称为史诗(Epic)级用户故事。也可以按照不同的主题(Theme)对用户故事进行分组归类。
用户故事的3C特征
下面说说PB里面的形式之一，User Story（Jeffries 2001），最早是Ron Jeffries在2001年提出user story需要满足3C原则： Card(卡片), Conversation(会话), Confirmation(确认).
- 卡片：
我们并不打算用卡片去捕获组成需求的所有信息。实际上，我们故意使用有限地方的小卡片来促进用户故事简洁。卡片上应该只有几句话来捕获需求的精髓或目的。它也用作占位符以便在利益相关人、产品负责人及开发团队之间进行更细化地讨论。 - 会话：
需求的细节是在开发团队、产品负责人及利益相关人之间的会话中暴露和沟通的。用户故事仅仅为有这个会话的一个承诺。 - 确认：
用户故事还要包含满意条件形式的确认信息。这些是澄清期望行为的验收标准。开发团队用验收标准来更好地理解构建和测试什么，产品负责人用它来确认实现的用户故事达到他的满意。
好的用户故事满足INVEST原则
Bill Wake在2003年又总结了关于user story的INVEST原则：Independent(独立的), Negotiable(可协商的), Valuable(有价值的), Estimable(可估算的), Sized Appropriately or Small(大小合适的), Testable(可测试的).
- 独立的：
当采用独立标准时，目的不是消除所有的依赖，而是用最少依赖的方式编写故事。 - 可协商的：
故事不是预先的需求文档形式的书面合同。相反，故事是会话的占位符，在会话中细节是可协商的。 - 有价值的：
故事需要对客户、用户或者两者都是有价值的。客户（或者选择者）选择并支付产品。用户实际使用产品。如果故事对他们没有价值，这个故事不应纳入产品Backlog。
有价值的标准的关键是从产品负责人的角度看在Backlog中所有的故事必须是有价值的（值得投资），它代表客户与用户的角度。不是所有的故事都是独立的，也不是所有的故事是完全可协商的，但所有的故事必须是有价值的。 - 可估算的：
故事应该对设计、构建及测试它的团队可估计的。估算说明了故事的大小，因此也就说明了工作量和成本。（更大的故事比开发小的故事需要更多的努力与成本、更多的钱）。 - 大小合适的：
当我们计划开始做故事的时候它们应该是大小合适的。在Sprint中要工作的故事应该是足够小的。如果我们执行一个几周时间的Sprint，我们想要工作的几个故事，每个都是几天大小的。如果我们有一个两周的Sprint，我们不想有一个两周大小的故事，因为完不成这个故事的风险太高了。 - 可测试的：
可测试的故事指的是一种非此即彼的方式—相关联的测试要么通过，要么失败。可测试的意味着有和故事关联的良好的验收标准（与满意条件有关），即我早先讨论过的故事“确认”的方面。
用户故事拆分思路
- 从用户角色细分
- 从用户操作细分
- 从数据细分
- 从工作流程细分
- 从业务逻辑细分
- 从简单／复杂的情景或规则细分
- 从验收接受条件细分
- 从功能性及非功能性细分
- 从非功能性、易用性、安全性……等细分
用户故事图谱
用户故事图谱（User Story Mapping，以下简称USM）是一个可视化PB的简单工具，有助于了解PB和需求全貌，理清用户故事之间的关系，特别是当PB越来越大，越来越复杂的时候。USM还可以方便地利用迭代的方式来确定发布计划与发布目标。
用户故事图谱可以看做是一张二维表格，纵向按照用户故事的主题分为不同的列；横向按照不同的迭代时间盒分为不同的行。每张用户故事卡片同时处于在不同的主题列与不同的迭代行中，优先级越高的用户故事越靠近左上方。