第三节：产品日常工作场景

在第一章第二节中，我曾经就产品经理的日常工作流程进行了阐述，将产品经理的日常工作分为了组建团队、需求分析、需求实现、数据验证，并对每个部分进行了分析，当时分析的重点在于介绍产品经理的工作流程，故而内容更加偏向“方法论与技能”而非“产品思维”。 为了帮助读者更好的理解产品思维在日常工作场景中的使用，在本节中我将从产品日常工作的常见场景中提取

在前面的章节中，我们提到过功能/需求其实是由场景决定的： 总而言之，在提交需求时，产品经理要关注“场景思维”，将功能-场景-定位进行连接，想的更深一些，这样才能让符合定位的有价值需求更多的被实现。 如上图所示，编辑资料应属于一级模块“我的”中的用户信息模块，我们在需求设计时需要谨记定位与场景去进行设计。然后，我们需要对编辑资料的数据路径进行分析，这能帮我们更好的理解产品设计是否符合闭环。 如上图所示，本需求的核心数据是用户信息。首先，用户资料数据库应中包含UID（用户编码）、二维码与用户信息的关联关系，用以查询；其次，用户资料需要支持输入、存储以及运营管理；最后，用户信息中的【头像挂件数据】属于运营数据，需要运营在运营后台进行配置，数据流转形成了完整闭环。根据以上的整理，我们可以输出编辑资料功能的需求功能列表，这是第一个对外输出的文档，能帮助开发与设计快速了解需求结构与逻辑。 有了需求功能列表，接下来就是根据功能列表来输出产品需求文档，这里篇幅有限，就不展开细细陈述了，只要是围绕需求功能列表展开，产品需求文档的完整性与清晰性就无需担忧。有时除了产品需求文档，我们还需要图像化的表达方式来阐述需求，比如产品原型图、交互稿、视觉设计稿等等，当然一般来说这些稿件不会由产品一人来产出，但是基本都会需要产品经理来验收，确认合格了再进入开发，需求最终上线，形成完整的编辑资料功能。 只有路径实现闭环，功能要点结构化，才能保证不错不漏，让最后实现的需求符合我们最初的预期。 对于需求成本，我们通常谈的最多也最为明显的需求成本是“技术投入成本”，通常包括设计、开发、测试三大模块。在项目周期以及人员配置稳定的情况下，每个版本的可用工时是恒定的，是可用天数和可用人数的积，例如：假设一个版本设计人员可用时间为3天，前后端开发人员可用时间各为8天，测试人员可用时间为5天，同时人员配置为设计师1人，前端开发2人，后端开发2人，测试1人，那么在此版本内可用工时为设计工时3人天（3天2人），后端开发工时16人天（8天1人）。通常在每个版本需求提交后，技术会对需求进行估时，以量化每个需求需要投入的技术投入成本。，这三点共同决定了需求成本。相对于需求成本的可预知和可量化，需求的产出价值则更难进行衡量，正常来说一个需求会拥有以下两个方面的价值：，也就是这个需求为用户提供的显性、情绪价值；，也就是能为公司带来多少收益，这里的收益不仅仅指真实的金钱收益，也包括社会声誉、企业形象等隐性收益。 互联网平台的本质是对用户的赋能与培育，每一个需求、每一条规则都会对用户造成影响，甚至会对不同类型的用户造成不同的影响。在需求评估时，我们需要取评判该需求对不同角色的积极影响和消极影响。例如在闲鱼APP中对上架商品进行严格审核，这能提高上架商品的综合质量，相应的也能够提升购买者的体验，但更严格的审核制度可能意味着更多商品被命中审核不通过或者说审核时长有所上升，故而我们在进行“更加严格的审核制度”这一需求价值评估时，要将其对不同类型用户的影响进行综合评估以此得到更为公正、兼容的需求价值分数。平台型互联网产品通过激发用户潜能让产品拥有更大的动力以及更好的运转模式，这是为什么平台型产品的生命力更强的原因。