一个失业的产品经理，回顾一下这8年的产品生涯（一）

一、前言1. 找工作

本来，对今年的就业环境的情况，已经有了一个心里预期，没想到真正去找工作的时候，发现郑州这边的环境，比我想象中的还要恶劣。

开始找工作有一个月了，简历优化了好几次，boss上主动沟通了很多公司，只得到一次面试机会，再无下文了。

31岁，大专学历，毕业证还是非统招的，没有大厂经验、没有知名成功项目，我感觉我的产品职业生涯似乎要结束了。

2. 最近两年

找不到工作，跟学历有关、跟能力有关，也跟最近两年的工作经历有关。选择很重要，选错了，很要命。

最近两份工作经历，简直一塌糊涂。两年换两份工作，一个外包，一个跟无头苍蝇一样的创业公司，都是混乱的项目，拿不出任何成绩。

18年的一天，跟朋友一起吃饭，一个朋友做网络算命的，说给我算算。本来是嗤之以鼻，但是想想挺有意思，就让算了算。卦象显示，庚子年后，人生会有些不顺。当时听了后来了一句：去他娘的封建迷信。但是最近这两年老是能想起来。

回想一下这两年为什么会把自己的职业生涯搞成这样，只能说人无远虑，必有近忧。

混的不好的人，喜欢炫耀自己过去的辉煌，我现在混的很不好，我也想炫耀炫耀。回想15年到20年那5年，应该是31年人生中最辉煌的时候了，目前职业生涯中最大的成就，赚的最多的钱，也是在那个时候。

当时在一家金融公司负责互联网产品工作，很得BOSS器重，不到一年，便让我负责起技术部门的全部工作。原因有很多，当时自我归结为能力、态度，现在回想起来，应该是和BOSS的性格很符，按照游戏三国志的设定，我们的相性应该一致。在这件公司围绕着主业务做了很多项目，不良资产、电商、供应链都有涉及，而且都成功，现在回想起来，那时候公司的势很足，个人的势也很足，做什么都很顺。

负责项目业绩最巅峰时期，也有很多人来挖我，当时感觉自己很牛逼，公司呆的也很舒服，我也会在这公司干一辈子，没有考虑过自己的行业经验壁垒，感觉自己能力很强，就算不在这公司干了，凭自己的能力，哪不能去？

18年之后，公司主营业务开始下滑，一发不可收拾，中间尝试各种续命、甚至换方向，都没能挺过。挺了两年，大BOSS又因为一些其他的事情入狱，又赶上疫情，终于坚持不住，倒闭了。这个时候，突然发现，自己的一切骄傲，似乎都是平台带给我的，当平台崩塌后，我好像什么都没有了。

3. 工作选项的失误

20年初，疫情期间，携手5年的公司宣告破产解散，自己开始搞一个自己的小项目，正好朋友介绍了一个政府消防项目，当时想着这样接着项目，自己搞点自己的事业，也是不错的，比上班强，还自由。但是政府项目两个月完成了，交付完之后，自己的项目也没有太大的起色，随后的几个月，陷入了无比的焦虑当中。

想了想，开始找工作。

说实话，刚准备开始找工作的时候信心满满，毕竟自己是做个几年产品总监、负责过上亿项目的人，找个工作还不手到擒来，但是开始投简历的时候，看到JD各种行业壁垒、各种学历壁垒的时候，有点慌了。

投了几份简历，迎来了第一次面试，也遇到了羞辱般的碰壁。那是一家做外贸供应链产品的公司，HR给面的。简单的自我介绍完，HR的第一个问题就把我问自闭了。HR说：你没看我们岗位要求的最低学历是本科吗，是谁让你过来的？当时感觉浑身都燥热了起来。

之后找工作的时候就陷入了一种自我怀疑怪圈，只敢投一些学历要求低，JD没有明确要求行业的岗位，然后就遇到了一家人力外包公司。

这个专门为我们当地一家客车企业提供人力外包服务的公司，当时其实我并不知道什么是人力外包，只知道项目外包，面试是甲方的人，通过了，项目是这家客车企业的金融业务系统，离家特别近，几分钟路程。

