CategoryResourceRepost/极客时间专栏/邱岳的产品实战/模块四：产品会客厅——场景化处理你的产品疑难杂症/产品会客厅 | 需求评审怎么做，如何区分什么是真的用户需求？.md

## 【写在前面的话】

你好，我是邱岳。

产品会客厅是一个实战问答的板块，我想要创造的是一个集思广益、共同探讨问题、答疑解惑的互动环境。

在“产品实战”和“产品手记”两个专栏的留言中，我看到了很多开发工程师朋友的留言。大家的留言或是说起自己在产品上的一些思考与心得，或是谈及自己在转行产品经理，正在学习产品的知识。还有一些朋友聊到了跟产品同事相处的方式，甚至是一些龃龉。一位朋友甚至戏称自己学习产品知识，就是为了有理有据地怼产品同学。

我在之前的文章中也跟大家分享过，产品经理与开发工程师由于思维方式与关注领域的不同，产生一些逻辑上的不一致是难免的，但本质上依然是一种合作与共赢的关系。**还是那句话，“兄弟阋于墙，外御其务”，我们在关起门可能会吵起来，但是在做产品的时刻，我们依然是兄弟，是朝着同一个业务目标努力的。**

今天的两位同学不约而同地提到了一个开发与产品唇枪舌剑的经典场景：需求评审会。我在之前也写过“需求评审会”的系列文章。不过在那篇文章中，我更多地是从自己作为产品经理的角色出发。所以，今天我想邀请池老师，一位身经百场需求评审会的开发者与决策者，来从他的角度来谈一谈，需求评审会到底应该怎么开。

## 【第四期问题】

恭喜第四期的幸运用户 @zi @光明 @june，你的提问被部分抽取成为本周的实战问题。极客时间将送出价值68元的极客福袋一份。1个工作日之内，工作人员会与你取得联系。

### 用户留言

用户@zi @光明 @june 提问。

<li>
我是一名Java后端工程师，在需求评审的时候，遇见逻辑不一致应该如何处理？哪些部分应该坚持，哪些部分应该让步？
</li>
<li>
作为产品萌新，在开需求评审的时候，经常被资历深的开发同事挑战，被怼到说不出话，一个会议时常陷入了无休无止的质疑之中，耗费了整个下午。如何让我提的需求更为靠谱呢，更容易说服我的开发同事们呢？
</li>
<li>
如何区分什么是真的用户需求，什么是伪需求？
</li>

## 池建强回信

@zi @光明 @june 你们好！

我们来看一下第一个问题。

> 
我是一名 Java 后端工程师，很希望在这个专栏里学习一些产品的内容。我的问题是在需求评审会的时候，遇见逻辑不一致应该如何处理？哪些部分应该坚持,哪些部分应该让步呢？


我们先来回答一下具体问题，再谈谈技术和产品的逻辑关系。

需求评审的时候，如果工程师发现“逻辑不一致”的问题，先要去判断是哪里的逻辑不一致：是产品的 UI 和交互出现了逻辑上的不一致，还是后端的业务处理逻辑不一致，或者是 UI 和业务逻辑处理上的不一致，亦或是之前设计的产品逻辑和这次需求评审里的业务逻辑不一致。

把这些搞清楚了，并且确认出现了逻辑上的不一致，组织好语言，直接和产品经理沟通就好了。如果你在逻辑上是对的，产品经理没有理由不采纳你的建议。如果你没有把握，或者口头表达能力较弱，也可以把自己的思考写下来，通过文档的方式发给对方，最终达成一致。

逻辑上的不一致会引发很多问题，这个没什么可以让步的，让步就是对产品和用户不负责任。**真正需要平衡的是产品的实现效果、交互的优化、功能的改进等，与技术实现难度上的平衡。**

这需要工程师和产品经理一起取舍，到底是工程进度更重要，还是功能实现更重要，然后做需求裁剪，或者是延长工期等。

下面我们来谈谈工程师是否要懂产品。**事实上，一款产品的成败，并非单独取决于某一个因素，产品领域的成败取决于各种环境变量，更取决于掌舵人的价值选择与世界观。** 只有产品经理和工程师们都足够优秀并且合作无间，才有可能创造出一款优秀甚至伟大的产品。

技术人员懂产品和业务，会带来很多好处。好的产品最好交到一个有技术能力、有经验的人员手上，会让大家更加放心。

举例来说，你是一个技术人，现在交给你的任务是把两个盒子装到另一个看起来比较难装的盒子里。你如果用技术思维去解决，可能会想到，我是不是把那个大盒子拆开搞大一些，然后看看如何塞进两个小盒子等等。

但是，你如果真的了解产品和需求，就会跳出那个技术的框，从更高的维度考虑问题。比如把两个小盒子拆开或重新组装，这就像你买了东西，把包装扔掉，再放到袋子里，就可以非常轻松的完成任务。

只有懂产品、业务和需求背景，才能去做出一些不用技术就可以轻松解决问题的决策。

