我们的产品是如何走向成功与失败的？本文作者从这一问题出发，结合自身项目实践，对推动产品成功的相关因素展开了分析探究：对问题进行足够的理解、深入的调研、合适的用户研究。

在开始写公众号的前期，有很多小伙伴问关于项目管理的问题，因此写了篇关于项目的文章。从整体的项目流程到项目研发执行的细节分两篇来介绍，项目管理及产品研发流程。

01

在过去几年中，包括我在带创新部的时候，做了大大小小上百款产品。也做了不少成功的产品，为了总结一套成功的经验进行复刻，我一直在对自己的工作方式、时间分配做大量的反思和总结。

正好前两天在知识星球更新了「好的产品经理与差的产品经理」的区别，有一条也谈及于此。

通常情况下，我们的产品项目预研及产品实现过程的标准流程是这样。

详细的产品研发实现标准流程是这样。

以上流程均较为详细，为了方便我们今天的讨论，将其简化压缩为一般流程。

02

我们一个产品项目，一般是市场调研，分析需求，罗列问题，明确问题，设计方案，研发，测试，生产，上市。

将一个泛化的问题逐步明确，缩小范围，然后设计方案解决它。

实际项目过程中，产品经理、研发工程师、测试工程师、市场人员会拆分出各自的任务项。

并且从方案设计到系统性测试，期间我们会遇到很多问题，避免不掉回过头去修改、重新再来，具体表现是这样的。

在项目管理的旧文中，整个流程是从项目导入开始的，整个周期约 110 天。

如果包含前期的调研、需求分析、定义问题，这个周期可能还需要更长，根据具体的情况而定，比如公司和我本有有资源的情况下，进度会比较。

越是项目靠前的阶段耗费的时间越长，因为问题不明确，我们需要调研、搜集数据、需求问题验证。

如果想要快速的切入到项目前期的工作并取得相对的结果，需要产品经理完善相关的公司流程、制度。

比如建立市场信息收集制度和指导文档，与忠实的消费者建立强力的链接等等。

项目前期的内容不是本文的重点，我们后期讨论。

所以假设，一个产品项目从前期想法到最终落地时间为 100 份。我通常的时间分配是这样的。

我所有的成功项目，基本都是这样，将 30～40% （视项目情况动态调整）的时间精力放在开始方案设计之前。

因为只有对问题进行足够的理解，深入的调研，合适的用户研究，所设计的解决方案才会满足用户需求。

03

但，即使是这样，实际的研发过程中仍然会遇到许多相对细小以及未充分预计到的问题，并且我认为在咱们 AI 硬件类产品中会不可避免的发生。

因此，这个流程就会增加一个反复的过程，类似这样：

既然解决方案是在对问题足够多的调研、研究和理解基础上产生的。那么，为什么依然会这样呢？

我认为有这么三个主要原因：

1. 需求洞察的难度

用户具有异质性、情境性、复杂性等特点，而用户群又具备群体性。需求探查的时候，需我们与大量的消费者接触，进入消费的脑海中，洞察他们的行为以及背后的原理。

用户需求，在旧文“需求系列”中有详细的阐述。

然而，洞察需求，找到问题的本质，是非常非常困难和复杂的。

我们产品经理通常有这么两种情况定义需求：按照自己的理解，按照用户的描述。

我们很多产品经理经常足不出户，全靠在网上搜集信息，拍脑袋，甚至数据分析都很少做，更甚至都没有建立完善的数据收集制度和工具，来自运营、销售、市场、商务等部门的数据全部原封不动的躺在各部门睡大觉。

产品经理其实是个非常苦的岗位，不仅要对内，还需要对外。比如我们做无人机的时候，经常跋山涉水跟踪观察/访谈用户，以及测试。

田间地头蹲守看我们农民伯伯怎么操作无人机，休息频率，请教农作物虫害特性等等。

那段时间，如果把我扔在煤堆里，不拿拐棍捅一下，根本找不到我。

用户往往描述的问题的时候往往是他们想要解决问题的方案，而不是方案背后的问题本质。我们产品经理经常到这里就止步不前了，以为找到了问题的本质。

洞察需求是非常消耗时间和耐力，非常痛苦的一个过程，我们需要不断的问“为什么”“为什么”“为什么”。

2. 管理层的任性

我们产品经理一定遇到过不少这类情况：Boss 改、增需求。

这个原因有很多，以及我们产品人该怎么应对，将在下一篇介绍。

