我跳槽遇到的产品面试题真实案例，附完整的题目和答案

基础技能题

1. 要做一个类似微信的APP；第一次需求会议，你会准备哪些会议资料及会议纲要

    

    背景

     假设已通过立项的情况下，已完成BRD和MRD的分析，初步市场需求调研后的第一次需求会议

     准备资料

     会议纲要

• 会议开始，介绍产品总体行业市场调研数据和调研结果，简单阐述产品的商业模式和盈利模式，统一所有人对产品的认知，明确产品方向、目标和定位；

• 根据《用户研究报告》，介绍调研收集用户的需求、行为和态度差异，把用户区分不同类型，赋予人群画像，挖掘不同人群对产品的偏好和潜在需求，从而指导产品规划和设计；

• 根据《竞品分析报告》，阐述从竞争对手或市场相关产品中，进行商业模式、用户人群、功能特性和流程考察分析的数据和结果，根据事实找出公司产品的优势与不足，为产品设计提供参考依据；

• 根据《产品规划方案》，向团队介绍通过研究市场、探索用户需求、分析竞争对手，根据公司自身的情况和发展方向，输出差异化的产品或服务，制定出的可以满足用户需求和市场机会的产品解决方案和产品实现路径，并细化讲解业务逻辑、产品架构和产品路线图，让团队明确了解产品具体执行落地方案和规划。

• 根据《产品需求文档》，让研发团队详细了解MVP版本的功能需求，详细描述每个产品功能清单、流程、需求、设计要素等等

• 介绍项目基本情况，确定项目的成员组成和基本分工情况

• 根据产品规划方案和需求功能清单 ，进行项目开发计划排期和工作量评估

• 业务逻辑图：帮助团队统一了解产品的业务场景、定位和逻辑

• 产品架构图：细化产品的业务流程，是对产品的底层设计

• 产品路线图：从MVP版本进行规划，快速响应市场需求，为产品的发展规划清晰的路线图

• 用户研究报告

• 竞品分析报告

• 产品规划方案

• 产品需求文档PRD

• 产品原型

• 项目成员表

• 项目计划排期

  
  

2. 请通过文字的形式，介绍你做过的最复杂的数据流程

https://www.zptq.com/s/3979/18390/c96b9d40ad9611eda12c0017fa002dc2/start.html#id=yeu65n&p=%E4%BF%A1%E7%94%A8%E5%8D%A1%E8%A7%84%E5%88%99%E9%AA%8C%E8%AF%81

上面链接是做过的一个产品原型，因为在数据处理这块非常复杂，当时前端的交互逻辑我用axure做了一个demo帮助开发理解。但原型本身只是数据流程前端部分的逻辑，后面部分的逻辑需要在后端进行处理

我介绍下这个功能的背景

• 这是一个根据信用卡账单来计算可还款天数的功能，系统会自动生成收款和还款的交易，帮用户将信用卡账单延迟到下一个月。

• 首先先由用户输入账单金额，选择账单还款日期，然后自动根据当前日期自动生成可以选择的日期

• 用户选择日期必须大于2天，表示最少要保留两天还款的时间，系统才能进行周转

• 周转金不能低于2000，周转金会包含手续费，每次交易会扣除手续费，交易后周转金会越来越小

• 每天会进行2-4笔的还款操作，一笔还款最多对应2笔收款，那么最多的收款笔数是4*2 = 8笔，一天最多会有4+8=12笔交易

• 系统一开始会计算距离当前日期距离还款日有几天，低于2天直接就不可还款

• 然后由用户选择还款天数，必须大于两天，通过账单金额和天数，随机生成还款和收款笔数，然后计算出需要多少周转金额，包含每笔所产生的手续费，最后生成一个还款计划

• 还款交易不产生手续费，收款会产生手续费，因此笔数最大化会满足企业利益需求，但是收款笔数太多会影响信用卡的交易，因此会有个算法来控制随机生成的收款笔数，保障产生的手续费和笔数是用户能接受的一种平衡状态

还款规则

1. 1-2笔收款，就会跟着一笔还款

2. 还款金额不会大于前面的收款金额，且要扣除手续费

