企业目的：

1.考察求职者对项目设计是否有自己的理解，是否能权衡商业价值和用户价值；

2.考察求职者如何处理工作中的沟通问题、分歧问题，是否有成熟的思想。

回答思路：

1.首先应该了解设计总监(产品经理)在思考这个问题的出发点是什么，一般的分歧都是由于各自考虑的侧重点不同所导致；

2.阐述自己的观点，也要接受别人的观点，以寻求问题的平衡；

3.应该主动提出自己合理的思考方案，以供对方参考，也应该耐心听取对方的意见进行斟酌和修改；

4.决不能直接说自己不接受他人意见，也不能说老板说什么就做什么”的话。

用你自己的优势打败设计总监的坚持

要和产品经理阐述自己的观点，在碰撞中才能更好

需求一般分为【战略性需求】，【功能性需求】，【业务性需求】，【体验性需求】。其中战略性需求一般由公司领导提出，产品来执行；功能性需求则为产品的核心功能；业务性需求则与运营相关，主要用于拉新促活，提高留存；体验性需求则用于提高用户体验；需求的优先级一般为：战略性>功能性>业务性>体验性。回答时，可以这么说：
需求包括：
第一，老板提出的战略性需求。
第二，产品经理根据产品方向规划需求。
第三，推广规划的活动和数据分析出来一些需求。
第四，用户访谈提出需求。
第五，其他参与者和关注者反馈的需求。
介绍一款你觉得好的产品？
这个问题真是100%会被问到的题目，特别是0-3岁的产品经理面试；一定要提前准备，提前准备、提前准备...重要事情上说n遍，不然你临时思考很难说的完美，因为产品经理都需要经常体验新款APP，培养产品感。
另外，不要说太大的产品，比如微信，QQ；说大众产品有一个问题：你说的APP大家都在用，你说的好与不好别人从第一感觉或一眼就能辨别出来，万一别人针对这个产品提一个你不知道的供你，你剩下的就只有尴尬了。因此说小众有特色产品才是面试的好助手：面试官不一定用过，你天南海北侃的时候他只能一脸懵逼，甚至觉得你说的还蛮不错！
最后，说一款产品的时候要从它的战略层、范围层、结构层、框架层、表现层进行说明（用户体验5要素，），这样会显得你比较专业，别人即使听不懂也会觉得你逻辑清晰，给你增加印象分！

转念一想,作为产品经理的我不就是来解决冲突的吗?研发与产品的冲突、运营与产品的冲突、客户与产品的冲突,现在我要做的是先反思一下遇到冲突的时候该怎么办

首先进行沟通看不能有双方都能接受的方式，还有看产品最终客户的需求是什么样的，产品经理的想法跟自己的有出入能沟通就沟通不能就以客户需求为主。

1. 承认冲突

产品经理和研发沟通的时间非常多，完全避免冲突是不现实的。在冲突发生的时候，我们最需要的就是控制自己的情绪。曾经听说过一个比喻：产品经理就像是化学中的催化剂，既能使得产品加速完成，也能阻碍产品的研发。

和研发保持愉快的合作关系，能够让研发产生更加积极的情绪，有利于产品目标的顺利完成。若是和研发产生矛盾，研发很有可能会产生懈怠情绪，从而导致产品延期，也有可能对后续的进一步合作产生影响。既然情绪本身不会给我们的产品带来任何好处，我们就需要在沟通的时候尽量避免负面的情绪，专注于如何解决问题上。

随后，我冷静地对研发说：

“当你说教室管理放在排课这里不合适的时候，我感觉有点为难，因为我们在需求评审的时候已经反复确认了这个问题，只有排课这里会用到教室，在这里维护的话，用户操作起来会更方便，界面也会更简洁。”

2. 寻找需求

这时，我也在同步思考为什么研发现在才提出这种想法，为什么之前评审的时候他说没问题了。于是，我问道：

“那你觉得怎么样做更合理呢？”

程序员回答：

“把这个功能放在门店管理里面，像分类管理那样做一个弹出框实现这个功能会更好。”

我这时候的想法是：你之所以这么说是因为你现在正在开发这个功能，你觉得这样实现起来需要耗费更多的时间来思考如何实现，用以前的方法来实现的话只需要直接复用以前的功能就行，减少了工作量。而且把这个功能放在门店管理部分，就不属于你的研发范围，你只需要调用就可以了，这就是你的需求。而我的需求是如何简单快速地实现这个功能，不管是谁实现的。

在研发产品的过程中，产品经理实现客户需求的主线是不变的，在此基础上，若能够平衡好内部的需求，我们就能成为了加速产品完成的催化剂。在这次冲突中，也有可能研发真的觉得这样实现会更好，只是我没法快速Get到他的思想。

3. 解决矛盾

这个产品的第一版需要在一个月内完成，时间非常紧迫。这个时候产品应该更多地考虑下一期产品的功能，而不是纠结于这个已经确定的功能。

这个时候我把技术经理和相关的人员叫在一起，问问大家对这个解决方案有没有意见，最终大家都同意了这样实现。

这个小功能不会对产品本身产生大的影响，不会造成他人的不满，不影响最终的产品目标，快速确定解决方案就是最重要的。

这对我以后管理需求有什么启发呢？

需求评审注重细节

需求评审的时候，为了减少研发人员的业务思考，避免产品研发过程中对需求的误解，一份高保真的原型和详细的需求描述很重要。前期沟通得越清楚，后期的沟通成本就越小。

迭代应对变化

遇到突发情况更改产品的需求也是正常的。对于需求变更频繁的产品，用迭代的方式进行研发能够减少不确定性。特别是C端使用的产品，根据用户的反馈，一周一迭代就是一个很好的控制需求变更的方法。

以不变应万变

若在迭代的过程中遇到需求变更，最好的方法就是先不开发此功能，充分考虑变化带来的后果，放到下一个迭代之后再实现这个需求对应的功能。

有需求就可能有冲突，面对变化的需求，要越来越处变不惊。

共勉。

如果是根本立场的分歧，我觉得要么妥协，要么坚持。权衡一下你能接受的底限和代价。