**有时候我们常说，技术人钻到牛角尖里去了，就是沿着一个技术问题，一直去求最优解，最终变得异常复杂。** 如果你能跳出技术人的思维，从产品的思维，或者是从用户的角度出发，可能会找到一个不用技术的解决方案，或者说把以前的技术方案成功的复用到当下的问题上来。

技术人学习一些产品知识，有助于做出更好的产品，当然我们也要随时保持开放的心态，并尊重产品经理的意见，就像产品人员也应该相信工程师的技术决策一样。

再来看看第二个问题。

> 
作为产品新人，在开需求评审的时候，经常被资历深的开发同事挑战，被怼到说不出话，一个短会议时常陷入了无休无止的质疑之中，耗费了整个下午。如何让我提的需求更为靠谱，更容易说服我的开发同事们呢？


产品“新人”并不是提出不靠谱需求的借口，新人需要学习和成长，新人会犯错，但这个过程不应该在正式的需求评审会上。如果你的产品需求出现了逻辑上的问题，或者压根就是不靠谱的需求，这样的需求是不应该出现在评审会上的，那样只能给自己带来挫败感，并且浪费所有人的时间。

如何提出更靠谱的产品需求呢？我的建议是下面这样的。

找到自己的导师，很多公司在新人入职后会为他指定一个导师，如果没有，你可以默认自己的直属上级作为导师。

你自己设计的产品需求，首先自己要 Review，是不是达到了产品的目的，是不是满足了用户的需求，逻辑上有没有问题，技术上是否可行，是否真正完成了上级交代的任务。

如果这些答案都是肯定的，然后拿着你的需求和你的导师先去交流，一般情况下他会给出更可行的意见和建议，弥补你的思维死角，你根据这些观点去补充和完善你的需求，然后再和导师确认。如果技术实现上拿不准，也还要去征求工程师的意见。一切准备妥当了，再发起需求评审会，情况就会完全不一样了。

产品经理并不需要说服开发的同事，产品经理应该是和工程师站在一起，把这个产品做好。如果大家觉得你是这么靠谱的人，自然会乐意和你合作。工程师们心疼的是被浪费的时间，痛恨的是不靠谱的需求，避免了这两点，你们就可能在一起做出一款优秀的产品了。

关于第三个问题。

> 
如何区分什么是真的用户需求，什么是伪需求？


这个问题实在是太大了，产品名宿张小龙、周鸿祎都曾经写过长长的文章或通过演说来阐述自己的产品观。我在这里简单的谈谈自己的看法。

构建一款产品的目的，肯定是为了解决用户的实际需求，但是需求并不是只有一种。**从大的层面，我们可以把需求分为两种，一种是用户目前实实在在的需求，另一种是用户不知道的，产品经理创造出来的需求。**

优化和解决老百姓的衣食住行问题，都属于第一种需求，但这些需求里又可以分为**强需求、弱需求和伪需求。**

什么是**强需求？** 人们的吃饭、出行、教育、情感、社交等领域衍生出来的很多需求都是刚需，没有这些东西，人们的生活会收到严重的困扰，甚至无以为继，这是强需求。

对用户来说可有可无，用不用都行，没有也不会受到太大影响的需求，我们可以称之为**弱需求，甚至是伪需求。**

现在市场上很多产品是针对弱需求的，因为强需求的产品大家都做得差不多了。弱需求的产品能不能做？能。如果你有强大的产品能力和渠道能力，可以培养用户的习惯，由弱变强，形成最终的强需求产品。如果没有强大的渠道，那最好去挖掘用户的强需求，并构建相关的产品。

需求分析不能忽视的另一个因素是使用频率。一个刚需产品，如果半年用户才会用一次，或一年完成一次交易，那就要去看这个市场是不是足够大，产品附加值是不是足够高。

如果答案是否定的，很可能是个**伪需求。** 看一下市面上的产品就知道了，大部分产品都试图满足用户的低频需求或者伪需求，所以那么多创业公司相继消失也就不足为怪了。

还有一种需求是用户压根不知道的，或者当下没有感知的，直到开始使用了才发现自己有这样的需求。

比如用户只是希望一匹更快的马，但是想不到汽车；用户希望更大的屏幕和触摸笔，不会想到 iPhone 和 Android。**能够创造出这种需求和产品的产品经理，都是开创时代的人，他们对技术、产业、趋势有很好的前瞻性，同时具备强大的执行能力，最后，他们运气都很好。**

祝你好运。

池建强

2018.08.31

极客邦科技/极客时间

## 精选分享

<img src="https://static001.geekbang.org/resource/image/ff/a1/ff866eab2799cddfaac391a9024317a1.jpg" alt="" />

**邱岳评论：很棒的思考。我也认识这样一位朋友，他的个人签名就是“件件有着落，事事有回音”，十分靠谱的一个人。**

## 下期话题

你有没有遇见让你眼前一亮的产品呢？有没有试着对它做过竞品分析呢？

<img src="https://static001.geekbang.org/resource/image/06/ad/0627f457a076aff118d7fa36981d73ad.jpg" alt="" />