什么样的产品同学进步最快呢?对此,本文作者总结了快速成长的底层逻辑,都是源自方法论的支撑,并从需求调研与分析的敏捷模型、不要低估“业务状态表”的产品价、工作亲自做行动要落地三个方面进行了分析,推荐对产品经理感兴趣的小伙伴阅读。

连续性的成功,都是源于方法论的胜利。

这段时间,我带的一个实习生属实惊艳到了我,因为她的产品成长效率远超我的预期,比我当年更快、更高、更强,也让我不由沉思:莫非现在年轻人的大脑带宽更高么?

这也留给我了一个深度思考的命题:什么样的产品同学进步最快呢?

因此,镜同学回首自身的职业历程以及复盘这位产品新同学的成长经历,想给大家分享一个朴素的认知,这就是:快速成长的底层逻辑,都是源自方法论的支撑

也希望本文能带给你一些产品参考。

一、需求调研与分析的敏捷模型

大家都知道,需求调研与分析是产品经理的重要工作,绝大多数产品设计都需要从需求调研着手,在这个过程中产品经理一般需要输出《需求调研分析方案》、《竞品分析报告》等文档。在需求调研的前期阶段,很多产品同学更习惯先用思维导图来进行需求梳理,先围绕需求背景、调研分析的高层级现状,搭建一个简单的敏捷框架,用“思维导图”为载体进行内部评审,以便更好地确定产品设计方向和范围。

应该来说,使用思维导图来进行敏捷梳理不失为一个好方法,但是,不少产品同学在进行产品梳理时都缺乏结构化的思维,总是单纯地把产品功能罗列,信息不全面,缺乏设计深度,需求点容易遗漏,易读性不强,不利于评审决策。

最重要的是,一旦需求调研没有好的方法论做支撑,很容易影响后续的产品设计的习惯和自然态度,比如,我带的这个实习生,一开始使用思维导图进行需求调研时,完全是信马由缰,想到哪里写到哪里,而且更多只是对需求功能的罗列,缺乏结构思维和设计深度。

后来经过两三次的产品内部评审,我针对她梳理的思维导图进行批注点评,也给他看过团队优秀人员的导图结构,比如,在需求调研时必须包括功能定义、业务场景、需求价值、页面元素等四大项,之后发现她明显进步了。

上周,我让她进行“双因验证”的产品设计,这对她来说是个陌生的领域,但她对于需求调研已经掌握了底层的方法论,不仅知道如何快速寻找资料、冷启动新领域的产品设计,体现需求梳理成果的思维导图也更加结构化。

毫无疑问,通过这个方法,她完全掌握了需求调研与分析的产品知识,更值得欣慰的是由此形成了本能的习惯,千万不要低估惯性效应的力量

二、不要低估“业务状态表”的产品价值

众所周知,对于B端产品领域来说,一般业务流程都比较复杂,用户角色也比较多,产品经理能否高效理清业务流转往往是核心业务逻辑成败的关键。

这里其实有个很好的方法,那就是梳理“业务状态流转表”,通过Excel表格将核心的业务流程展示清楚,既方便产品理清逻辑,也能高效指导开发。

前两年,我们团队有个C端产品同学,他没有使用过业务状态表,对于业务流程的梳理缺乏方法论,只是被动地在原型设计和需求文档上一笔带过,等到需求评审时就被开发同学反问住了,总是漏掉一些业务状态或者某些设计不对。

小伙伴们也不妨回想下自己以往的产品设计,回忆下在需求评审时,是否也曾经对某个业务流程的状态有遗漏,是否也被开发同学难倒过?

不用不好意思,这是成长的过程,but,在业务状态梳理时,你如果有方法论做支撑,懂得使用“业务状态表”辅助流程设计,你的产品设计完整度一定会更专业,需求评审时也更有底气,更有利于掌握主动权,也更有利于体现专家效应。

什么是“业务状态表”呢?

其实,业务状态表是个简称,是对产品流程设计的补充,主要以业务实际流转的状态为抓手,对各个业务活动进行系统的梳理与分析,用以理清相关的流程变动,数据关系、操作用户以及关联的处业务动作。

严格来说,并没有统一的模板,价值重点在于“借助Excel表格方式高效实现对流程设计辅助”的方法论

比如,上周我们一个产品同学在设计“消息中心”的产品设计,也是通过梳理“业务状态表”对关键业务活动进行流程设计补充,当然,这个需求相对比较简单,但是这样更加清晰,更能体现产品的设计思维,非常方便开发同学进行代码设计。

再比如,我们之前在做供应链金融时,系统的操作用户比较多,流程设计也是泳道图,状态流转更复杂,客观上,我们只能通过状态表来实现高效流转。

“业务状态表”的产品价值很高,因此,不妨再举个例子,前段时间我们在对安全产品进行产品流程设计时,因为该产品的操作用户比较多,业务流程很长,流转状态很难定义,关联的操作也不好理解,这种复杂的场景最适合通过“业务状态表”进行。