当时想着毕竟是行业龙头企业的大项目，我这种一直在小公司厮混的野狐禅，正好去学习一下大公司的项目经验。报道之后，签了一堆三方明白书之类的协议，才知道原来还有人力外包的项目。

进去之后，发现所谓大公司项目也非常混乱，同事水平水的一批，干的大多数也都是传话筒的活，不过也有收获，一些管理和制度，让我之前不成体系的产品知识系统化了，干了一年，感觉不行，钱也不多（走的时候才知道外包公司拿走了将近6成，年终奖也被克扣了），也学不到什么了。

然后换了一家公司，这也是职业生涯中最累，让我上班最痛苦的公司。现在也不想太详细说了，后面回顾项目情况的时候再说吧。

回顾这两年的经历，只能说一步错，步步错。人的信心很重要，找工作不要轻易降低你的标准和定位，无论是因为能力还是运气，达到某个高度之后，就不要再往下跳了，一旦降低，就可能回不去了。

在小公司，尤其是业务不清晰的小公司，很少有合理的晋升制度，入职时给公司给你的定位，会造成你在公司决策权和信息获取方面的缺失，很大程度将决定你在该公司职业生涯中的长期定位。当公司又没好的业绩和长久的发展空间时，只能又累又背锅。

接下来的内容，我就从自己的经验、技能、方法，项目经历、职业生涯做一些回顾，本篇内容主要集中在个人经验积累的产品工作方法论上面，项目经历、职业生涯的情况将分批讲诉。

二、我的产品生涯中的经验和技能

本来列大纲的时候，这部分的内容，我一开始命名叫《我的产品方法论》，梳理完之后，感觉还不配叫方法论，只能说是一些经验、技能和工作方法的回顾，接下来主要从商业需求分析、用户研究、需求分析管理、产品设计、项目推进、产品迭代、团队管理、学习方式方法这8个方面进行一个总结。

1. 商业需求分析（从0开始的需求分析）

在从0到1的产品，产品经理最先接触的应该是一个商业雏形的概念，这个时候还并没有形成标准的商业模式，我们的团队还不知道接下来该怎么做。我们需要进行的是商业模式和商业需求的分析。

虽然商业模式、商业方向这些更多的应该是老板考虑的事，但是我觉得，作为一个产品经理，应该有基础的商业嗅觉，起码能判断出，一个商业模式，是怎么样赚钱的。

我这里提到的商业雏形，也是最原始的需求雏形，也是需求分析的第一阶段。

（1）提升商业需求获取的能力

①行业经验、兴趣的积累

②头脑风暴思想的碰撞

很多人反感频繁的开会，扯淡。但是产品经理一定不能反感，爱好广泛一些，多扯淡，很多时候很多好的想法都是扯淡扯出来的。

③保存对新事物的好奇

④多体验

体验各种应用、体验各种广告，了解它们本质的商业模式。

⑤抄

产品的行话叫竞品分析，多思考别的产品优秀和不足的地方，思考他们团队为什么要这么做？

⑥行业研究，数据分析

行业研究网站，上市公司财报，哪怕是一些新的概念，很多都能在老的模式中找到分析的方式，如最近火热的预制菜概念，其实在很早以前就有中央厨房、料理包这一类的概念。

⑦跳出行业，已局外人的视觉去看自己的行业

在一个行业待得久了，看待事物的方式很容易产生一个惯性的固化思维，适当的可以跟行业外的人交流一下你们的模式、产品，听听外行人的意见。

⑧给自己足够的思考时间

好的创意不是忙出来的，对于我来讲，大脑最活跃，思维最发散的时候集中在拉屎、上班路上，以及躺床上休息的时候。太忙的时候很难出创意，大量的时间精力在不停的做方案，赶项目，996，下班后只想早点休息，思考太需要时间了。

（2）从商业需求雏形到商业需求方向的落地

有了商业需求雏形，如何确定可行性？进而确定到商业方向呢？

