为什么产品思维比项目思维更重要？深度解析两者的优缺点

产品经理面临的一项巨大挑战就是如何成功地将组织的思维方式从局限于项目的角度拓展至更加全面和深远的产品视野之中。

什么是项目思维

项目思维观念相当普遍。尤其在软件开发领域，许多人的职业生涯大都集中在项目及项目管理上。大型组织通常都设有专门负责项目管理的PMO部门。这并不令人意外，因为项目管理历史悠久，而我们作为人类也往往习惯于用项目的方式去思考需要完成的事项。

那么，什么是项目思维呢？

项目思维的核心侧重点在于成果的交付，无论是特定功能、软件，还是从飞机到房屋的任何物品。由于聚焦在交付上，因此，主要的评判标准便是时间表和进度安排。项目管理尤其关注产出，其成败很大程度上依赖于我们是否能精准地预估时间表，并按照既定进度成功交付预定的产出。成功通常是按照事前明确的规格和要求来定义的，通过设定一连串的里程碑和时间节点，然后精确地实现这些目标。

什么是产品思维

产品思维采取了一种截然不同的方法。与其专注于产出，产品思维更关注结果。

这无疑是对项目思维观念的一次颠覆。我们不再局限于时间表和日期的束缚，而是将精力全面投入到我们期望达成的目标或需要完成的任务之中。由于我们的关注点是成效而非单纯的产出，因此难以在初期就对交付时间做出精准的限定。其主要原因在于，我们并未必能预先明确如何实现这一目标。

对于长久以来深耕于项目和项目管理领域的人而言，这样的思维方式或许是一次剧烈的转变。许多人会对这种缺乏结构化的时间表和进度安排，以及无法定期进行精密监控的不确定性感到不适。

从项目思维转变成产品思维的好处是什么

那么，摆脱项目时间表，而更注重结果的出现会带来什么好处呢？

首先，不论我们以何种方式去追求，最终追求的核心始终是结果而非过程。产品思维的巨大优势在于，它能确保我们以更为精确和高效的方式实现预期目标。

以项目思维为出发点，我们初步便假设已然掌握如何达成预期成果的路径。基于这一假设，我们会精心构筑一份饱含明确要求和里程碑的项目计划及时间表，进而开始有条不紊地执行。假若我们的初始评估属实，而最初的假设确系最佳解决方案，那么整个流程将会如虎添翼，一切皆能按部就班地走向预设目标。

但如果我们最初的判断是错误的呢？如果我们确定的解决方案无法实现我们所期望的结果呢？

这便是项目思维导致各种问题的关键所在。一旦计划得到启动，特别是在庞大的组织结构中，任何形式的调整和转变都将变得极其困难。一旦日期被确定，一旦各方达成共识的计划深入人心，尽管我们努力适应和学习，更改仍然会变得相当棘手。如果我们不幸错过了预定的时间节点，这可能会给整个团队乃至企业带来巨大的压力和问题。

然而，借助产品思维，我们拥有在实践过程中持续学习和调整的能力。我们不是盲目地跟随预定的时间节点和里程碑，而是把焦点放在持续学习和达成预期成果上。如果某个环节未能如预期般进行，或者用户对某一功能的反应未达预期，我们有能力和灵活性去重新评估，然后进行相应的调整，从而仍然朝着最初预期的目标前进，而不是破坏所有人都依赖的严谨计划。

最关键的是，当遇到问题时（毋庸置疑，问题总是难免的），产品思维赋予我们持续学习和适应的能力，使我们能够始终专注于我们试图达成的具体目标。相对而言，当问题浮现而我们仍受困于项目思维和其对时间表的过度关注时，我们往往会陷入无尽的会议和讨论中，试图弄清楚为何最初的设想失误，并探寻如何才能回归正轨。这种方式最终常常牺牲了产品质量、工作与生活的平衡，以及最终预期的成果，因为我们过分专注于如期交付最初共识达成的产出，不论这是否还继续符合当前的现实和需求。

项目实例

我们已经讨论了许多概念，现在让我们通过一些实例来更生动地阐述这些要点。

在这种情境中，房屋建设无疑是项目管理的经典范例。当我们建造房屋，我们需要从楼层布局图，装饰元素与细节，直至动用巨额资金启动这项建筑工程，历经了漫长而细致的全过程。

项目之初，我们会有建设经理这样的角色，他会预测完工日期，比如是从现在算起大约六个月的时间。这样的预估一定会牵涉到多种多样的变量，也时常会因不可预知的情况而面临进度的调整。然而，得益于房屋建设任务具有明确的输入和可重复的流程，建设经理有能力逐周审查工程进度，并能准确预见项目的完成时间。

