产品生命周期：产品功能之旅

这是我正在撰写的五部分系列文章的第四篇，旨在帮助有抱负产品的人进入产品管理领域。

在我的上一篇文章中，我将产品管理学科分解为四个部分，旨在帮助有志于产品管理的人了解他们在公司内或总体上的职业轨迹。 在这篇文章中，我将讨论产品功能的生命历程，从构思到放弃，以帮助有志于产品管理的人从 360 度角度了解产品经理的角色所涉及的内容。

T – 30 天

有人说，需要是发明之母。 这实际上是涉及产品功能诞生的情况。 这一切都始于某种程度的不适。
公司的一些员工在完成他的一项日常任务时面临着不适——也许用户群已经增加，而他无法使用旧流程进行管理。 公司中的一些高管查看 Excel 表并认为公司损失了太多钱，例如，大量产品取消。 或者，竞争对手推出的产品功能可能导致客户离开该公司的产品。 查看营销转化漏斗的人注意到某个阶段的流失率很高，并认为优化这可能有助于他实现季度目标。 或者可能是 100 种不同的原因，从针对常见问题的大量客户投诉到上周接受调查的大多数用户要求的新功能。 关键是——这一切都始于某种程度的不适。

现在，这种不适已引起产品经理的注意； 或者产品经理可能是第一个注意到它的人。 这是启动可能导致新功能诞生的一系列事件的点。

T – 25 天

现在是产品经理仔细考虑问题陈述的时候了。 他去与报告不适的客户或内部利益相关者交谈，然后与实际经历的人交谈； 所有这些都是为了一个目标——确保他已经确定了“根本”问题陈述。 如果这个阶段被轻视，或者产品经理没有花足够的时间在这上面，那么产品的特性是脆弱的，扭曲的，很快就会达到目的。
一旦产品经理确定了核心问题陈述，他就会决定是否值得解决。 不适真的很大，还是有点夸张或更糟，只是编造的？ 解决它实际上会为客户和/或公司增加显着价值吗？ 解决它不会对客户和/或公司造成重大损失吗？ 有没有办法通过对流程进行细微调整或通过任何不需要更改产品的活动来解决这个问题——比如更换供应商、与现有供应商协商更好的价格、获得第三方软件来解决问题、招聘额外的员工、内容、图形、号召性用语按钮等的变化？

基本上，如果有一种方法可以让我们从不涉及产品更改的方法中获得类似的增值，那么我们将寻求改变产品中的任何内容——无论这意味着添加还是删除。 一旦产品经理确信解决问题陈述将提供显着的价值，并且产品级别的更改将比非产品级别的更改提供更多的投资回报率（考虑时间、金钱和努力与/秒的价值），新的种子产品功能被种植。

T – 15 天

如果产品经理有一些先前的经验，他可能会根据该经验提出解决方案。 但是，这可能不是所有情况下的最佳解决方案。
如果问题陈述需要高度技术性的解决方案，产品经理会与开发人员和工程经理讨论相同的问题，并听取他们的建议，以最佳方式解决问题。 如果解决方案需要更改设计级别，则可能会咨询 UX 负责人。 可能是产品经理和用户体验人员组织了一个设计冲刺并选择了该功能的实际用户很好接受的解决方案。 有时问题完全与业务相关，因此需要高级管理层的支持。
因此，可以有多种方法可以最终确定解决方案。 但是一旦成功，产品经理就负责将理论解决方案转化为有效的产品功能。

T = 0（又名产品特性的诞生）

确定特定解决方案后，产品经理与相关团队合作，制定解决方案的基本轮廓。 它可能包括也可能不包括解决方案的原型。 有时它只是一个基本的 Excel 表，其中包含“if-then”条件，用于何时向用户显示特定 CTA 等。
产品经理在相关的 PRD（产品需求文档）中将解决方案转化为文字。 如果功能很小，它可能只是现有 PRD 中的一个段落，用于更大的功能。 有时该功能非常庞大，以至于需要完整的 PRD 才能正确详细说明它。 PRD 由相关团队运行，产品经理确保就该功能达成广泛共识。

T + 15 天