①市场的规模

②竞争对手

就像上面市场的分析说的拿样，对于常规的行业，通过客户、通过产品，去找你的竞争对手，这里的目的就是分析在当前的竞争对手的情况下，你能拿到的市场份额，以及方便做后期的竞品分析，重点关注头部的竞争对手。

③自身的资源

除了市场和竞争对手外，自身的情况和资源是否满足，如果不满足，需要哪些东西。

（3）商业需求的目的

在商业需求分析的阶段，不需要形成具体的执行方案，更多的是为接下来的执行提供方向，最终的目的我认为有以下四点：

确定业务模式业务怎么开展？怎么赚钱？赚谁的钱？为哪些人提供什么样的服务？方便定位客户群体知道接下来该怎么哪些资源2. 用户研究

（1）找到你的用户

当有了一个商业需求了，告诉你，我们要一款产品，为某些需要某些服务的人群，提供一个平台，来帮助他们解决问题。这个时候应该干什么？我的话会去先找我的客户，先了解目标客户的特点，进一步的去分析需求。

如何找到你的目标客户？根据需求情况，我常常采用的方式：

①借用团队现有资源

一个商业需求的确认，肯定是团队现有了某些资源，才能确定的，或者是业务上的，已经开展了类似的业务；或者是客户上的，已经储备了一批这样的客户；又或者是实体资源上的，我有一批货源。以现有资源为基础，找到对接的用户群体。

②征求专业人士的建议

寻求行业内的资深人士，或是老板，或是深耕业务多年的同事，让他们知道用户的方向。

③行业峰会

如食品行业从业者的糖酒会、互联网人群的各种技术峰会，都可以找打很多目标用户。

④兴趣社群

亦如贴吧、qq群、各种行业论坛这种，会聚集一批兴趣、行业相同的同好者。

⑤把自己当成第一批业务员，实地跑一跑

就像刚入行的业务员，没有客户资源怎么办，拓客嘛，实地去跑、扫街，扫完街回去总结，客户在哪，有没有集中的地方？

（2）用户调研

到这一步其实就是老生常谈，用户画像和用户需求调研，结合我们产品商业模式的战略防线，为客户提供的服务，初步建立其一个大概的用户画像，把用户的一些共性特点属性总结归类，然后在调研中不断完善。我这边常用的调研方式如下：

①访谈

②问卷

在已经在心中确定一个大致的产品方向时，就可以通过问卷的形式验证或完善你的想法，通过把一些抽象的问题量化成具体的数值或者选项，供用户进行选择，具体的渠道可以通过社群等方式进行投放。

③模拟业务

构建了一个产品的雏形，可以试着把自己当成一个业务员，把这个产品当成一个付费的业务来试着售卖，看有没有人愿意为其付费。

3. 需求管理

当通过商业的定位、需求分析、以及用户调研后，我们基本都可以知道，我们要做的这个产品是为什么人提供样的服务，这些人都有哪些特点了。延伸出的需求也就比较清晰了，在需求落地之前，需求的管理决定了产品的质量。

（1）建立需求池

需求管理的第一步就是建立适合项目的需求池，如果产品线只有一个你产品经理的话excel就可以满足需求，如果作为产品总监的角色，需要对团队的需求池进行管理，可以使用一些工具，tapd、jira之类的都可以，或者在线文档，excel+svn/git，都是可以的。

①为什么要建立需求池？

需求池是记录需求的一个工具：

产品经理要面对一条产品线从上到下所有的人，每个人都会有想法、意见、建议，不可能第一时间去完成，也不能全靠脑子去记。

此外，不是所有的需求都是需要实现的，也不是所有需要实现的需求都是立马要做的。记录下来，保证到你这的需求有迹可循，方便管理。

需求池是需求排期、版本管理的工具：

挡需求：

作为产品经理肯定会经历过这种情况，上级领导、其他职能部门提出不是特别合理或者不是特别紧急的需求，但是要当时直接拒掉他的需求，太过于不讲情面、不利于团结，但是如果你当着他的面把需求记录在需求池，并向其展示优先级比较高的需求，向其说明原因，表示你的需求我已收到，但是当前的需求排期有更紧急的任务，我计划什么时候对你的需求进行分析，再进一步沟通。

