从实习生到CEO：产品小白篇，我胜任了产品经理岗

第二篇：产品小白

题外：我的最后一份实习和毕业后的正式工作是延续的，所以实习入职和正式入职，并没有太过清晰的分割点；成为正式员工的工作内容和强度与实习期间好像也没有明显的不同，现在回想看，应该是研究所比较有耐心，等待员工的成长；在工作安排和员工胜任力的匹配方面，可能从员工侧考量的更多些。这一点，我在创业期间也一直尝试并努力营造类似研究所的工作氛围，结果我自己不是很满意；到了大厂，面对创新业务的内外部压力，员工培养和胜任力匹配完全是另一种方法论了，按下，以后再表。

实习转正后，我并不是专职的产品经理，除过从实习阶段延续下来的测试、运营、售后、报表开发等和产品经理想去甚远的工作之外，与产品经理关联较多的工作有系统操作手册撰写、系统测试报告、迭代需求整理、新项目需求调研、原型设计、PRD撰写以及系统培训，接下来我以上述工作为切入点，为大家整理下，如何从一名产品小白，逐渐成长为一名可以胜任岗位工作的产品经理。

系统操作手册

系统操作手册的撰写，应该是所有产品小白都必经的工作，或者说是逃不过的工作。为什么说是逃不过呢？因为我遇到了太多不愿意写系统操作手册的产品同学，或者说系统操作手册写的，呃……如同流水账一般，全然不顾阅读者的体会，潦草交差，自己觉得是一个操作手册而已。

如何正确撰写系统操作手册呢？

首先：应该从用户的视角写系统操作手册。所谓手册，就是让用户上手的册子，是指导，更是引导；引导的关键点在于，由易到难，循序渐进。即，从用户可以理解的视角展开系统操作手册的撰写，按照用户常用的使用场景顺序来写，而不是一味的按照系统模块的顺序；系统操作手册使用的语言体系要和用户更贴切些，晦涩难懂的专业术语尽量转化为用户可以理解的白话。
其次：系统操作手册应该区分角色。相对复杂的系统，需要将运营管理端、平台Admin、租户管理员或二级管理员的使用部分拿出来，单独成册，终端用户的操作手册单独撰写。SaaS平台产品，不同的租户，因初始化配置不同，在用户端的页面呈现也会有不同，配置手册，也有必要单独撰写；并在终端用户的操作手册中注明系统版本及配置信息。
第三：系统操作手册的黄金模板。如果系统操作手册有模板可循，那我想，应该是这个样子的：系统的角色定义、用户及典型使用场景定义、黄金流程图、特殊/配置租户的个性化流程图、业务流及数据流、具体模块的页面操作说明、常见的异常情况及处理。根据系统复杂度不同，上述内容可做适当删减。
第四：系统操作手册并不是所有点击都要写。事无巨细，不是系统操作手册应该有的姿势，太多基础/通用的注册登录以及密码找回，可以不写；当然，前提是产品经理设计的不是太过个性化。系统操作手册只做黄金业务场景的操作说明和异常处理说明，对于用户浅显易懂的，约定俗成的操作，完全不用展开。移动互联网时代，几乎所有C端的产品，都不会再有系统操作手册，核心就在于两点，其一，是产品设计的足够人性化，终端用户可以尝试或者再试错后迅速掌握使用方式；其二，则在于用户使用习惯的培养，用户在经历了足够多的移动端APP、小程序或H5页面操作后，已经被众多的产品训练成了一名“合格的互联网公民”。PS：关于这一点，其实涉及到一个话题，即：产品经理的过渡设计，回头做个专题，展开分享下。

系统测试报告

系统测试报告比较多的出现在测试岗位白盒测试后。作为产品经理，可以养成在UAT阶段，撰写系统测试报告的习惯，尤其是从0~1的系统以及投入终端用户使用初期阶段，系统测试报告的重要性不言而喻。PS：如果有研发基础，测试同学输出的测试报告，也可以拿来参照下，理解测试“冒烟”的过程其实就是产品经理设计系统的黄金流程；测试“回归”的过程，其实就是产品经理撰写PRD时对字段及异常定义的过程。

测试报告的撰写注意事项及产品维度的价值都有哪些呢？