多数情况下，我们都在顶着老板的压力被动接受这样一个现实。

3. 研发过程中继续需求求证

以前在群里讨论应该提过这个话题，我们产品经理并不是在产品立项进入研发阶段就放手了，我们会继续跟踪用户，做持续的用户探求。并且持续探求用户问题的本质。

除此之外，我们研发过程中，会产生样机，我们也会拿着样机找到我们的中式用户进行体验。

这其中，可能会修正之前的问题定义，也可能会修改现有的解决方案。

以上，是我觉得三种比较常见且重要的影响因素。我自己将这种称之为「不可避免的研发行为」。

无论是研发过程中、从系统性测试回到方案设计，还是从小批量到研发的反复。还算可以接受，因为基本上我们的产品项目还算跑在通往成功的路上。

04

真正让我们头疼，且常常失败的产品项目是这样的：

这种从系统性测试或者小批量回到问题定义的研发产品项目流程，极其可怕。往往意味着我们前面所作的一切都是无用功，需要推到一切从头再来。

这无论是对于产品经理，还是对研发工程师是致命的打击。

可能有不少产品经理听到过 RD 这么抱怨过：“搞了一年，啥结果也没有”。因为实现产品以及产品在市场上的成功是我们的资本，是职场的筹码。

而这种情况经常发生在这样的行为下：

更为极端的情况下，是这样的：

在我所有的产品经历中，基本上所有失败产品都是在这种情况下产生的。

为此，借助与不少公司老板、高层聊天的机会，探究了一下他们的工作方式。得出的结论逃不过上面两种时间分配。

第一种的时间是我做的大致统计，具体每家公司都有差异。

当然，我探访的老板们，他们也谈市场调研、需求分析、用户研究，培养公司忠实的消费者用户群。但也基本是停留在做一点儿或基本不做。

其实公司管理层也都意识到方案设计前期需求洞察的重要性，为什么却投入很少的精力甚至直接忽略呢？

除前文需求洞察艰难这一小节所讲的原因外，还有如下几个原因：

1. 需求洞察部分工作难以量化，可视性不佳

需求洞察部分的工作难以量化，公司管理很难通过相对比较可行性的量化指标（KPI）。比如，敲代码，ID 设计具有很强的视觉化的反馈，而需求洞察则很难。

而这就导致管理层认为这部分是浪费时间，特别是在「精益创业」「快速迭代」等思潮的影响下更加剧了这种情况的恶化。

需求洞察的结论又往往是比较短小的文字描述，其工作量领导无法直接感知出来，项目评审会上，无具象化的产出很难反映出产品经理的付出。描述性的、抽象性的东西显得很空洞且简单。

其实我们产品经理本身又何尝不是如此呢？

举个栗子：

为什么很多产品经理到处找 PRD 文档模板，其中有一个原因就是是希望丰富自己的输出，显得自己专业，工作可量化。

回想一下，每当自己输出文档的时候，是不是有一种总感觉缺点儿什么的感觉。

2. 管理层的固有观念

管理层认为需求洞察其实很简单，以及对需求获取的流程产生认知偏差。

以为，出去跑一下供应链就可以获取信息，走访一下市场等等类似方式即可。

比如，我曾经有个领导，周四下的任务，下周的周三就来问，什么时候可以出方案？什么时候立项？

其实这种就是典型的将产品项目工作移到解决方案的实现上，直接跳过了需求洞察、需求评审、可行性分析，风险预案等产品前期工作。

这种行为我认为也是不可避免，一是个人工作经历和对岗位内容认知的缺乏；二是，老板也有老板，他需要拿到具体、可视、可量化的东西向他的老板回报。

我们产品经理需要对此有充分的认知，并努力做好沟通与数据分析，不是为了证明老板错了，而是用你具体的详细，可量化的目标物与老板沟通。

最后

需求洞察是一项非常艰苦、非常艰难的工作，是一个通常被价值低估的产品工作内容。

我相信好的需求洞察是保证产品项目取得成功的重要因素之一。

并且，我相信花大量时间在产品方案前期的需求工作部门效果显著并且降低我们无效用的研发投入。

作者：AI 产品观，前实体行业「需求导向型产品经理」，现「AI 硬件产品经理」（AIPM），公众号：AI 硬件产品官。

本文由 @AI 产品观 发布于人人都是产品经理。未经许可，禁止转载。

题图来自Unsplash，基于CC0协议。