重要的往往价值也更大,关于业务状态表的产品方法,镜同学真心希望产品同学一定学会利用,镜同学带过的实习生都受益于“业务状态表”,该方法对我本人的帮助也很大,推荐你重点参考。

毫不夸张地说,“业务状态表”这个设计方法是产品进阶的必备技能和专属法宝,当然,不用在意模板,要重点掌握产品方法和设计理念。

三、工作亲自做、行动要落地!

如果说上面两点讲的都是产品设计的方法论,那么接下来说的这个就是产品的认知方法,镜同学以为:对于产品经理来说,系统的方法论重点包括产品设计方法论和思维认知方法论

镜同学之所以想重点讲这点,是因为上周发生的两件小事,其也让我更想highlight这个认知方法:产品同学务必要沉下心、行动要落地、工作亲自做

眼高手低要不得,粗枝末叶不可取,没有过程练习很难达到理想结果,职业发展不要赌运气,要百分之百得竭尽全力

比如,上周我让项目经理编制《产品全生命周期制度》,周一开部门例会时我就提醒他,一定要亲自来写,可以网上借鉴,但一定要结合我们公司的现状,不能只是冠冕堂皇的官样文章,实用性和可落地性要强,语言也要简洁。

实际上,他并没有这个认知,他只是让一个项目工程师设计初稿,然后在其基础上稍微完善处理,结果评审时可想而知,漏洞百出,甚至他自己都讲不清楚全生命周期管理的要点,汗颜尴尬的同时,他的专业性也受到质疑。

很多工作一定要亲自去做,不要眼高手低,镜同学对于下属的工作成果都要进行批注、评审,方案设计、产品规划与梳理等等,也都是亲自参与,只有这样才能强化过程,蓄积待发。

再比如,我们有个高级产品经理,他的产品设计功底很强,但是书面表达力很弱,尤其不怎么会写PPT,语言功底差、产品方案汇报力薄弱,但他自己并没有这个认知,总是觉得方案很好写,不就是PPT么,只是自己没机会去写而已。

事实上,PPT方案的编制和演讲,都是产品经理的重要能力,绝非想象中的简单,需要系统的认知、全局认知的把控、语言的精炼组织等等,一句话:百炼方能成钢

而这个同学比较轻敌,缺乏经验,镜同学也发现了他这个问题,因此便有意帮他在这方面做提升,努力为他创造机会,上周我让他做完善公司三年规划的一页PPT,就是对规划中的“风险识别与应对”,也希望借此锻炼下他的方案编制力。

其实,这个方案我早就写好了,我特意对他做了简单的提示,启发他思路,重点是想让他学习方案编制的要点,体会这个过程,从而建立正确的认知,从此沉下心去,不再眼光手低。

结果和我预期的一致,他自己也很内疚,因为,他没有亲自写过方案,缺乏这样的过程,没有这样的思路和经验,我给他提出的思路就像是一个预设的一个圈,他终究没逃脱。

好在他很快建立了这个认知,完全明白了过程的重要性,知道了亲自去不足自己的短板,他自己课下又重新写了一版方案,虽然仍然稚嫩,当这一小步,确实认知的一大步。

产品同学更是如此,基础设计能力本就繁多,再加上新领域和挑战层出不穷,更考验产品同学的认知,尤其要记得镜同学的嘱咐:不要眼高手低,行动要落地,很多事情一定要亲自去做,这是积累的必备过程。

说了这么多,镜同学多次说过,产品经理的核心工作可分为需求设计和需求传递两大内容,因此产品能力体系主要也就体现在以“专业知识”为核心的硬实力和以“沟通协作”为核心的软实力,只要基本的逻辑理解、抽象分析等硬实力在线,沟通协作等软实力不存在硬伤,剩下的关键因素就是产品方法论。

可持续的产品发展与晋升就需要产品方法论做支撑,从这个角度来看,产品方法论是进步最快的催化剂、是我们高效晋升的充分必要条件

镜同学之前团队里有个同学,她红灯思维较为严重,习惯以个人经验做事,缺乏开放心态,对于产品方法论更是了解不多,因此导致进步很缓慢,我们应努力避免这种情况发生。

反观不少产品新同学,他们具备空杯心态、开放心态,有良好地学习意识和学习能力,即便经验少了一些,专业能力还不够强,但辅以系统性的方法论则使得他们产品进步很快

产品之路漫漫,方法论也众多,广义上来讲,思维认知模型、数据分析方法、产品设计规范、思维认知模型等等,这些都是方法论,我们需要学习前人的经验,这是高效的明文密码。

当然,镜同学的个人成长经验也未必适合每个人,仅希望对你有产品参考,希望大家眼里有目标、心中就有方向、做事有方法、出手才有力量,越是在过程中踏踏实实地努力践行,成功绽放的速度也就越快。

正所谓:蓄之既久,其发必速!

专栏作家

产品大峡谷,公众号:产品大峡谷,人人都是产品经理专栏作家。七年B端产品经理,供应链物流与金融领域,擅长需求设计、业务指导、商业观察等。