《产品经理成长笔记》1.3：熟悉业务

做产品，首先要了解业务。无论我们的竞品调研做的如何的深刻和丰富，无论我们的原型画的多么的漂亮，如果没有业务作为基座，系统产品的工作，就如沙台上筑高楼，没有了生命和意义。

这个帖子，会从较为全局的视角梳理产品经理做事前（产品化/原型/PRD），对业务认知（需求理解/BRD解读）过程中需要注意的点；篇幅所限，可能不会深刻或具象，我们可以先知全局，而后逐一攻破认知；经历些具体的项目后，再回来翻一翻，相信大家会有新的理解和更为直观的认知。也欢迎大家结合自己的真实项目，留言/私信交流。我会收集大家的反馈，抽取共性问题，专门拉帖，具体展开再议。

1、行业及垂类领域情况

产品经理对业务的理解，大概会从某一个业务应用场景开始，逐步延伸对场景的了解，然后可窥行业的一斑，再往后，可以继续拓宽行业理解，深化行业下某一个或几个垂类领域的认知。

从入行到成为行业专家，需要一个持续积累的过程；此间，搞定一个个需求，上线一个个功能，会帮助我们积累越来越多的行业认知和产品化能力；同时，遇到的一个个卡点，产品化难点，甚至失败的产品设计（版本回退），也是帮我们从另一个维度更深刻的理解业务流与数据流背景下的产品设计内在驱动力。做好充足的心理准备，既可以享受体验成功的喜悦，又可以坦诚面对不足甚至缺失，针对性的补齐、改进、提升自己的岗位能力和行业认知。

2、公司现有业务概况

对行业的认知，不等于所在团队当前和后续的工作方向。我们产品化工作的出发点，应该以业务目标为终点，倒推进行版本规划和迭代管理。业务的阶段目标，又受限于公司现有资源，中长期规划，差异化优势打造等多方面因素的影响。

换句话讲，行业正确的事情，不一定是我们目前就要做的，可能是我们以后的以后要做的；也可能中长期都不会列入公司的发展目标；也可能公司会守正出奇，基于行业正确，结合自身资源特性，进行差异化设计或商业模式创新，由此驱动的产品化设计，可能和通用的系统能力不完全一样，甚至完全不一样。

由此，产品经理在理解认知行业的前提下，更要理解和认同公司的业务情况和发展目标，相应的进行产品化设计。

3、现有系统产品能力介绍

①现有系统能力概况

即使是一个从0开始的团队，也有其一定的积累和基础，可能是技术栈，可能是框架，可能是供二开的系统，可能是可复用的中后台能力，可能是经过检验的一个很不错的系统底座……。完全从0~1的项目，有；但是总会有所依赖，有所参照，有所复用。遇到此种情况，产品经理要摆脱“理想化的乌托邦”规划，基于现有能力，进行系统能力的建设和改造，优先最小成本，最高效率的完成支撑业务需求的能力建设，而后根据系统使用情况，再逐步优化，升级。

同时，系统能力在不同的行业都会有积累，也会出现越来越多的SaaS形式的通用能力，供我们调用。在成本与效率面前，以及信息安全可控的前提下，我们要尽可能的调用成熟的外部能力。在业务系统能力建设的过程中，取百家之所长，迅速完成业务支撑能力的V1.0建设，而后根据业务发展和资源情况，或继续调用，或选用更为适合的能力，或同步自建。

②自研系统URL+账号

产品经理加入一个新团队后，第一件事情可能就是要学习掌握N多个现有系统能力，给自己建立一个在线文档，记录现有系统地址账号密码的前提下，自己独立新建几个租户，新建几个账号，权限测试下现有能力，很有必要。不太建议大家光靠记忆某个系统URL的前几个字母，去通过浏览器记录打开/进入系统。收藏夹，分类整理，正式环境一组，预发环境一组，测试环境一组系统URL+账号+密码的方式，可以帮助我们清晰的记录收纳需要自己熟悉掌握的关键信息，也便于我们在有需要时，可以快速的到达指定的系统/页面/数据。

③业务系统

对于业务系统的熟悉，不建议按照系统页面的顺序，甚至每一个按钮/交互顺序开始，而应该先了解不同业务系统的“系统使命”，即这个业务系统是要完成哪些功能而研发的？也要了解这个系统的历史迭代版本，第一版有哪些功能，后来又陆续增加了哪些功能，由此脉络，来进一步感知业务系统的“成长史/迭代路线图”。这些背景信息的对齐，可能比熟悉具体页面的操作，更有价值。

同时，不要迷恋“系统操作手册”，任何一个形成性的文档，都是滞后的，内容不尽完整甚至内容有误的。产品经理，应该学会时时刻刻自己去撰写系统操作手册，按照自己的理解，参照历史的系统文档，形成自己认知路线的系统操作手册。

④中后台底座

大体系，一定有系统能力沉淀，这些沉淀，可能已经发展到前端可视化的中台能力，也可能还停留下后台层面。产品经理要在熟悉可视的前端业务系统能力的基础上，全面的了解掌握体系内的中后台能力，这些能力会成为帮助我们快速建设业务系统能力的有力助手。