首先：测试报告不仅是对研发的要求，更是为产品的自省。测试报告的第二阅读者是研发，第一阅读者应该是产品经理。所以，从这个维度看，测试报告是产品经理写给自己的报告，要事无巨细，关注异常；更要通过测试报告来反向补全PRD，并向研发输出Bug修改要求及系统改进建议。

其次：合理管控测试报告的用例粒度。一般的项目中，测试用例由测试岗位撰写后，测试同学与研发同学评审后，就进度了测试阶段。其实我建议，产品同学要常态参与测试用例的评估工作，尤其是系统从0~1阶段以及复杂需求阶段。单元测试可以帮助到研发敏捷迭代，以及测试与研发的快速交互。但是产品经理要注意，部分特殊场景的测试，需要多个单元测试与异常测试融合交替进行，关键能力的回归，也要通过多组数据和不同的操作路径验证。

第三：系统测试报告可以作为版本管理的重要参考。产品路线图以及版本管理是产品经理的常态输出，小白阶段的我们只是参与并执行，如何才能Hold住版本管理，可能也是好多小白一直想做，很多时候又觉得已经在做的事情，其实不然，具体下一篇展开一下。从测试报告的角度看，如果一个功能，涉及的用户场景足够复杂，需要多次调整入参，还是会出现N多Bug及异常，这时候，就要考虑是否将该功能进行版本拆分了，先稳定一个版本，后再逐步迭代。参与过SaaS系统设计的同学，会体会的更为深刻些，一些规划的能力和场景，往往在提测阶段，通不过验收，其实底层的原因是在产品设计阶段埋下的雷。嗯，不断自省，客观认识自身的不足，并主动持续改进，是从小白走向老鸟的加速剂。

迭代需求整理

已有系统，零星的迭代，小需求的处理是小白的常态，也是我们成长的起点，这个阶段中，需要我们做的主要就是耐得住寂寞，看得到未来，怎么讲？

耐得住寂寞：是指接收迭代需求的时候，务必尊重系统现有功能的设计，遵循既定产品机构设计的思路，在此基础上进行迭代及改造，切莫否定现有的产品架构或者游离于当前的系统基础，为了一个小迭代，擅自增加太多支撑性能力，把一个小的迭代搞得越来越臃肿。这一点不仅会发生在小白身上，好多有经验的产品经理或者高P产品也难免会犯这个错，典型的表现就是“瞧不上、看不过”之前的产品设计思路，甚至是某个前任产品经理，自己非要革除些什么，势必改变些什么。其实大家要记住，产品的迭代需要节奏，切莫动辄就要重构、就要重建。
看得到未来：如果耐不住寂寞是很多小白不由自主的意识；那么看得到未来，却是很多小白较长时间内的无意识。无论是当前系统的体量有多么庞杂，底座有多么的深厚，产品经理都要带着批判和改良的眼光去审视TA。淘宝的体量足够大，客群足够情绪，覆盖及触达的足够深入。拼多多还是从团购和社交两个维度，对下沉市场的电商产品进行了革命性的改造。对于小白同学而言，我们可以告诉自己：产品的优化设计，可以不投入研发去实现，但是，不可以不投入思考去架构，有可能下一个明天就从现在的某一个灵光一现中长大了。

新项目需求调研

如果步入职场初期，有机会参与新项目的需求调研，大家应该是欣喜的，无论其中的不确定性和需求变更如何的让你抓耳挠腮，都要珍惜，不要放弃。新项目对于小白而言是一个完全可以放开束缚，全情投入去感受产品经理的成就感与挫败感的最好机会。