值得一提的是，这个建筑项目最后整体延误了约一周的时间，就我个人而言，这几乎可以说是准确地击中了目标。虽然某项任务由于意外延误了工作进度，从而导致了项目整体的数日推迟和一系列连锁反应。但这都在可以接受的范围内，也并非出乎我们的预料。

正因如此，这类建设性的项目显然是高度侧重于项目管理。每一个参与者都明了各自需完成的任务，严谨的时间管理成为关键所在，尤其当你考虑到不仅是我们的住所在建设中，而且整个开发项目也在同步推进。

产品示例

然而，这种项目管理模式是否适用于所有场合？

答案是否定的。

虽然我们多么希望能将软件开发与建筑工程相提并论，但现实状况却并非如此。明确划定的计划和固定的作业流程并不能毫无保留地迁移到产品开发之上，不管我们如何努力去适应。即便明晰的时间表带给我们某种程度的心理安慰，这却不是我们应走的产品开发之路。

在我参与的某一产品项目中，我觉察到了一个关键性的问题，明白这个问题须得解决，方能扩大我们的目标群体并吸引更多的用户。按照传统逻辑，解决之道应是明确需求、划定工作范围，然后着手构建功能。然而，让我所在的组织内的多数人感到困扰的是，我并未沿用这一成规。

当我洞察到问题的实质后，我深入地探究了各类可能的解决方案，从开发新功能到集成第三方软件都在其中。在这个探究过程中，我意识到真正的答案并不在于构建新的功能，反而在于转变我们对待学生的需求设置。我们可以简洁地指引他们完成作品集的各个环节，并允许他们使用任何他们认为能最好展示工作成果的软件工具。这种做法不仅对学生有利，也使我们摆脱了局限于特定软件或供应商的束缚。

若是我们还停留在项目思维的框架里，这样的解决方案是永远也想象不出来的。这个解决方案之所以能够出现，是因为我专注于解决问题和实现预期结果（即吸引更多的应用用户），而非仅仅集中于下一个功能的开发。

这样的成果往往是产品思维所带来的，并且这种思维方式允许在整个流程的任何阶段进行调整和优化。在上述例子中，我们完全避免了任何开发工作。然而，一般情况下，可能需要经历多轮的设计原型，方能摸索到真正有用的解决方案。或者，通过一些初步的开发工作，我们可能更加明确哪些功能真正能带来我们所期待的成果。关键在于，我们在整个流程中始终保持学习和适应，而不是一开始就固定方针，然后死守一个项目计划。

如何正确的从项目思维转变为产品思维

所有产品和产品管理都无可避免地涉及到一定程度的项目管理。我们需要确保各项任务按照既定轨迹有序推进。不幸的是，假设我们可以在一个完全不需要向各方利益相关者和合作伙伴提供确切时间或承诺的环境中工作，是颇为不切实际的。

关键之处在于，仅当我们能以极高的信心水平作出承诺和规划时，才应采取这一步。因此，与其预先承诺特定的行动路线，不如在对正在进行的工作有了充分验证和深入理解之后再作出决定。这通常是在进行了一到两个工作迭代之后的事情。尽管这在整个过程中可能感觉相当晚，但只有到了这个阶段，对时间和资源的估算才真正具有意义。在马蒂·卡根的著作《被激励：如何创造让人们喜爱的科技产品》中，他称这种高水平的承诺为“高完整性的承诺”——我们给予团队足够的时间进行适当的调查和研究，然后才要求他们做出承诺。

与此同时，我们还需努力让其他人认识到产品思维所带来的益处。许多人对于时间表和期限的追求，很大程度上是受到传统思维模式的影响。然而，这有时候是商业运营和预算安排所必需的。因此，我们需要了解时间表在这些特定场合下的作用和意义。如果其目的是促进产品的销售，那么我们应将注意力从特定功能的实现转向更宏观、更战略性的层面。如果其目的是风险管理，也许我们需要帮助人们认识到，真正的风险并非在于错过某一个截止日期，而是在于未能实现我们所寻求的核心价值。

总结来说，产品开发的首要任务是为用户和客户创造价值。在多数情况下，我们并没有确切的知识来预判哪些要素能够带来这样的价值。持有我们可以提前找出正确解决方案的预设，特别是当这一解决方案需要纳入年度规划和预算时，通常是不合实际的。

与项目思维注重于预先设计解决方案，并然后严格按照计划去执行不同，产品思维则始终围绕着实现预期结果来展开。这需要对不确定性和持续学习过程有一定程度的舒适感，这也许相当具有挑战性。然而，如果我们的最终目标是实现真正有价值的结果，而非仅仅达成按期交付的输出，那么这实际上是唯一可行的工作模式。