3. 首笔收款交易时间在早上9点之后

4. 最后一笔还款交易时间在晚上8点之前

5. 收款和收款之间必须间隔1小时-2小时

6. 收款和还款之间必须间隔半小时

7. 一天最少交易笔数是一笔收款一笔还款

8. 不能连续多次出现一笔还款一笔收款

9. 遇到大额的周转金，就生成较多的收款笔数和还款笔数

10. 遇到小额周转金，就生成较少的收款笔数和还款笔数

11. 已交易成功的任务，会产生手续费

12. 未交易成功的任务，不会产生手续费

13. 计划失败，已交易成功的任务，手续费不会退还

14. 资金安全性，平台在所有环节都不会碰到资金，全部用支付通道进行资金管控

15. 坚持本人进出原则，资金始终在用户的个人账户里周转，无法转移到其他账户

• 第一个环节是用户可选择和自定义的，比如还款天数，账单金额，周转金

• 第二个环节是生成计划，一旦用户确定生成计划，那么计划是预生成的，不可变更的，计划遇到不可执行的异常情况，将会结束计划执行

• 收款和还款，本质上是向支付通道发起交易，但交易总会有失败的可能性发生

以下情况是可以恢复计划的

• 周转金不足，用户补足周转金后，当天可以恢复计划执行，隔天计划失败

• 由于通道愿意交易异常，后续任务都会暂停，需要人工介入，通道恢复后，今天的任务时间会从新安排，然后触发首个交易任务，如果恢复时间太晚，无法完成今天的任务，计划失败

• 恢复计划，一般会根据今天剩下的任务数量和时间，重新生成，如果时间够用就重新生成时间，如果时间不够用就减少任务数量

以下情况是不可以恢复计划的

• 周转金不足，且无法补足，那么计划异常结束，用户需要重新调整后生成计划

• 周转金不足的原因，可能是用户在还款计划期间，把信用卡的余额进行了消费，导致计划无法正常周转执行

• 用户的个人信息失效，如身份证过期，银行卡被限制交易，限额等等，不可控的因素，那么计划就无法执行

• 金额太大和太小的计划，最多可以恢复一次计划，不然会导致计划无法正常执行

3. 要做一个信息卡片，如何决定卡片上展示什么，不展示什么

信息卡片，一般要展示关键信息，其他信息可以点击卡片进入详情展示更多的信息

通过关键字段就可以决定展示哪些关键信息

关键字段可以让用户在卡片上快速辨别是否需要阅读，且关键字段可以有效区分不同卡片

• 如订单卡片的订单号，订单价格，订单日期

• 如文章卡片的标题，首图，摘要

• 如账单卡片的交易主体，交易日期，交易金额

有些信息是有主从关系的，在设计时，主信息应该展示在卡片上，子信息和冗余信息不展示在卡片，可以展示在详情里

如用户列表，主信息是用户名称，ID，头像，子信息是用户的交易记录，优惠券等等

卡片信息的设计，在信息展示的设计，主要考虑方便用户快速检索和定位，如果将过多的子信息和非关键信息都展示出来，信息量太多太杂，一方面用户无法快速找到需要的信息，另一方面页面的设计会出现很多冗余的信息。

4. 如果是你微信产品经理，请写出下方页面需求备注说明

1. APP进入的首页是消息列表，按时间倒序展示聊天信息

2. 信息列表下拉可以打开搜索功能

3. 置顶的聊天信息，可折叠显示，并显示折叠的数量

4. 聊天信息，包含好友聊天信息，公众号信息

5. 公众号新消息显示红点，为未读状态，点击后消除红点，为已读状态

6. 好友消息，显示新消息的数量，标注红色块带数量，为未读状态，点击后消除红色标注，为已读状态

7. 下滑可以查看更多的历史聊天信息

8. 服务号的消息，在消息列表展示

9. 订阅号的消息，全部折叠放进【订阅号消息】

10. 好友消息会在手机直接push提醒用户，公众号信息不需要push

11. 免打扰的好友消息不需要push

能力题

1. 技术说 “这个需求技术上实现不了” 该如何推进工作