这样双方都有一个深度思考的时间，作为产品的我们也能更好的判断需求的合理性，做还是拒绝。

方便汇报：

对于阶段性的工作汇报、或者对于领导重点关注的需求，你只需要翻一下需求池，就能很直观的回报了。

②如何建立一个需求池？

需求池其实是个很简单的东西，需要的字段：需求描述、所属模块、功能点、需求类型、需求价值、场景描述、提出人、提出时间、状态，优先级。能记录清楚什么时候、什么人提出的什么需求？当前是什么状态即可，其他的字段可以根据项目情况、团队情况增加字段。比如说开发时间、上线时间之类的。

（2）需求优先级

如何确定需求的优先级？

①根据业务目标来确定优先级

②根据需求价值确定优先级

③根据产品的生命周期阶段确定优先级

新产品：

新产品的核心是业务流程的完整性，流程相关的功能必须完善，要形成闭环，来完成我们产品定义的目标。所以只需要围绕核心业务流程，就可以定义出高优先级的需求，反之，无关核心业务的锦上添花的需求，哪怕看起来再重要，优先级都不应该太高。

举个例子，如果老板有一批茅台，想在网上建个网站平价卖掉，那个这个网站的核心业务流程就是下单，其他都不重要。

但是如果老板想通过这批平价茅台，作为用户奖励，建立起一个酒水商城，这个时候，核心流程就多了起来，我们要考虑基础的下单流程，还有考虑延伸出的注册登录流程、奖励获取流程，以及老板需要的电商平台的基础功能流程：发布产品流程、订单管理流程等。

成长阶段：

这个时期应该是已经启动，积累了一部分种子用户，进一步发展的阶段，这个阶段，已经验证了需求是真实需求，有客户买账，存留、拉新是核心。

关注数据、反馈，影响业务的bug，影响用户体验的细节、都是这个阶段应该关注的。

此外，围绕核心业务，能为核心业务锦上添花的功能，这个时候的优先级也要相对提高。

以上面的电商平台为例，我们在新产品上市后，我们重点关注用户在登录注册、参与活动、下单支付等流程有没有阻碍，茅台激励的形式有没有更好的方式，用户参与活动转化购买其他产品的途径。

成熟稳定阶段：

④根据实现成本确定优先级

大多数互联网项目的成本都是开发成本，评估一下需求的工时，再对照一下价值、目标，优先级高低一目了然。

4. 产品设计

（1）业务流程图

（2）功能清单

结合需求及流程，确定需要的功能，使用思维导图或者excel表格进行整理，这里需要具体到功能模块，如登录、注册、发布xx信息等。

（3）角色用例

对于多角色系统，如涉及到买卖双方的c2c交易平台，需要考虑到卖家与买家不同的角色用例，区分不同角色需要的功能，如果不同角色用例没有交叉，就可以考虑对不同角色使用不同客户端去区分使用了。

（4）产品结构图

在确认了业务流程、功能清单、角色用例的基础上，我们就可以确定整个产品的结构框架了，主导航有哪些，需要哪些页面，页面的层级与聚合关联关系，都可以通过结构图梳理和呈现出来。

一般来讲，像移动端，由2-5个主导航构成，首页、我的属于95%以上产品都会有的功能，中间根据具体业务的情况去设置相应导航。

中后台产品的主导航就比较多一些，根据业务情况去聚合就可以，如用户中心、会员中心、商品中心、广告中心、营销中心等。

（5）页面元素

（6）页面设计

前面的一些工作完成之后，到了页面设计这一步，其实就没有什么通用的方法论这一说了，更多有价值的是一些规范性的东西。

首先，是一个产品的不同页面直接一定要保持样式一致性，这样可以通过建立一个原型规范来去执行。