产品经理需要成就感：这个对于小白的成长，太重要了。就如同你踢足球，从来都没有进过球，当你完成第一次进球后，你发现后边的进球越来越多，无论是侧翼突破，还是边线抽射，再或者禁区外的点球，你都有足够的信心，踢出一个完美的香蕉弧度直挂死角。新项目，会让你经历用户的从0~1，经历数据的从0~1，这种美妙的体验，用文字不足以形容，唯有去经历吧。积跬步以至千里，一个产品经理的成长和第六感觉，正是从一个个的需求上线，系统发布，用户点赞，营收徒增积累而来的。
产品经理需要挫败感：客观上，我们并不能完全依赖于用户调研和客户感知去设计产品，因为，我们的权衡用户调研的深度和时间成本的投入；被调研用户的样本范围和代表性，并没有一个公允或者标准可参考。在基于有限调研基础上的产品设计，上线后，遇到客户投诉甚至无视，低于产品而言，正是我们改进的方向。其实道理很简单，你的产品没上线之前，你去问潜在用户他需要什么，用户真的不知道，如果知道，那他就是产品经理了；但是系统上线后，交给用户去品头论足，挑毛病，找茬确实用户擅长的输出。

举个栗子：记得当时做一个注册系统的项目，这个需求最开始生发于教务管理系统的一个注册模块，但是随着高校合并潮的到来，一个综合性大学，要同时面对本课程、硕士研究生、博士研究生、硕博连读、直博、***博、委托培养、交流生、继续教育生的注册、学籍、招生及就业数据的管理，在组织架构上，负责这项工作的职能科室，又不仅仅归属于教育处，同时还和研究生院、继续教育学院、国际合作处、招生就业处以及财务处产生较多的业务交流。这样的需求背景，就需要对传统的教务管理系统下的学生注册管理进行业务流和数据流的完全重构，对应的系统使用部门，也从原教务处的下属科室，升级为与教务处、研究生院、继续教育学院等平行的处级部门。在这个系统的设计阶段，我前后两次，每次1~2周不等的在客户学校的教务处和研究生院协同办公，每天最多的工作就是观察一线科室老师的工作日常，来不断调整系统设计，让系统的操作流程适配通用的业务流程，甚至系统流程主图都修改过几次大稿，过程中一度绝望，当时特别想，干脆重新办一所大学算了，来适应我们设计的系统使用流程……。在这种几近奔溃的状态中，我们不断的被用户的点赞和认可激励着，一步步走出了泥潭，找到了可以打通业务的黄金流程，并通过角色定义用户，用户定义权限，权限定义业务流，业务流定义数据流的逻辑，让这个重度客制化的系统，进化为一个可以复用到多个同样体量的超大型综合大学的SaaS平台。

原型设计及PRD撰写

原型和PRD的输出，和很多“别人家的”操作，似乎都大同小异，我印象比较深的，可以和大家分享的有几个点：

存在没有原型和PRD的项目：研发主导型的团队中，可能会比较不看重原型，有可能画个流程图之后，研发就直接在可用的工程上改了，改完后，直接提测，有问题，再回去改，连PRD都省了。这个最少在我的经历中是发生过的，大家见怪不怪吧
原型的组件化很枯燥但是很实用：我最早实用组件的时候，是被逼得，一个动态门户网站群的原型，大量的复制粘贴和修改更新同样的页面布局，让我苦不堪言，只好使用动态母版，并逐步养成了制作组件的习惯。在此后的新项目团队中，我也一直带领着产品同学创建组件，复用并改造组件。有同学不乐于投入精力做组件，可能原因有两点，一个是没有被大量的原型工作逼疯过，一个是没从全局思考产品的架构，没有建构可以复用的组件，所以也就懒得去投入精力做了。所以，我们要想从小白快速晋升，学会制作组件吧。
重视PRD的模板：我至今保持使用的PRD模板中，数据字典、角色定义、用户场景、字段定义、扩展说明、枚举管理、系统主流程、异常说明等小节都要保留。具体需求/场景的PRD，相应的小节下可以写“无”，但是不可以删除。这个习惯会让大家在每一次打开PRD的时候，都提醒自己不要忽视流程的逻辑正确、不要丢掉细节，不要让数据流断掉……。
Axure画板要分成三块：很多项目中的原型画板，我都会分为3个部分，上+左下+右下。上部分是当前需求的原型部分；左下是原型中未尽的部分，异常的说明和需求模糊或有歧义需要对齐的内容；右下是版本+1的部分。这个习惯在从0~1做产品设计的时候，为产研团队的协作效能及版本管理带来了非常大的帮助，大家可以尝试下。

系统培训