小功能可能需要不到一天的时间才能冻结。 有时，大型功能需要 30 多天才能获得所有人的批准。
让我们平均用 15 天的时间来说明，这是向开发者介绍新生功能的时间。 适当的设计和 PRD 交接发生在项目工作的开发人员被告知 5W（什么、为什么、何时、何地、谁）和测试用例（该功能在发布后应该如何表现或不表现）的情况下.
与工程经理一起为该功能确定适当的发布时间表，其中包括开发结束时间、测试开始时间、报告的错误何时修复以及最终发布日期的截止日期。 然后将整个时间线划分为可衡量的冲刺（通常为 15 天）。 一旦开发人员满意，开发就开始了。

T + 30 天

Sprint 1 结束。 推出了产品功能的一部分。 它可能还不是面向客户的，但当今大多数团队都遵循敏捷方法进行软件开发——这意味着我们以增量和迭代的方式构建。 因此，我们不是在 6 个月内构建一个大功能并立即发布所有功能，而是将整个功能分解为可以独立运行的独立部分（一堆用户故事），并迅速准备好进行审查和迭代。
产品经理通过每日 Scrum 会议和与从事项目工作的相关工程经理进行讨论，确保发布时间表按部就班。 如果有延迟，时间线会相应调整，或​​删除小部分功能以确保按时发布。 在每个 sprint 之后，所取得的进展都会在会议上提交给产品经理和相关利益相关者，并在批准后发布。
一年的 UpGrad 产品管理计划

T + x 天

经过 'n' 次冲刺后，开发完成，整个功能都出来了。 客户没有必要仅在完全发布后才能使用该功能。 他们可能会在 sprint 1 本身结束时使用它。 每个后续的 sprint 周期发布只会使该功能更加强大，并使其更接近预期。
发布一个功能本身就是一门艺术，涉及很多我们将跳过的步骤，只是假设在经过大量的鼓掌和捶胸之后，它向全世界宣布了一个功能已经发布。 这可能与 CEO 本人谈论新发布的完整新闻稿一样复杂，或者可能只是将邮件发送到将使用该功能的特定部门并可能在第一名。 既然该功能已经发布，让我们给这个功能起一个名字——Mr. Feature。

T + y 天

即使在最终发布之后，有时也会出现问题。 曾经光鲜亮丽、价值连城的Feature先生可能已经不一样了，可能有多种原因。 产品周期中的这个阶段是关于支持产品的。 一个美好的一天，发布了另一个版本，导致 Mr. Feature 以意想不到的方式执行（又名成为错误），或者可能删除了另一个依赖于 Mr. Feature 的功能，这导致了错误的行为。 也可能是在制作该功能时，我们低估了将使用它的用户数量，或者没有计划所有用例，现在该功能无法扩展到这么多用户或用例。

这要么是测试团队在他们的定期审查中报告的，要么是某个团队成员在自己使用该功能时发现的。 对于面向客户的功能，这些投诉可能来自产品的实际客户，并通过客户体验团队传达给产品经理。

产品经理试图了解错误的根本原因，并根据优先级安排下一个发布周期的修复——如果它是高优先级甚至后续的 sprint，它可以添加到当前的 sprint 中。 在修复并发布 bug 后，Mr. Feature 将迎来新的一天，尽管是经过改进的形式 - Mr. Feature 2.0 - 感谢产品经理和工程团队。 赞！

T + z 天

据说所有美好的事物都必须结束。 可悲的是，Mr. Feature 也是如此，无论它的版本是什么——也许 Mr. Feature 9.263.75！ 这意味着Feature先生已经过着漫长而幸福的生活，但现在路的尽头就在这里。
这可能是由于各种原因。 出现了一个新功能，这使得对 Mr. Feature 的需求完全多余。 这也可能是一些极端的事情——就像公司认为尽管该功能为其用户增加了价值，但对他们来说不再具有经济意义。

不管是什么原因，都会通知产品经理（或者他是开始讨论的人），不再需要 Feature 先生的服务。 现在，尽管令人心碎，但产品经理有责任让 Feature 先生休息。 虽然在此之前，他需要确保一些事情，比如通知正在使用 Mr. Feature 的用户从特定日期起将无法使用，但新功能在删除 Mr.Feature 之前运行良好，没有其他当 Feature 先生离开时，流量会受到影响，依此类推。

因此，是时候对 Feature 先生说 RIP。 在您的产品管理职业生涯中，您将不得不多次这样做。 但请记住，一个功能的结束是另一个功能的开始，并且循环继续。 这就是产品经营的生活！

从世界顶级大学在线学习产品管理课程。 获得硕士、Executive PGP 或高级证书课程以加快您的职业生涯。

为您推荐的特色课程： 杜克 CE 的设计思维认证课程