什么样的产品同学进步最快呢？对此，本文作者总结了快速成长的底层逻辑，都是源自方法论的支撑，并从需求调研与分析的敏捷模型、不要低估“业务状态表”的产品价、工作亲自做行动要落地三个方面进行了分析，推荐对产品经理感兴趣的小伙伴阅读。
连续性的成功，都是源于方法论的胜利。
这段时间，我带的一个实习生属实惊艳到了我，因为她的产品成长效率远超我的预期，比我当年更快、更高、更强，也让我不由沉思：莫非现在年轻人的大脑带宽更高么？
这也留给我了一个深度思考的命题：什么样的产品同学进步最快呢？
因此，镜同学回首自身的职业历程以及复盘这位产品新同学的成长经历，想给大家分享一个朴素的认知，这就是：快速成长的底层逻辑，都是源自方法论的支撑。
也希望本文能带给你一些产品参考。
一、需求调研与分析的敏捷模型
大家都知道，需求调研与分析是产品经理的重要工作，绝大多数产品设计都需要从需求调研着手，在这个过程中产品经理一般需要输出《需求调研分析方案》、《竞品分析报告》等文档。在需求调研的前期阶段，很多产品同学更习惯先用思维导图来进行需求梳理，先围绕需求背景、调研分析的高层级现状，搭建一个简单的敏捷框架，用“思维导图”为载体进行内部评审，以便更好地确定产品设计方向和范围。
应该来说，使用思维导图来进行敏捷梳理不失为一个好方法，但是，不少产品同学在进行产品梳理时都缺乏结构化的思维，总是单纯地把产品功能罗列，信息不全面，缺乏设计深度，需求点容易遗漏，易读性不强，不利于评审决策。
最重要的是，一旦需求调研没有好的方法论做支撑，很容易影响后续的产品设计的习惯和自然态度，比如，我带的这个实习生，一开始使用思维导图进行需求调研时，完全是信马由缰，想到哪里写到哪里，而且更多只是对需求功能的罗列，缺乏结构思维和设计深度。
后来经过两三次的产品内部评审，我针对她梳理的思维导图进行批注点评，也给他看过团队优秀人员的导图结构，比如，在需求调研时必须包括功能定义、业务场景、需求价值、页面元素等四大项，之后发现她明显进步了。
上周，我让她进行“双因验证”的产品设计，这对她来说是个陌生的领域，但她对于需求调研已经掌握了底层的方法论，不仅知道如何快速寻找资料、冷启动新领域的产品设计，体现需求梳理成果的思维导图也更加结构化。
毫无疑问，通过这个方法，她完全掌握了需求调研与分析的产品知识，更值得欣慰的是由此形成了本能的习惯，千万不要低估惯性效应的力量。
二、不要低估“业务状态表”的产品价值
众所周知，对于B端产品领域来说，一般业务流程都比较复杂，用户角色也比较多，产品经理能否高效理清业务流转往往是核心业务逻辑成败的关键。
这里其实有个很好的方法，那就是梳理“业务状态流转表”，通过Excel表格将核心的业务流程展示清楚，既方便产品理清逻辑，也能高效指导开发。
前两年，我们团队有个C端产品同学，他没有使用过业务状态表，对于业务流程的梳理缺乏方法论，只是被动地在原型设计和需求文档上一笔带过，等到需求评审时就被开发同学反问住了，总是漏掉一些业务状态或者某些设计不对。
小伙伴们也不妨回想下自己以往的产品设计，回忆下在需求评审时，是否也曾经对某个业务流程的状态有遗漏，是否也被开发同学难倒过？
不用不好意思，这是成长的过程，but，在业务状态梳理时，你如果有方法论做支撑，懂得使用“业务状态表”辅助流程设计，你的产品设计完整度一定会更专业，需求评审时也更有底气，更有利于掌握主动权，也更有利于体现专家效应。
什么是“业务状态表”呢？
其实，业务状态表是个简称，是对产品流程设计的补充，主要以业务实际流转的状态为抓手，对各个业务活动进行系统的梳理与分析，用以理清相关的流程变动，数据关系、操作用户以及关联的处业务动作。
严格来说，并没有统一的模板，价值重点在于“借助Excel表格方式高效实现对流程设计辅助”的方法论。
比如，上周我们一个产品同学在设计“消息中心”的产品设计，也是通过梳理“业务状态表”对关键业务活动进行流程设计补充，当然，这个需求相对比较简单，但是这样更加清晰，更能体现产品的设计思维，非常方便开发同学进行代码设计。
再比如，我们之前在做供应链金融时，系统的操作用户比较多，流程设计也是泳道图，状态流转更复杂，客观上，我们只能通过状态表来实现高效流转。
“业务状态表”的产品价值很高，因此，不妨再举个例子，前段时间我们在对安全产品进行产品流程设计时，因为该产品的操作用户比较多，业务流程很长，流转状态很难定义，关联的操作也不好理解，这种复杂的场景最适合通过“业务状态表”进行。
重要的往往价值也更大，关于业务状态表的产品方法，镜同学真心希望产品同学一定学会利用，镜同学带过的实习生都受益于“业务状态表”，该方法对我本人的帮助也很大，推荐你重点参考。
毫不夸张地说，“业务状态表”这个设计方法是产品进阶的必备技能和专属法宝，当然，不用在意模板，要重点掌握产品方法和设计理念。
三、工作亲自做、行动要落地！
如果说上面两点讲的都是产品设计的方法论，那么接下来说的这个就是产品的认知方法，镜同学以为：对于产品经理来说，系统的方法论重点包括产品设计方法论和思维认知方法论。
镜同学之所以想重点讲这点，是因为上周发生的两件小事，其也让我更想highlight这个认知方法：产品同学务必要沉下心、行动要落地、工作亲自做。
眼高手低要不得，粗枝末叶不可取，没有过程练习很难达到理想结果，职业发展不要赌运气，要百分之百得竭尽全力。
比如，上周我让项目经理编制《产品全生命周期制度》，周一开部门例会时我就提醒他，一定要亲自来写，可以网上借鉴，但一定要结合我们公司的现状，不能只是冠冕堂皇的官样文章，实用性和可落地性要强，语言也要简洁。
实际上，他并没有这个认知，他只是让一个项目工程师设计初稿，然后在其基础上稍微完善处理，结果评审时可想而知，漏洞百出，甚至他自己都讲不清楚全生命周期管理的要点，汗颜尴尬的同时，他的专业性也受到质疑。
很多工作一定要亲自去做，不要眼高手低，镜同学对于下属的工作成果都要进行批注、评审，方案设计、产品规划与梳理等等，也都是亲自参与，只有这样才能强化过程，蓄积待发。
再比如，我们有个高级产品经理，他的产品设计功底很强，但是书面表达力很弱，尤其不怎么会写PPT，语言功底差、产品方案汇报力薄弱，但他自己并没有这个认知，总是觉得方案很好写，不就是PPT么，只是自己没机会去写而已。
事实上，PPT方案的编制和演讲，都是产品经理的重要能力，绝非想象中的简单，需要系统的认知、全局认知的把控、语言的精炼组织等等，一句话：百炼方能成钢。
而这个同学比较轻敌，缺乏经验，镜同学也发现了他这个问题，因此便有意帮他在这方面做提升，努力为他创造机会，上周我让他做完善公司三年规划的一页PPT，就是对规划中的“风险识别与应对”，也希望借此锻炼下他的方案编制力。
其实，这个方案我早就写好了，我特意对他做了简单的提示，启发他思路，重点是想让他学习方案编制的要点，体会这个过程，从而建立正确的认知，从此沉下心去，不再眼光手低。
结果和我预期的一致，他自己也很内疚，因为，他没有亲自写过方案，缺乏这样的过程，没有这样的思路和经验，我给他提出的思路就像是一个预设的一个圈，他终究没逃脱。
好在他很快建立了这个认知，完全明白了过程的重要性，知道了亲自去不足自己的短板，他自己课下又重新写了一版方案，虽然仍然稚嫩，当这一小步，确实认知的一大步。
产品同学更是如此，基础设计能力本就繁多，再加上新领域和挑战层出不穷，更考验产品同学的认知，尤其要记得镜同学的嘱咐：不要眼高手低，行动要落地，很多事情一定要亲自去做，这是积累的必备过程。
说了这么多，镜同学多次说过，产品经理的核心工作可分为需求设计和需求传递两大内容，因此产品能力体系主要也就体现在以“专业知识”为核心的硬实力和以“沟通协作”为核心的软实力，只要基本的逻辑理解、抽象分析等硬实力在线，沟通协作等软实力不存在硬伤，剩下的关键因素就是产品方法论。
可持续的产品发展与晋升就需要产品方法论做支撑，从这个角度来看，产品方法论是进步最快的催化剂、是我们高效晋升的充分必要条件。
镜同学之前团队里有个同学，她红灯思维较为严重，习惯以个人经验做事，缺乏开放心态，对于产品方法论更是了解不多，因此导致进步很缓慢，我们应努力避免这种情况发生。
反观不少产品新同学，他们具备空杯心态、开放心态，有良好地学习意识和学习能力，即便经验少了一些，专业能力还不够强，但辅以系统性的方法论则使得他们产品进步很快。
产品之路漫漫，方法论也众多，广义上来讲，思维认知模型、数据分析方法、产品设计规范、思维认知模型等等，这些都是方法论，我们需要学习前人的经验，这是高效的明文密码。
当然，镜同学的个人成长经验也未必适合每个人，仅希望对你有产品参考，希望大家眼里有目标、心中就有方向、做事有方法、出手才有力量，越是在过程中踏踏实实地努力践行，成功绽放的速度也就越快。
正所谓：蓄之既久，其发必速！
专栏作家
产品大峡谷，公众号：产品大峡谷，人人都是产品经理专栏作家。七年B端产品经理，供应链物流与金融领域，擅长需求设计、业务指导、商业观察等。