“352”是绿茵场上常见的一种阵型，其特点在于构建强大的中场形成局部优势，通过提升中场控球率有效衔接前后场，实现攻守兼备的效果，进而帮助球队达成比赛胜利的目标。产品经理不同的阶段虽然要求不同，但是都会面临一个同样的问题，要干的事情又多又杂，非常容易迷失方向，不是抓不住重点，就是工作中有所遗漏给团队挖坑。笔者通过对产品经理日常工作内容的梳理，结合足球阵型提出了产品经理工作流程的“352”阵型。
一、什么是流程？
“做产品就是剥洋葱的过程”——布棉
这是我个人非常认同的布棉老师的一句话。
同理，产品经理本身也是一颗洋葱。每天我们要处理大量的杂事，和各个部门的同事沟通（sibi~）、各级别的boss沟通（baodatui~），还要各种写写画画，时间稀碎一地。没有一套抗打的工作流程做指引，很难保证既有侧重又不遗漏地完成工作任务。
在正式讨论流程之前需要拉一拉认知，当我们要完成一项工作任务的时候，其实需要的不只是流程一个方面。比如很大一部分的产品经理每天的工作时间超过50%都在进行各种沟通，但是一方面大多数沟通本身更多的是随机产生的，并非一个固定的工作。常见的场景可能是文档中的细节没有写到，前端直接跑过来问细节，又或是技术可行性需要和项目经理沟通，等着那个PM有空了自己颠颠跑过去请教问题。另一方面沟通本身是一种技能或底层的素质，并非流程。想要完成某一项工作任务，仅仅懂得工作流程是不够的，还需要知识、技能；底层素质；驱动力等等多个方面，本文想讨论的问题聚焦在流程方面，那么问题来了，到底什么才是流程？
流程是事物进行中的次序或顺序的布置和安排；或指由两个及以上的业务步骤，完成一个完整的业务行为的过程。
上述是百度百科对流程的解释，我个人的理解，想把握好流程有如下的重点：
1.有固定的次序，但并非是线性思维（eg：画流程的时候并非不能做原型框架，实际情况往往是做了框架反而流程更清晰了。同理需求和功能也一样。更多解释可以看《用户体验的要素》。）
2.流程本身的构成步骤之间的先后顺序一定要合理配置，流程才可执行（eg：没有流程图，根据需求直接设计功能，根据功能直接就画原型会把所有人逼疯~）
二、产品经理工作流程的“352”阵型
2.1 “352”从何而来？
“352”从流程当中来，它本身就是做产品必备的流程，是一个个子流程的归纳与精炼。而子流程又是从产品经理的一个个繁杂的具体工作内容当中来，产品工作内容的繁杂从下图就可窥探一斑：
不过产品经理的工作虽然杂，但是通过词频图就可以清晰的看出来“需求”其实产品经理工作当中的核心。那么围绕着“需求”，再根据“时间”从前至后进行排序就是最常见的产品工作流程。《人人都是产品经理》、《产品经理的20堂必修课》等入门框架书都是围绕着“时间”顺序来对产品经理的工作内容进行阐述的，更多的细节可以直接去翻经典书。我这里必须要提到的是“函先生”的写给迷茫的产品新人：产品经理工作体系 | 人人都是产品经理 这一篇文章。“352”的流程图也是在“函先生的流程图的基础上进一步归纳总结而来。流程图的讲解函先生已经做得非常细致了。手动给函先生点赞~
2.2 已经有现成的工作流程为什么还需要“352”？
因为环境的改变，原有的流程很难满足现在的产品经理工作需求。
一方面不同公司、行业、阶段的产品经理日常工作内容虽然有挺大的差异，但大家都是从基础的功能点调研、画原型等工作开始的，随着产品能力的不断提高，工作的重点会慢慢向需求的把握，产品的定位，团队的管理进行过度。但产品工作的流程本身也具有阶段性，围绕着“需求”产品的工作流程毅然而然会形成“需求管理”、“需求转产品”、“产品反馈”三个阶段。而这三个阶段是固定的，不会轻易改变的。因此伴随着产品经理的成长以及行业的变更，线性的工作流程必定需要跟随变化，如果不能及时调整，会出现不适应的情况。
另一方面，现在市场环境的变化，倒逼产品经理必须调整工作的侧重点，5年以前，谁能做移动端的产品谁就有市场，3年前，谁能把握良好的用户体验谁就是好的产品经理。但是现在互联网的下半场，宏观经济的不确定性，功能交互的确定性，大数据、AI的新技术推动都在指向两个方向：
1.产品数据化
2.产品运营、市场化
说白了你要么能通过数据能力帮公司赚钱，要么你就要有能力通过数据帮公司省钱。两样都不占的话，你很难拍胸脯说自己是一个好的产品经理。我最近统计了薪资排名前100的几个招聘渠道的JD，“数据”、“中台”、“用户增长”是出现最多的几个产品类型，这就可以说明现在的趋势，因此对于大多数产品经理而言如果还是用以前的工作流程，容易忽视新趋势。
2.3 分享一下自己用过的产品工作流程
1.线性工作流程
根据书本将产品的工作内容进行模块化的拆解，一步一步线性地去完成产品的工作。好处是通过线性的指引，了解了产品的工作内容，打基本功。但是缺乏灵活性。
2.以“战范构架表”为一级分类，准线性的工作流程。
好处是能很好地以用户为中心设计产品，但缺陷是过于关注用户体验，而忽略了宏观的思考。
3.围绕需求的三段流程，“需求管理”、“需求转产品”、“产品反馈”
之前由于转到TOB的岗位，沿用“战范构架表”的流程框架各种不适应，举个简单的栗子，做用户体验的C端产品经理，只需要考虑用户的需求（当然还有BOSS啦~）。但是，TOB的产品经理需求方多到令人抓狂，经常遇见客户方面财务和市场打架的情况，这个需要产品经理对客户公司的组织架构了解，对客户的业务流程熟悉，还要懂利益，懂人性。显然不是简单的一句“以用户为中心”就能解决问题的。
改为三段流程后，虽然多了更多的宏观思考，更多的灵活性，但是对产品本身的关注度却有所下降，离“产品经理”渐行渐远。
三、“352”产品经理工作流程的特点？
3.1 精简，但重点突出
精简不多说了，再啰嗦两句我认为的重点：
1.需求是“基础”。
球迷应该都理解“防守”对于一支球队的意义有多重要，这一点最好的说明就是号称“橙衣军团”的荷兰队，攻式足球观赏性足够强，是人气最高的几个球队之一，但其从来没有得过世界杯的冠军。
同理，如果产品对“需求”方面的把握不足，就如同荷兰队一样，即便你做的产品交互视觉再炫，最终也很难得到用户和市场的认可。
2.“需求到产品”的转化是“核心”
还是拿足球类比，“352”阵型的逻辑是构建强大的“中场”以中场的优势去获取比赛的胜利。
同理，“产品经理”之所以叫产品经理，产品的设计、发布、上线等保证需求转化为产品的相关工作内容永远都是产品经理工作的重心，不论不同的公司、团队对于产品经理职责的限定，还是产品经理自身所处的阶段，对于产品质量的把控是产品经理之所以能够被成为产品经理的原因。沟通再频繁，管理的比重再大只要还是“产品经理”的头衔，不要忘记初心。
3.“以终为始”，数据要“贯穿”整个产品工作的流程
“352”球场的右侧是基于数据分析的不断迭代，数据是这个时代的趋势，无论是否愿意接受，基于运营、市场的最终数据分析能力，是接下来产品经理岗位必须熟练掌握的技能。具体掌握到什么程度，不同的公司和业务肯定有所差距，但是方向和趋势确实显而易见的。
产品经理除了日常的工作，一定要通过“数据”这个“GPS”时刻观察产品的表现，及时作出调整。要将自己变成足球场上的“教练”或者“门将”，要能够通过数据冷静、客观地进行分析。
3.2 可扩展性
“352”每一项都可以进行再分解，每一项需要学的东西都非常的多，但有框架流程的指引，可以保证在进行产品工作的时候不会过于陷入细节，也不会遗漏重要的工作模块。同时，在需要扩展子流程的时候，“352”也能帮助定位，理清思路，提高扩展流程所需知识技能学习的速度。
3.3 “352”符合闭环
其实“闭环”这个词不知道为什么我一直感觉挺难理解的，“PDCA原则”，“良性循环”，“可持续发展”，“学习、实践、总结”其实个人感觉与“闭环”说的都是差不多的意思，反而更容易让人理解。
最后，由于笔者最近两年离开产品经理岗位，“352”来源于近期重新学习产品经理相关知识，梳理流程过程中的思考，不足之处，欢迎大家评论里拍砖，共同探讨。
