快手商业化产品面经（已OC）

To B产品有三类文档：1、客户需求确认：需要把客户需求沟通清楚，流程业务场景突出需要。比如医美机构要求我们搞一个排队叫号系统，我们需要清楚业务流程：客户预约-面诊排号-面诊叫号-面诊-敷麻排号-敷麻叫号-敷麻-治疗排号-治疗叫号-治疗。其中，敷麻分为两种，第一种是客户去分诊台敷麻，自己卸麻；第二种是客户去专门的房间做面部清洁、敷麻、卸麻，这种才涉及到敷麻排号。2、PRD：a.大需求：页面流程尤其是逻辑需要说明清楚，不要让别人产生误解。包括页面新增哪些功能权限，要对这些功能权限组进行详细说明。新增页面上存在的各种字段，也需要说明它们是干嘛的。即使是相似的功能，解释也不能省。小步快跑，多次迭代。考虑到研发成本有限，有些基础的东西没时间做，因此第一次做某个功能时，不要想得太细太多，先解决客户当下的诉求，对于未来可能存在的需求，放到未来的版本迭代。b.小需求：新增功能时不用介绍老功能，否则抢占篇幅，让人抓不住重点。略去已知的背景，尽量用几句话简要说明即可。比如，最开始我的描述是：“在某个订单项目上选择支付方式为增值金后，系统判断该项目最大可使用增值金的比例，结合该项目的折后价格，校验增值金支付金额。如果输入金额超过该项目最大可使用金额，提示"订单中包含有增值金支付上限的品项，请按项目支付"。”mentor告诉我，不需要提示已达到增值金支付比例，系统直接修改金额。于是我改为：“基于“增值金支付比例”和“项目最大支付增值金比例”综合进行判断，自动修正为可使用金额上限。”3、产品操作文档：把产品使用场景和操作路径讲解清楚。机构不关心底层逻辑，只需要介绍哪些功能发生变动。