考察你对自己观点的坚持度，以及向上管理能力。我最终摸索出一套比较两全的方案，可以总结为8个字：【求同存异】【帮助决策】。求同存异是指：我在和老板沟通方案时，会先倾听老板的想法，知晓我和老板之间核心差异点在哪里。有道理的地方，我会记录优化，分歧的地方，我会选择积极沟通。帮助决策是指：单纯的辩论，没有任何意义，往往最终谁都说服不了谁，同时耗费大量的时间，可能错失产品最好的上线时机。同时，我们也不应该把问题抛给老板，我一般会花一点时间，用SWOT法则，把方案的优缺点、风险、机会都列清楚，为老板提供足够的决策依据，再组织一次专门的会议和老板进行沟通和分析。在老板局决策后，我一般会用MVP方法，快速上线一版，并做好ABtest，在拿到数据后，再进行汇报和反馈，进行二次迭代。

（1）与客户充分沟通，理解客户需求的本质，从产品用户，使用场景方面，看能否以现成的或者更简单的方式实现需求；（2）如果需求无法避免，那么看合同里面有没有需求变更的部分，如果有那么按照合同执行；（3）评估需求可能带来的收益，会出现的风险和代价，商议能否将功能放在后续的更新中。（敏捷开发）（4）找上级，汇报需要增加的成本。

第一，换位思考。因为从技术的角度来说，我们希望我们的架构界限清晰，能够高效地迭代，同时在稳定性方面去做技术债务的解决。而从产品和运营的角度来说，他们一定是希望用户端的功能能够尽快上线，让用户感知到我们的产品在优化。第二，经常出来分享也是个很好的交流机会，能够学习其他讲师的经验。看到别人有更好的解决方案的时候，对你的业务也有帮助。我一般看到很不错的分享之后都会立刻拍照，或者会跟团队说：“你看别人是这样解决问题的，我们也可以参考一下。”另外，还能够认识很多朋友，有可能哪天遇到相同的困难，询问身边的朋友就能得到一个可以快速借鉴的解决方案，减少了很多踩坑的可能。

因为产品化的需求基本上接近于标准化的东西，是需要多个客户场景进行验证的，而且需要在定制化的需求里进行共性的抽象和提炼，才能形成产品化的需求和设计思路。通常情况下，在市场开拓的一年内基本可以说是以定制化优先，当我们交付了多个项目，并且产品和开发人员都能够深入理解客户的场景要求后，我们才能从不同的客户场景中提炼出业务和管理的共性，形成标准化的业务方案和一些技术方案，进而再将定制化的系统进行重构优化，形成产品化的方案。产品化也可以融入到日常的产品设计中。我们在甲方或者乙方做产品的过程当中，产品化和定制化设计思路最大的不同就是：产品化的系统一定是能够进行多系统可共享的。比如说一个客户管理系统，A项目或业务用了，B项目或业务也可以用，大家可以共享，这也是今天谈得比较多的业务中台的概念。那多系统可共享的产品设计最核心的要求就是：系统要做到高内聚、低耦合，以及标准接口，所有的系统功能和外部系统都可以通过接口的方式与我们已经产品化的，比如说客户管理系统，能够进行快速的拆分和对接。客户管理系统不依赖于任何一个业务系统，这时候我们说客户管理系统就已经产品化了。

先稳住，不要慌，先确定问题，是输出的不明确，没有进行前期的业务解读，还是开发没有看文档原型，没有理解业务，如果是自己的问题要检讨，不要甩锅。开发的问题侧重沟通后期预防类似的情况的应急处理，主要还是看沟通和情商了偏差出现在哪里，影响有多大，为什么会出现回滚需求，解决偏差。先聊清楚原因，要么是实现成本太高太费力，开发觉得不值得做，或者这一版来不及要么就是对需求理解有偏差，没有沟通到位，如果必须按照需求来不能有偏差，那其实就没办法测试通过，需要在当前版本上线前改掉。

正确答案是D这道题实际上是有一定的偏向性，真实参与过公司实习的产品同学，因为有过真实经历，基本上会有一条回答的线索在。但是如果没有参加过实习，仅仅是看了一些视频或者是课程，硬打这道题是答不上来的。这也是现在产品校招出现的一个卷的形式：以前有一个不错的产品设计在简历上就可以，现在基本上需要有一个成型的产品项目经历。那回答这种问题，需要有一个分析思路，本题的四个答案，就是按照产品进行的过程进行的分析、分为项目还没有开始前的产品设计分析、与研发同学进行需求沟通、设立每个阶段的时间点、解决突发情况ABC都是设计过程中比较常见的产品执行操作。一个产品上线时间点没有能够按时完成，一般来说，要么是产品需求反复更改，要么是开发团队质量不行，或者是出现比较大的外部突发事情。D选项，就是在开发按照正式的提交测试时间点进行提交，看似时间进展很合理，但是在测试环节发现问题很大。那么到底是保持时间点？还是保证细小问题也要解决掉，这个不能D选项是一刀切，而是要按照这个产品功能上线的具体情况进行分析。比如说老板要去开一个发布会，这个功能就不能延期，那就只能保证他演示的东西先不要出问题。如果时间点没有那么严重，但是功能性很强，那就需要以解决bug作为核心

正确答案是D这道题是考察对产品职位的理解。一般在中大型公司，产品经理人数较多，就会面临研发团队无法支持开发的场景，特别是部门越多，越会出现一些跨团队的产品功能点。比如说：你是音乐业务的一个普通产品经理，但是整个团队有5个产品，而且其它人有权限更高的产品任务，研发也会优先安排。或者你的任务里需要用户研发团队给出指定用户的功能，或者需要支付团队给某个银行买音乐服务时特殊优惠，就需要另外的研发团队沟通和排期。但是不管你的任务重不重要，它就是你的任务和业绩。如果总是无法上线，那么就相当于任务没完成，最后的考核就会失败。所以这个问题的核心就是让研发给你排上期，不管是死磨硬泡，还是糖弹（下午茶）攻击。ABC三个选项都是任务沟通的方式，但是没有解决核心问题，而且目标人群应该是研发而不是产品，因为其它产品也在抢研发时间，都是工作任务，不会因为简单的协调其它人就放弃。

参考解析：具体问题具体分析，如果是UI或产品对产品需求本身存在疑问，可参考如下：摆数据：证明做这个需求的必要性及完成之后的收益；讲道理：说明这个需求跟公司整体战略的一致性；向上沟通：如果基础沟通不能达成一致，可将双方领导拉到一起讨论。