抽离公共部分一些常用的组件，比如按钮、头像、弹窗、表单等，在项目开始前期建立相应的标准，尽量不要出现一个项目相同场景的功能，交互组件样式不一样。

如果你常使用axure，用好母版和元件能让你事半功倍，把不同项目可以复用的样式做成元件，把一个项目中的通用组件做成母版。

这个方面可以多参考一些开源的前端UI框架，尤其是像中后台类的产品，可以把一些优秀的框架如element、layui之类的优秀的样式做成组件，储备下来。

其次，遵循用户体验，尽管产品经理输出的只是原型，但是原型的体验很大程度上决定了最终输出的UI设计稿的体验。

另外，学会克制，不要在原型里加一些跟业务无关、跟功能无关的花哨设计，如果真的忍不住，自己列到需求池里，评估之后再进行处理。

最后，做页面原型设计的时候首先要明白你的目的是什么？

对于大多数常规的产品原型目的就是向UI和开发传递可视化需求用的，想设计师和开发表达出我们想要的东西大概是长什么样.

原型是一个沟通工具，沟通到位了，一句话就可以表述清楚一个功能，沟通不到位，弄个几十页的prd做出来也不是你想要的。

当然这不是绝对，就像前面说的，如果要组织可用性测试，尽量保证你要测试的原型和交互是完整好用的。还有一些toB或者toG的项目，在开发之前，需要跟客户演示，做一些售前的工作，也需要高保真的原型。

5. 项目推进

在我作为产品经理参与主导的项目管理中，各种会议的管理，正式我推进项目的最有效的工具，我作为产品经理的工作，除了需求分析、产品设计之外，其他主要的工作就在各种评审会上面。

（1）需求价值评审会

作为产品经理，你要保证，做的任何需求都是有价值的，这也是产品经理的价值所在。

接到一个需求，当你开始分析时，首先要判断它的价值， 而且尽量把它去量化，比如说某个功能上线后，结合运营多少资源，可以为产品带来1万活跃用户，我们需要投入2个人10天的成本，值不值得做？

但是实际上很多需求你没办法一个人去清晰的判断出它的价值，就需要一个价值评审会，来明确产品价值。

尤其是对于B端产品经理来讲，需求价值评审会就是避免你成为传声筒的最好方式，客户、领导、其他业务部门传递过来的需求，没办法拒绝，拉着相关的干系人，逐条评审产品的价值，明确是否要做，怎么做，不能做，也有合适的理由拒绝。

价值评审会产品经理为主导，拉着一名技术人员，以及需求的提出人、干系人来进行。

价值评审会需要准备一份《需求价值评审文档》，包含一下属性：

（2）原型评审会

面向技术团队内部的会员，向开发、UI、测试讲诉你的产品，你的原型会议。

原型评审会的目的：向团队成员表达清楚你想要的东西，让大家参与，找出当前设计存在的问题。进行任务的分配，然后评估各项工作的大概工期。

讲解原型的几个要点:

评审会经常会遇到的问题多是一些与开发人员的沟通问题，如何应对？

①功能做不了

②功能成本高

评估价值与成本，是否在接受范围，再来决定是否要做。

③功能没价值

听听开发认为没价值的原因，不要有对抗思维，向其也表述你认为要做的原因和价值，去综合评估。

对于跟开发意向有分歧的地方，怎么处理？

（3）UI评审

（4）技术评审

对于新项目，我建议产品经理一定要参与到技术评审中，了解技术架构、技术选型，框架等，最主要的是要关注数据库结构的设计，表和字段是否满足你的产品需求，减少开发过程中的遗漏。

除此之外，对于产品经理主导的新团队，在技术评审的时候一定要让前后端把接口的规范定清楚，把责任提前明确，防止前后端扯皮。

（5）测试用例评审

这个评审主要是由产品经理和技术来评审测试用例的范围，是否覆盖全，以及明确重点测试的部分，还有可容忍的bug范围。

（6）项目复盘会

复盘项目过程中出现的问题，人的问题，制度的问题，共同讨论如何规避问题。

6. 迭代需求的获取（从1开始的需求分析）