B端产品的一个好处在于，产品经理可以经常性的为用户进行培训，这也是可以在一线接触用户收集反馈的绝好机会。所以，当时做产品经理的我，特别喜欢出差，除过沿途的风景无限和初到异地的新奇以外，最令我期待的是培训过程中，用户不断点头向我传递的认可，和培训过后提出的需求建议向我传递的信任和期待。

所以，大家在产品小白阶段，如果有机会去做系统培训和宣讲，除过系统输出之外，一定记得输入，能现场交流的尽量从现场拿回用户对系统的反馈；此外，问卷，拉群等异步交流的方式也可以使用。同样的内容的培训内容，就不用再多次现场讲了，录制好培训视频，让参训者看，我们做解答，提高效率。

其他

关于Ajax：这是一段美好的回忆，当时龙哥做前端。我们打篮球的时候，是特别有默契的搭档，我打1、2号位，突破后给喜欢埋伏在底角的龙哥投空位三分或者长两分；龙哥打小前，冲击内线篮板后，也喜欢分我，然后帮我挡拆，我骑马射箭稳稳拿分。正式因为球场上的默契配合，项目中，我总喜欢提出一些提升体验的交互优化设计，龙哥总是不厌其烦的去找插件，爬代码。我记得龙哥好到一个日本的开源社区，里边有大量的前端交互案例，直接源码Down，适配也特别棒；龙哥就自己调试各种Demo，倒逼着我加速设计到不同的系统页面中。HTML5，都是后来的事情了。那种产研互相配合单纯为了做产品的时光，一直是我津津乐道给团队分享的栗子。从研究所出来，龙哥去了新浪，赶在微薄初起的那段时间，收获了自己的第一桶金，后来又做了一个牛逼浏览器的布道师；我创业艰难那段时间，没有足够的预算招兵买马，龙哥在线帮我带前端的团队，各种调试……。现在，我俩一直联系着，今年的NBA总决赛第一场，绿凯用勇士的方式赢了勇士，我俩不约而同的发圈点赞。
分页加载：这也是一段弥足珍贵的短暂回忆。当时利在研究所读研二，一个项目在遍历一个大表的时候，拉顿甚至页面假死的情况一直断断续续，没有彻底解决。一次食堂吃饭，我大概聊了下分页加载和前后端异步（现在，很多人都喜欢VUE的前后端分离的框架）处理数据的方案，坐在旁边的利瞪大眼睛看着我说：哈登，你不是学教育技术的么……？我说：我本科学的是计算机呢，哈哈。这次过后，利经常在上课完后，跑到我工位，问问最近做啥系统，有啥问题，和项目主后台要个分枝，自己就开始敲代码。当时LZ大学的一个项目，因为要赶进度，我们少有的周末加一天班，利不知道从哪里知道的消息，下了课就跑来，义务支援。毕业后，利去了华为，从待研发到带产研再带业务团队，经常一周六天，周末休息的时候，就让媳妇开车，他跑来我们的创业项目，还是义务干活，完事喝酒，躺平车里睡觉回家，下周一，继续肝。
远去尼泊尔的那位兄弟：这位兄弟是后端研发，应该是我工作后的第二年，他加入团队，我们合作过一个项目后，我觉得经验可能稍微少些。在下一个新项目立项阶段，得知默认把这个兄弟安排到我的组里后，我找领导直接说换人。领导“率直”的把这位兄弟和我叫到一起，当着我和这位兄弟说，哈登对你不满意，所以新项目你不用参加了……。我勒个去，直接社死，比这尴尬的，不多见了吧？！没多久，得知这位兄弟要离职，去尼泊尔。我突然感觉，可能以后就几乎不会见面甚至联络了，就想怎么解释下，在我迟迟未行动之际，这位兄弟找我说：哈登，谢谢你在合作期间对我的帮助和指导，我知道自己的不足，那次老板说你对我不满意，我也不怪你……。我去，当时我想哭，也比较歉疚。后来带团队后，我一直告诫自己，有些话真的不能讲，不是每一次伤害，都是可以被原谅的。

----------------------------

产品小白的部分，写到这里。

下一篇，可以写写产品经理进阶过程中的一些话题，比如技术背景、产品化与商业化、主产品经理的定义、产品路线图及版本管理……。