一个产品经理（或组织）面临的最大挑战之一就是如何将思维模式以及文化特性从项目层面提升到整个产品的高度。

项目思维

项目思维相当普遍。特别是对于从事软件开发的工作人员，他们职业生涯的大部分时间都专注于项目执行以及项目管理。大型组织通常有PMO部门——项目管理办公室，专注于项目管理。

这并不奇怪，因为项目管理已经存在了很长时间。且我们人类倾向于从项目角度思考：依次做完那些需要我们完成的事情即可。

那么项目思维是什么呢？

项目思维的重点在于交付。可以是对于特定功能或软件的交付，或者说实际上是对任何东西的交付。从飞机到房屋亦是如此。那么由于专注在交付上，主要的衡量标准就是时间轴和日程表。

项目管理专注于输出，并通过我们先前对时间轴估算的准确程度来衡量，再按照日程表交付指定「产量」。

在这样的情况下，能否成功很大程度上取决于，是否预先制定产品规格，设定具有一个个节点的日程表，以及按照这些日期完成交付。

产品思维

产品思维则采用了完全不同的方法。产品思维并不关注产出（output），而是关注结果（outcome）。

与项目思维相比，这是一个重大的思维转变。我们并不关注时间表和日期，而是关注想要实现的目标或要完成的工作。

由于我们专注于结果而不是产出，所以在前期，对交付时间做出约束会比较困难。这主要是因为前期我们不太需要知道我们将如何实现目标。

这种思维方式可能是一个很大的转变，特别是对于那些花费大量时间专注于项目执行和项目管理的人。对于没有定期监控的时间轴和日程表，许多人可能会因这种不确定性而感到不安。

产品思维的好处

那么放弃项目时间表改为关注结果会带来什么好处呢？

首先，无论我们做出什么努力去实现目标，从根本上来讲我们都要向着结果去前进。产品思维的主要好处是我们确保我们更高效地获得结果。

而项目思维，则需要在一开始时就假设，我们已经知道如何去实现预期的结果。根据这一假设，我们创建一个具有目标要求和工作节点的项目计划和时间轴，然后开始执行该计划。

如果我们做的正确，且我们最初的设定在事后被证明是正确的解决方案，那么我们就会得到好的结果。我们要做的也只是执行计划并取得成果。

但如果我们最初是错的该怎么办？我们确定下来的解决方案无法达到我们渴望的结果要怎么办？

这就是项目思维让我们陷入各种麻烦的地方。一旦我们制定了计划，尤其是在大型组织中可能就很难转移和改变。

在确定好日期并且每个人都对计划表示同意的情况下，不管我们尽多大努力学习和适应，这样的计划通常会根深蒂固于每个人的大脑中。且如果我们最终错过了某个日期，那么它可能会给团队和业务进度带来很大的影响。

但是，使用产品思维，我们能够随时学习和适应。我们不去确定日期和工作节点，而是专注于研究和实现结果。如果某些事情没有成功，或并没有得到用户积极的反馈，我们就去处理这件事，去适应并仍朝着我们预期的结果努力，而不用担心破坏了所有人的美好计划。

更重要的是，问题出现时（不要自欺欺人，问题总是会出现的），产品思维使我们能够学习和适应，并专注于我们要努力实现的结果。

相反的，问题出现时，当处在被时间表困住的项目思维中，我们常常会陷入无休止的会议，并试图搞清楚为什么我们的初步猜测是错误的，以及我们如何重新按计划进行下去。

这最终会导致牺牲产品的质量，工作与生活的平衡以及最终结果，因为我们不得不继续专注在交付最初商定的产出上，不管这是否仍然是正确的事情。

项目示例

我们已经讨论了很多概念的东西，那么现在让我们看一些例子来更好地理解这些概念。

关于项目的一个很好的例子是建造房屋。我妻子和我去年建了我们的房子。我们经历了包括从选择平面图到选择房子里的所有饰面和细节的整个过程，之后也投入了很多钱来推动这项工程。

当我们开始时，我们的施工经理（绝对优秀）给了我们估计的完成日期。大约6个月。显然，这个估计并不会完全符合现实，通常可能会出现导致工期拖后的事情，但由于房屋的建造是一个具有明确输入的且可重复的过程，一个好的施工经理可以逐周查看计划并确定他们何时可以完成工作。

