编辑导读：产品思维是一种解决问题的综合思维，是进一步把问题解决方案产品化的过程，而项目思维注重分析目标，注重对于结果的交付。本文作者结合案例讲述了项目思维和产品思维的区别，以及为什么产品思维更有利于创新型互联网业务，与大家分享。
01 项目思维（Project Thinking）
项目思维相当普遍。许多人，特别是软件开发人员，都将职业生涯花在项目和项目管理上。大型组织通常有PMO（ProjectManagementOffice，项目管理办公室）部门。这并不奇怪，因为这种方式已经存在很长时间了。我们人类倾向于从项目的角度来思考需要完成的事情。
所以什么是项目思维呢？
项目思维的重点是交付。这可以是特定功能或软件的交付，或者是任何产品的交付，从飞机到房子。因为重点是交付，所以主要的衡量方法都是基于日程和时间表。项目管理特别关注产出（output），如何准确预估时间表，能否按照该时间表来交付指定的产出，成为衡量项目管理好坏的标准。项目管理里的“成功”被定义为，预先制定产品规格，设定一个节点日程表，然后按这个计划完成产品交付。
02 产品思维（Product Thinking）
产品思维采用了一种完全不同的方法。产品思维关注的是结果（outcome），而不是产出。
这是对项目思维方式的一个重大转变。它关注的不是时间表和日期，而是我们想要实现的目标或要完成的工作。因为关注的是结果，所以至少在开始阶段，给交付设置一个时间限制要困难得多。主要是因为我们并不一定知道如何提前完成目标。
对于那些习惯于花很多时间专注项目管理的人来说，这种想法可能是相当大的转变。由于没有定期监控的结构化时间点和日程表，许多传统项目管理人员会对因此带来的不确定性感到不安。
03 产品思维的好处
那么，放弃项目时间表而专注于结果，会带来什么好处呢？
首先，它将重点放在我们努力的目标上，而非努力的程度（过程）上。与项目管理只关注完成度不同，它会确保我们不会偏离大方向。所以产品思维的主要好处是能更有效的获得结果。
而项目思维则需要在一开始时就假设，我们已经知道如何去实现预期的结果。根据这个假设，我们创建了一个项目计划和时间表，其中充满了需求和里程碑，然后就开始执行这个计划。如果我们是对的，最初假设的就是正确的解决方案，那么也会得到好的结果。只要按计划完成就行了。
但如果我们一开始就是错呢？如果我们确定的解决方案不能达到希望的结果怎么办？
这就是项目思维让我们陷入各种麻烦的地方。一旦制定了一个计划，要改变它可能是非常困难的，尤其是在大型组织里，想转向和改变计划超级困难。一旦日期确定，大家都同意了一个计划，它就深陷每个人的脑海，尽管我们尽了最大努力去学习和适应，它仍然挥之不去。而如果我们错过了一个日期，就会给团队和企业带来难以置信的问题。
但有了产品思维，我们就能在前进的过程中随时适应。我们不设定日期和里程碑，而是专注于实现结果。如果某件事没有成功，或者客户对某件事反应不佳，我们可以据此调整改进，并继续朝着预期的结果努力，而不会破坏每个人都关注的美好计划。
至关重要的是，当问题出现时（不要自欺欺人，它们总会出现），产品思维让我们能够及时调整，并确保不偏离结果。相反，当问题出现时，如果我们困在项目思维中，仍会把注意力集中在时间表上。我们常常会陷入无休止的会议，试图确定最初的猜测为什么是错误的，以及如何才能回到日程计划上。
这最终会导致工作与生活的平衡被打破、为了进度而牺牲产品和交付质量，因为大家需要集中精力实现最初达成一致的产出（不管这是否仍然是正确的做法）。
04 一个项目的案例
我们已经讨论了很多概念，下面来看一些案例。
建造一座房子就是很好的项目例子。我和妻子去年盖了自己的房子。我们经历了选择平面图的整个过程，选择了房子的所有装饰和细节，花了大量的钱。建造开始时，我们的施工经理（他绝对很优秀）给了一个预计的完工日期：大约6个月以后。
显然，这个预估不会完全符合事实，而且经常会出现一些会把日期推迟的因素，但是由于房屋的建造过程可重复性很高，有了明确的输入，一个优秀的建筑经理可以一周又一周地查看计划，并可以确定他们预期完工的时间。
房子完工比计划推迟了1周左右，完全符合我对项目日期的看法。其中一项交易拖延了，因此工程搁置了几天，还导致了一些连锁反应。但没关系。这是在预料之中的。
对于这种类型的建筑工程，非常适用于项目管理。每个人都知道需要做什么，让人们按时完成工作是真正的关键，尤其考虑到不仅仅是我们的房子，而是整个开发过程。
05 一个产品的案例
但是这种项目管理在任何地方都有效吗？
并不是。
尽管我们很愿意把软件开发看作是一种类似建筑的过程，但事实并非如此。无论如何努力，清晰定义的计划和工作都不能转化为产品开发。虽然在定义良好的时间表中感觉很舒服，但这不是产品开发的正确方式。
我正在开发的一款产品中，遇到了一个问题。我必须解决它，才能更好的让这个产品扩大受众面，接触到更多的用户。传统的方法是收集需求，确定工作范围，然后开发新功能。但我没有采用这种典型的方法，这让我的同事们都感到意外。
这个产品是面向美术设计专业的学生，有一部分需要他们展示自己的作品。当我理解了这个问题之后，就开始研究解决方案，比如是直接开发新功能，还是集成第三方软件来实现，等等。
在研究过程中，我清楚的意识到，解决方案是改变我们要求学生做的事情，而不是开发任何功能。与其关注展示作品的功能，不如简单的要求学生利用他们想要的任何软件来展示作品。实现需求的方法并不是只有一种，只有达到目标才是最重要的。而且，这对每个人都有很大的好处。学生将自己控制他们的作品集，而我们不会被束缚于开发功能或使用特定的软件供应商。
我们永远不会用项目思维来解决这个问题。这个解决方案的产生是因为我关注的是问题和结果（在我们的应用程序上获得更多用户），而不是开发下一个新功能。
这通常是产品思维的结果。它可以在任何时候出现。在上面的例子中，我们避免了不必要的开发工作。但通常可能需要设计几个产品原型来确定可行性。或者可以做少量的开发工作，来了解哪些特性将真正带来想要的结果。无论我们在学习过程的哪个阶段，关键是我们在学习中，而不是预先决定这个过程和遵循项目计划。
06 正确的方法
那么我们应该怎么做呢？如何保持产品开发的重点？
所有的产品和产品管理都涉及到一定程度的项目管理。我们必须持续推进工作。不幸的是，希望在一个客户或合作伙伴不要求完成日期或承诺的环境里工作是不现实的。
关键是，只有在有充足准备和自信时才能做出承诺。因此，当我们确认了需要做的事情，并有机会真正理解它需要付出的代价时，才会做出承诺，而不是在一开始就事先承诺特定的实现计划。这通常是在进入工作的冲刺时段。看起来可能有点迟，但正是在此时估算和计划才真正有意义。
MartyCagan在他的书《启示录：打造用户喜爱的产品》中说，这种承诺是「高度诚信的承诺」。我们应该允许团队在承诺之前有时间进行适当的探索和研究。
我们还需要帮助其他人认识到产品思维的好处。很多人要求日期和时间表是有原因的。部分原因是因为旧习惯。但有时对业务和预算是必要的。所以需要理解时间表在这些情况下的作用。如果这有助于产品的销售，我们应该把重点从特定的功能转移到更高的层次。如果是为了管理风险，也许我们需要帮助人们理解，真正的风险并不是错过一个日期，而是完全错过了我们试图传递的价值。
说到底，产品开发的全部目的就是为用户和客户提供价值。但大多数时候，我们并不知道究竟是什么能带来这样的价值。如果你做年度计划和预算时，认为可以提前一年想出所有正确的解决方案，这是非常不现实的。
项目思维的重点是提前给出解决方案，然后按计划交付，而产品思维关注点在于如何解决问题，所以需要反复试验和调整，寻找对用户价值最大的方案，来保证结果的最优解。项目思维则已经限定了解决方案，后续的行动都是按计划完成它，最终只是能保证实现这个方案，而无法保证问题被正确解决。
产品思维涉及到对不确定性的适应和学习，这可能是相当困难的。但如果我们想要得到正确的结果，而不仅仅是准时的产出，它实际上是唯一的工作方式。
原文地址：https://productcoalition.com/product-thinking-vs-project-thinking-380692a2d4e