对于产品经理而言，如何成长为高级产品经理是很多人都会有的疑惑。而本文也针对这一点给出了三点建议，详情来看正文吧。
产品经理，作为互联网行业不可或缺的岗位，已经成为企业发展中过程最为重要的角色。对于产品经理来说，从产品助理，到产品经理，再到高级产品经理，这样的职业路径已经是众所周知的了。每一级别的突破都代表了自身的成长。
我们来大体描述一下这几个级别产品岗位的职责：
产品助理：协助配合产品经理完成一些产品相关零散工作，熟悉工作流程，掌握基本的产品技能。
产品经理：能独立负责某一产品或项目，有一定的产品经验和产品专业能力，负责需求分析、产品设计、需求评审、项目跟进、上线跟踪等工作。
对于这两个岗位的职责定义，相信大家都不会有太大的异议。但对于高级产品经理则比较模糊了，相信有很多顶着高级产品经理title的产品人都没有太过清晰的概念。因为原本就没有教科书式的定义。
最直接的理解，就是高级产品经理工作年限更长，经验更加丰富，可以负责更为复杂的项目。这点来说并没有错，但十分含糊和抽象，经验怎么算丰富？项目要多复杂？
同样作为已是多年高级产品经理的我，也经历过以上的困惑，直到这一年多来深入到更为复杂的项目中去的之后，才感悟到作为高级产品经理所应承担的职责，以及所需要掌握的能力。
01:
确定各系统职责和边界，规划可适用于未来业务发展的产品蓝图
在一些中小型公司，产品业务会比较单一，因此在做产品规划时，更多的是考虑业务产品未来的发展方向，然后排定计划进行实施。从这个角度来看，产品的规划是紧跟着业务规划进行的。
但对于业务多元化，系统繁多且复杂的公司而言，产品本身更需要有独立性的规划。
因为在公司的这个发展阶段，产品不仅是需要满足当下的业务需求，更多的是需要满足未来业务发展的需要。
而产品随着业务需求的迭代，会变得越来越复杂，甚至是臃肿、混乱。而这样发展下去，产品的迭代必须会跟不上业务的发展，在这种情况下，产品不但不能助力业务，更多的可能是成为业务发展的阻碍。
而对这样的问题，则需要在顶层设计上着手。面对众多的业务、系统，我们需要在整体上梳理业务的定位，业务间的关系以及未来走向。然后对应着系统进行梳理，将我们用于支撑业务发展的C端APP、小程序、中后台系统等产品进行分层分域，划定各产品的职责和边界。通过拆分、整合、调整等方式来优化现有的产品结构。
在这一系列的动作中，可能还需要引入新的产品角色来一同构建我们的产品矩阵。
例如，因系统众多所产生的数据孤岛问题，当前端产品需要调用后端数据进行信息展示时，则需要对后端系统的数据进行整合，当数据量大时则变得非常困难。
在这种情况下，我们可能就需要考虑引入“业务数据中心”这样的系统，专门用于后端系统的数据整合归拢，便于前端系统的统一调用。
经过这样的思考，以解决现有及未来可能出现的问题为着力点，通过拆分、整合、调整、引入等动作一步步地实现产品矩阵的合理化、有效化，最终实现最大化的助力业务的快速发展。
在这样一个过程中，是由高级产品经理更或者是资深产品经理来扮演着这样的核心角色，通过对业务发展趋势的把握、对系统产品的梳理、对系统技术架构的审视，并与技术架构师或技术负责人深入讨论后共同完成的，即形成最终的产品蓝图。
确定了最终的产品蓝图后，后续的产品迭代都依据着产品蓝图中各产品的角色定位去做需求承接。在产品发展过程中，我们还需要持续地复盘检验这个产品矩阵的合理性和有效性，并作定期讨论和调整。以便不断地适应业务的发展变化，持续优化我们的产品蓝图。
02:
熟悉技术实现原理，与架构师/技术负责人讨论确定产品方案，确保系统的高可扩展、低耦合
在承接业务需求的时候，很多时候会不可避免地涉及到多个系统的交互，不同的系统还可能是由不同的技术团队负责，在这种情况下就需要考虑一个合理的对接方案。
作为高级产品经理则需要把控这个过程，提出合理的产品方案继而推动技术实现。
如何把控？首先需要了解大体的技术实现原理。通过对系统职责的判定确定系统边界，从而确立需求分割后的各系统归属，让各系统都做着自己的“份内事”，尽量避免越俎代庖。使得后续需求扩展迭代时能合理地推动实施。
在确定各系统所负责的工作后，则需要进一步确定系统的交互及流程。系统间交互尽量做到简单，尽量避免相互依赖。能用现有接口实现的就不要增加接口交互，能用通用基础接口实现交互的就尽量使用通用基础接口。接口字段的交互也要考虑到通用性，避免需求扩展时造成接口的改动。
所有这些约束，都是为了实现系统间的低耦合和高可扩展性。做到这些后，所有的收益都会在后续的需求扩展中得到体现和回报。
在这个过程中，如果这个需求本身由普通产品经理来负责，则高级产品经理需要介入和协助普通产品经理做好这个工作，与架构师或技术负责人一同沟通讨论最优的产品方案。把控好产品向更为合理的方向发展，这是高级产品经理的职责所在。
当然，可能有人会觉得这个工作不应该是由技术Leader来负责吗？其实如果有这样的一个技术角色来负责这个工作当然更好，但高级产品经理同样需要参与这个过程，确保与业务需求间的匹配性。但这种场景是理想化的，更为普遍的情况还是只能由高级产品经理来主导和把控这个过程。
03:
亲自参与1.0的系统的需求工作，搭建准确无误的产品框架
当我们需要搭建一个新的系统或者进行系统重构时，同样需要高级产品经理来把控。
因为全新的系统或重构的系统，在1.0的阶段，都是在搭建一个合理的产品框架。其产品思路和功能设计则非常关键，合理优秀的产品设计，对后续产品的发展和业务需求的支撑会产生积极影响。
例如，对需求的不断扩张都能得到良好的支持，在技术层面都不需要通过硬编码或大量的if else来实现业务逻辑。这种情况下，不管是产品迭代还是代码维护都能实现良好的延续。
有了良好的产品框架，后续的需求迭代工作转交给其它产品经理时，即便是普通产品经理都能沿着既有的产品设计思路实施功能扩展。使得后续的产品需求工作变得简单，每一次的版本的迭代都是对产品功能本身的增强而不是重构，最终让系统研发的成本大大降低。
但如果一开始没有考虑到后续需求的扩展问题，或者没有考虑到因外部系统需求扩展所产生的需求对接问题，则在产品设计阶段就不会有前瞻性的思考。1.0的产品如果没有较强的普适性和可扩展性，那对于后续的产品迭代基本上是灾难性的，很可能短时间内就需要进行重构。这样的结果无疑是表明最初的产品设计是失败的。
对于这样的项目，经验较少的普通产品经理基本上是很难做好这项工作的，所以不太可能对他们提出这样的要求。因此，高级产品经理则需要承担起这项工作，亲自参与产品方案讨论、产品设计、需求编写等一系列的工作。只有这样才能保证最终的交付物是准确可用的。
一旦完成1.0产品框架的搭建，后续产品的完善性迭代则可以转交给普通产品经理来负责。因为有了固定的产品框架，后续的版本发展基本上不会脱离这个框架，只要按照既有的设计路径就可以保证产品整体上的合理性和健壮性。
以上这些便于对于中后台高级产品经理所要掌握能力和承担的职责。而对于C端如APP类产品，其所要承担工作内容会大不一样，如更为关注用户增长，用户数据挖掘等，但最终的逻辑是一样的，就是承担难度更高、更为重要的工作职责。
作为产品经理，当我们身处一个小企业，业务单一，业务较为简单时，很可能涉及不到其中的这些过程。但对于长业务链条、系统繁多的企业时（如互联网金融），一定能深切地感受到这以上的种种场景。
对于拥有复杂业务逻辑及多系统交互的项目，是迫切需要拥有以上技能的高级产品经理来掌控整个项目的走势的。如果没有，项目混乱不可避免，即便最后能完成项目上线，但对于后续的业务发展下的需求扩展支持，则会变得非常艰难。在不久的将来，系统重构项目便会被列入计划。这对于一个业务快速发展的企业而言，这意味的是资源的消耗、高企的成本以及巨大的风险。