我们的房子大约比预期晚了一个星期建完，完全符合我对项目日期的看法。其中一项交易拖延了，因此工程搁置了几天，并且产生了一些连锁反应。但那没关系。这是在预料之中的。

对于这种类型的建筑工程，非常适用于项目管理。每个人都知道需要做什么，按时完成是关键，尤其是当我们考虑的不仅是要居住的房子，而是整个开发过程。

产品示例

但是这种项目管理在任何地方都有效吗？

并不是这样。

虽然我们很想把软件开发看作是建筑工程，但事实并非如此。无论我们多么努力，明确定义的计划和工作都不能转化为产品开发。虽然在明确的时间表可以带来很大的舒适性，但这并不符合我们进行新产品开发的情况。

在我一直做的一个产品中，我发现了一个关键问题，并且知道我们需要解决这个问题，以便继续扩大我们的受众范围并接触到更多的用户。

传统的方法是收集需求，确定工作范围，然后构建特性。但令我所在组织的许多人感到震惊的是，我并没有采用这种典型的方法。

在我了解了这个问题后，我便开始研究解决方案，从构建特性到集成第三方软件。

当我这样做的时候，我发现解决方案实际上是不开发任何东西。

与其构建新功能或集成其他人的软件（在本例中，是为了展示学生的作品集），解决方案是改变我们要求学生做的事情。

与其专注于做作品集的工具，我们可以简单地要求他们创建作品集，然后利用他们想用的任意软件来展示他们的作品。

这对每个人都有很大的好处。学生们可以为自己的作品集做主，我们也可以不用局限于构建软件或使用任何特定的供应商。

用项目思维永远不会解决这个问题。这个解决方案产生的原因是我关注的是问题及其结果（在我们的应用程序上获得更多用户）。而不是构建另一个特性。

这种结果通常是在产品思维下所产生的。且任何时候都有可能发生。在我上面的例子中，我们避免做任何开发工作。但通常需要用几个设计原型来弄清楚什么是可行的。或者我们可以做少量的开发工作来学习哪些特性将真正驱动我们得到想要的结果。

无论我们在哪个过程中学到东西，最关键的是我们在这个过程中学习到了东西，而不是预先决定进程并遵循项目计划。

正确的处理方式

那我们怎么做呢？如何保持产品开发专注重点？

所有产品和产品管理都涉及一定程度的项目管理。我们必须让工作进行下去，并且（不幸的是），我们的利益相关者以及合作伙伴一定还是会期待某些日期或承诺。

关键是只有在我们高度自信的情况下才可以做出承诺和项目计划。因此，我们要在验证了我们正在做的事情并且有机会真正理解它将采取什么措施的情况下，作出承诺，而不是事先承诺特定的路径。

通常是在进入工作的冲刺时段。看起来可能有点迟，但正是在那时估算和计划才真正有意义。

Marty Cagan 在他的书《启示录：打造用户喜爱的产品》中称这种承诺是「高度诚信的承诺」。我们允许团队在要求承诺之前有时间进行适当的探索和研究。

我们还需要让其他人了解采用产品思维的好处。有很多人要求提供日期和时间表是有原因的。部分原因是因为旧习惯。对于业务和预算来说是必要考虑时间的。因此，在这些情况下，我们需要搞清时间轴的作用。

如果是为了帮助销售产品，我们应该将重点从特定功能提升到更高级别。如果是为了管理风险，也许我们需要帮助人们理解真正的风险并不在于错过日期，这完全忽视了我们试图提供的价值。

最后，我们要明白产品开发的目的就是为用户和消费者创造价值。大多数情况下，我们并不确切地知道什么会带来这个价值。如果你在做年度计划和预算编制时，认为我们可以预先一年提出正确的解决方案，那是非常不现实的。

项目思维的重点是预先提出解决方案，然后按计划进行交付，但产品思维会将重点放在结果上。这涉及一定程度的不确定性和对学习能力的要求，这可能相当困难。但是，如果我们想要获得好的结果，而不仅是准时产出，那么它实际上是唯一的工作方式。