1.Why：为什么要做原型 原型可以作为MVP的一种，用来验证团队设计出的解决方案是否解决了用户的痛点。我们使用原型深入用户，开展用户访谈，验证这是否是他们想要的解决方案。然后依据用户的反馈，快速修正原型的设计，再次返回到用户之中做验证。这个过程可能需要进行多次。 原型可以作为产品负责 ...

很多企业开展敏捷多年，但是UX部门仍旧是一个独立的部门，没有进入敏捷团队中。UX部门依旧按照自己原有的流程运作，即UX设计师属于每个项目的共享资源，项目的需求功能进入UX部门的需求管道后需要排期。在设计过程中，UX设计师与团队的交流不多，基本上只有在需求沟通会议上澄清一次需求；UX设计师做的 ...

在产品开发的过程中，产品的内部、外部利益干系人会提出很多自己的期望；每个产品版本发布后，团队会收到用户的反馈意见。作为产品负责人，你会发现随着产品继续向前推进，收到的需求会越来越多，总有堆积如山的需求等待着团队去做。因此，判断某个需求做与不做，成为产品负责人需要做出的至关重要的决 ...

决定需求的优先级顺序有两种方法：定性评估法和定量计算法。定性评估法是通过评估影响需求排序的几个要素，然后为需求排出先后顺序；定量计算法是为影响优先级顺序的每个要素赋予一个数值，然后用公式计算并排列出需求的先后顺序。 1.定性评估法 决定需求的优先级顺序需要考虑以下几个要素。 [*] ...

你也许听说过，在敏捷工作方式里，团队一般采用用户故事卡片的形式来描述需求。用户故事是指用户通过系统完成一件有价值目标的事情。 1.Why：为什么要用“用户故事”描述产品需求 采用用户故事卡片的形式来描述需求，可以帮助产品负责人和团队逐渐形成以用户为中心的思考方式，而不是单纯地以功能为 ...

随着第一版MMR发布后，团队对产品研发工作越来越明确。产品需具备的功能，会随时被添加到产品的Backlog里。Backlog的来源如下： [*]商业模式（精益画布）； [*]产品愿景； [*]用户画像； [*]产品路线图； [*]客户或用户的反馈； [*]团队自己发现的需求。 Backlog需要满足以下属性，如果用 ...

敏捷需求管理是对传统需求管理的颠覆。两者的差异如下。 1.需求所承担的作用不同 在传统的需求管理方式里，需求的作用是为了详尽地描述团队需要完成的产品特性，它经常成为产品和研发之间的契约。产品负责人将需求传递给研发人员，研发人员依据文档的描述进行开发和测试。团队最终交付的是文档中描述 ...

很多团队认为，敏捷的价值观是“拥抱变化胜于执行计划”。那么，既然咱们做敏捷了，那就不用做什么计划了。 这是对敏捷价值观的误解。如果完全没有计划，团队一定会得过且过，没有危机感，致使项目一片混乱。这样的话，前几节介绍的商业模式、产品愿景都将无法落地实现。我在前面介绍的Sprint计划和看 ...