项目思维 vs 产品思维，各自的优势是？
以下文章来源于光涧实验室 ，作者Kyle Evans
我们人类倾向于从项目角度去思考：依次做完那些需要我们完成的事情即可。
项目思维的重点在于交付，而产品思维关注结果。这两种思维方式之间可能存在着很大的转变。
当问题出现时，哪种思维更好？哪种思维更能帮助我们靠近我们试图提供的价值？希望读完此文对你有所启发。
来源：光涧实验室，原文载于Medium
标题：Product Thinking vs. Project Thinking
作者：Kyle Evans
文章约3400字 阅读需要8分钟
一个产品经理（或组织）面临的最大挑战之一，就是如何将思维模式以及文化特性从项目层面提升到整个产品的高度。
▋项目思维
项目思维相当普遍。像大型组织通常都有PMO部门——项目管理办公室，还有比如像从事软件开发的工作人员，他们职业生涯的大部分时间都专注于项目执行以及项目管理。
这并不奇怪，因为项目管理已经存在了很长时间。且我们人类倾向于从项目角度思考：依次做完那些需要我们完成的事情即可。
那么项目思维是什么呢？
项目思维的重点在于交付。可以是对于特定功能或软件的交付，或者说实际上是对任何东西的交付。从飞机到房屋亦是如此。因此由于专注在交付上，主要的衡量标准就是时间轴和日程表。
项目管理专注于输出，并通过我们先前对时间轴估算的准确程度来衡量，再按照日程表交付指定「产量」。在这样的情况下，能否成功很大程度上取决于是否预先制定产品规格，设定具有一个个节点的日程表，以及按照这些日期完成交付。
▋产品思维
产品思维则采用了完全不同的方法。产品思维并不关注产出（output），而是关注结果（outcome）。
与项目思维相比，这是一个重大的思维转变。我们并不关注时间表和日期，而是关注想要实现的目标或要完成的工作。由于我们专注于结果而不是产出，所以在前期，对交付时间做出约束会比较困难。这主要是因为前期我们不太需要知道我们将如何实现目标。
这种思维方式可能是一个很大的转变，特别是对于那些花费大量时间专注于项目执行和项目管理的人。对于没有定期监控的时间轴和日程表，许多人可能会对这种不确定性而感到不安。
▋产品思维的好处
那么放弃项目时间表，改为关注结果会带来什么好处呢？
首先，无论我们以怎样的方式去实现目标，从根本上来讲我们都要向着结果前进。产品思维的主要好处是确保我们更高效地获得结果。
而项目思维，则需要在一开始时就假设，我们已经知道如何去实现预期的结果。根据这一假设，我们会创建一个具有目标要求和工作节点的项目计划和时间轴，然后开始执行。
如果我们做得正确，且我们最初的设定在事后被证明是正确的解决方案，那么我们就会得到好的结果。我们要做的也只是执行计划。
但如果我们最初的计划是错的该怎么办？我们确定下来的解决方案无法达到我们渴望的结果怎么办？
这就是项目思维让我们陷入各种麻烦的地方。一旦我们制定了计划，尤其是在大型组织中，可能就很难转移和改变。在确定好日期并且每个人都对计划表示同意的情况下，不管我们尽多大努力学习和适应，这样的计划通常会根深蒂固于每个人的大脑中。且如果我们最终错过了某个日期，那么它可能会给团队和业务进度带来很大的影响。
但是，使用产品思维，我们能够随时学习和适应。我们不去确定日期和工作节点，而是专注于研究和实现结果。如果某些事情没有成功，或并没有得到用户积极的反馈，我们就去处理这件事，去适应并仍朝着我们预期的结果努力，而不用担心破坏了所有人的美好计划。
更重要的是，问题出现时（不要自欺欺人，问题总是会出现的），产品思维使我们能够学习和适应，并专注于我们要努力实现的结果。相反的，问题出现时，当处在被时间表困住的项目思维中，我们常常会陷入无休止的会议，并试图搞清楚为什么我们的初步猜测是错误的，以及我们如何重新按计划进行下去。
这最终会导致牺牲产品的质量，工作与生活的平衡以及获得的结果，因为我们不得不继续专注在交付最初商定的产出上，不管这是否仍然是正确的事情。
▋项目示例
我们已经讨论了很多概念的东西，那么现在让我们看一些例子来更好地理解这些概念。
关于项目的一个很好的例子是建造房屋。我和我妻子去年建好了我们的房子。我们经历了包括从选择平面图到选择房子里的所有装饰和细节的整个过程，之后也投入了很多钱来推动这项工程。
当我们开始时，我们的施工经理（绝对优秀）给我们估计了工期，大约6个月。显然，这个估计并不会完全符合现实，通常可能会出现导致工期拖后的状况，但由于房屋的建造是一个具有明确输入的且可重复的过程，一个好的施工经理可以逐周查看计划并确定他们何时可以完成工作。
我们的房子大约比预期晚了一个星期建完，完全符合我对项目日期的看法。其中一项交易拖延了，因此工程搁置了几天，并且产生了一些连锁反应。但那没关系，这是在预料之中的。
对于这种类型的建筑工程，非常适用于项目管理。每个人都知道需要做什么，按时完成是关键，尤其是当我们考虑的不仅是要居住的房子，而是整个开发过程时。
▋产品示例
但是这种项目管理在任何地方都有效吗？
并不是这样。
在做产品过程中，如果我发现了一个关键问题，传统的解决方法是收集需求，确定工作范围，然后构建产品功能，但我并没有采用这种典型的方法。
在我了解了这个问题后，我便开始研究解决方案，从构建功能到集成第三方软件开发，但我发现解决方案实际上是不开发任何东西。与其构建新功能或集成其他人的软件（在本例中，是为了展示学生的作品集），解决方案其实是改变我们要求学生做的事情。
与其专注于做作品集的工具，我们可以简单地要求他们创建作品集，然后利用他们想用的任意软件来展示他们的作品。这对每个人都有很大的好处。学生们可以为自己的作品集做主，我们也可以不用局限于构建软件或使用任何特定的供应商。
用项目思维永远不会解决这个问题。这个解决方案产生的原因是：我关注的是问题及其结果（在我们的应用程序上获得更多用户），而不是构建另一个功能。
这种结果通常在产品思维下所产生，且任何时候都有可能发生。在我的自身经历中，我们避免了做任何开发工作，通常只需要用几个设计原型就可以弄清楚什么是可行的。或者我们可以做少量的开发工作来学习哪些特性将真正驱动我们得到想要的结果。
最关键的是我们在这个过程中学习到了东西，而不是预先决定进程并遵循项目计划。
▋正确的处理方式
那我们改怎么做？如何保持产品开发专注重点？
所有产品和产品管理都涉及一定程度的项目管理。因为（不幸的是），我们的利益相关者以及合作伙伴一定还是会期待某些日期或承诺。
关键是只有在我们高度自信的情况下才可以做出承诺和项目计划。因此，我们要在验证了我们正在做的事情，并且有机会去真正理解它将采取哪些措施的情况下，作出承诺，而不是事先承诺某些特定的路径。
通常是在进入工作的冲刺时段。看起来可能有点迟，但正是在那时估算和计划才真正有意义。Marty Cagan 在他的书《启示录：打造用户喜爱的产品》中称这种承诺是「高度诚信的承诺」。我们允许团队在进行承诺之前有时间进行适当的探索和研究。
我们还需要让其他人了解采用产品思维的好处。很多人要求提供交付日期和时间表是有原因的，部分原因是因为旧的习惯，还有考虑到业务和预算。
因此，在这些情况下，我们需要搞清时间轴的作用。如果是为了帮助销售产品，我们应该将重点从打造一个特定的功能提升到更高级别。如果是为了管理风险，也许我们需要帮助人们理解真正的风险并不在于错过日期，这完全忽视了我们试图提供的价值。
结语
最后，我们要明白产品开发的目的就是为用户和消费者创造价值。大多数情况下，我们并不确切地知道什么才会带来这个价值。如果你在做年度计划和预算编制时，认为我们可以预先一年提出正确的解决方案，那是非常不现实的。
项目思维的重点是预先提出解决方案，然后按计划进行交付，但产品思维会将重点放在结果上。这涉及一定程度的不确定性和对学习能力的要求，可能相对困难。但是，如果我们想要获得好的结果，而不仅是准时产出，那么它实际上是唯一的工作方式。