我是技术出身，我谈谈这个问题的看法，这个问题背后可能会有几个原因，找到原因后就很好解决了

• 这个开发人员刚接触和负责新的功能模块，对功能的了解熟悉程度不足

  这种情况应该跟技术负责人提出，让之前该功能模块的开发人员进行技术讲解和辅助，产品可以帮助讲解之前的功能逻辑、业务流程和需求，帮助其尽快熟悉该功能模块

• 历史原因，老的技术方案和代码结构，导致要实现该需求的难度非常大

  通常代码能正常运行，一般开发不太愿意去大改，特别是长时间不断叠加新功能特性的情况下，某些代码特别复杂，新需求可能会导致对代码进行一次大的改动，从而引起很多工作量。

  这个问题要从几方面解决

  a、在产品规划和设计之初，就可以技术评估出该功能模块的重要性和复杂度，那么可以要求让水平更高的开发来进行负责软件设计，让该功能模块在以后可以适应需求的变化，降低修改代码的难度。

  b、如果代码经过很多人的手，逻辑已经混乱不堪，建议给开发争取多一些时间，让开发使用迭代重构的方式，梳理代码逻辑，同时考虑新需求的开发。也要考虑在这次需求的版本开发结束后，还是要对这块的代码进行重构完善，避免后续有新的需求，还得大改的情况。

• 新功能模块，开发技术能力不足

  这种情况就需要跟开发负责人沟通，明确该需求的重要紧急程度，需要的情况下安排能力更强的人负责，如果是开发能力实在不行，那就需要考虑换人，保障需求如期开发交付

• 临时紧急需求，要求快速上线，且需求不是很清晰，导致开发需要加班才能做完

  首先开发会比较厌恶这类需求，这类需求会打乱原来的开发计划和手上的任务，需求不清晰增加了任务不确定性，导致了工作量增加，且给到开发实现的时间很短，所以开发会拒绝。

  a、产品在接到需求的时候，尽量让需求细化和明确，能文字描述和流程图表达的，都需要进行需求，不要口头需求，尽量降低开发的理解和沟通成本

  b、跟开发保持良好的沟通，可以尝试从问题入手，一起商讨出解决方案，而不是单方面吧需求拍板让开发区执行，让开发参与到需求的过程中，且让他的想法体现在方案中，这样他在落实需求的时候就不会很抗拒

  c、适当从开发角度出发，争取一些开发需求处理的时间，团队的配合应当是相互理解，相互支持，而不是不负责任的甩锅和撒手

  d、产品在拿到需求后，不能只做需求的传话筒，要对需求进行识别验证，且考虑技术可行性，让每一次交到开发手上的需求，都是认真付出的成果。

  e、在产品方案上，如果一个复杂的大需求，可以考虑版本拆分，这样即能减轻开发量和难度，也能正常推进工作

2. 请介绍在工作中你的设计方案的参考渠道有哪些，并介绍你设计过哪些较为满意的方案

 设计方案

• 我会参考一些成体系的产品设计参考信息，如一些大厂的产品开源框架和设计规范，如Ant Design，Element UI，View UI，VANT等等

• axureshop和墨刀素材市场，可以直接看一些成熟的产品设计方案原型，可以体验且有需求描述，需要还能购买源文件

• 竞品渠道我会在语雀参考一些大佬整理的知识库，有各个行业的产品设计方案，也会自己下载APP和产品进行体验

• 行业分析和数据方面我会参考一些高质量的产品导航网站，他们收录了很多常用的工具、数据和网站，查找起来方便高效

• 文章和知识方面，我在各个产品社区进行查找和阅读，如人人都是产品经理，pmtalk，pmcaff

我设计过较为满意的方案

https://modao.cc/app/4dff356cbec2ec791f6de18f4dc732901a1d51fc #电链小程序2.0-分享

https://modao.cc/app/7dbee40b1888def48e8b33ce3b4fc51eee4d543d #聚风APPV4.0-分享  密码: null

3. 请设计一个需求工作流程及关键文档，帮助经验不丰富的产品经理，较高质量的完成需求工作

本篇文章来源于微信公众号: 产品教练