1岁的产品经理｜迟来的产品新人年关产品工作总结

和从成熟的互联网公司的产品助理开始做起比较，劣势可能是没有一个更有履历的人能够带着你少走一些弯路，任何事情都须要你自己来摸索。
但更多的上风是：你能有一个机会去以全局的角度去看自己的产品，去做产品方案，对我而言既是机遇也是寻衅。

这一年以来走过了不少弯路，也经手了多个产品。
产品团队从我独身一人也扩充到了四人。
有过和技能们闹抵牾彼此不说话的场景，也有过在事情之余大家敞愉快扉彼此理解的释怀。

在年假这段韶光里，我好好地又看了一遍苏杰的《大家都是产品经理》这本书。
创造和刚做产品那会儿看比较，又有了不同的体会。
在有了一定的实践履历根本上再看，创造自己能够把书中的某些理论和实践相对应起来，那种「纸上得来终觉浅」的觉得少了很多。

于是我想，不如就借着这本书里自己有感触的一些点，结合这一年以来的事情感想熏染做一个自己的年终事情总结吧，同时也是对这本书的一个个人回顾。

事情回顾

这一年多的韶光以来我个人紧张卖力了三个项目。

第一个项目是一款做事于校园的短信平台，也是我们创业的启动项目。
这个项目也在2017年2月在聚募众筹拿到了天使轮融资。
第二个项目是一款针对企业的在线短信群发平台，在传统的短信根本之上我们供应了较为创新的短信模式，希望能做出自己的个性化差异产品。
第三个项目是APPlan，这是一款针对美本留学，为出国学生供应全方位智能测评与方案的产品，这个项目在2017年12月也成功入驻宁波肯特学校。

这些可能在某些大佬看来不过如此的小造诣，实在也是我们全体公司努力的结果，我很高兴自己能在个中做好自己的那一份事情，和公司一起发展。

在这个过程中我自己的一些感悟和心得，结合《大家都是产品经理》这本书，我总结成了以下10个点，希望能和大家一起分享。
如果某些感悟过于片面，还望看官们及时不吝指出。

心得篇1. 听用户的但不要照着做

案例：

这句话该当在产品经理领域听得比较多了，但我自己深有体会还是在「听用户的并且照着做」了之后；准确来说，该当是「听客户的并且照着做了」之后。

在17年的5月份到9月份期间，我们和一个客户互助开拓一款针对美本留学的产品，包括Web端以及App端，也便是APPlan。
客户很有想法，对产品的功能架构以及功能实现的详细办法都有自己的方案。

一个例子是，客户希望留学顾问是产品中的一个付费项目，用户可以直接通过App购买留学顾问做事，购买之后留学顾问能够通过App中的即时谈天功能对学生进行辅导。

当时的我和另一个产品同事都只是刚事情不久，虽然知道有「听用户的但不要照着做」这么一句话，但迫于当时的项目周期压力并没有花太多韶光和客户穷究她的方案就照做了。

两个月后，产品开拓初步完成。
在交给客户验收之前，我们内部先对产品进行了一次复盘。
在看到上面这个功能的时候，老板以及UI小哥就提出了质疑。

首先留学顾问收费高，动辄五位数的申请用度让用户在只是浏览了顾问的基本信息，没有任何条约保障的情形下直接付费基本不可能。

其次这个申请用度超多了绝大多数用户的银行卡单笔消费限额，纵然有那么一个用户想要直接付费，也会存在无法付钱的可能。

和客户互换之后，虽然这个方案是她设想的，但她也赞许我们的不雅观点，认为这样的设计不合理。

当然这锅客户是不会背的，只能是我们产品团队背走。

后来的办理方案是下掉直接付费的功能，取而代之的如果有兴趣那么用户可以发起线上沟通，付费则采取线上沟通之后双方都认可的办法进行。

总结：

就像大家都是产品经理里说的：

用户提出的需求每每片面，我们须要找到用户内心真正的渴望，把用户需求转化为产品需求。

2. 产品的可用性测试应找到对产品不熟习的用户进行

可用性测试是指通过让实际用户利用产品或原型方法来创造界面设计中的可用性问题，常日只能做少数几个用户的测试，看他们怎么做。

案例：

我们的创业启动项目是一款针对大学生的基于短信的信息网络平台。
在16年的7月份产品内部beta版开拓完成，内部职员测试通过，认为产品的稳定性还有体验都还可以。
然后我们就找了一批对产品不熟习的人来试用产品，然后问题就暴露了：

产品对新用户的勾引完备不足，乃至某些页面没有数据的时候会涌现很多不友好的弹窗警告；结果便是：新用户注册进来完备不知道自己要做什么，一脸懵逼。

由于这个问题创造得太晚，修正本钱已经很高了。
终极的办理方案是我们对产品进行了整体的复盘和大修正，也将产品上线的韶光延后。

总结：

公司内部的人对产品太过熟习因此会认为产品中统统的流程都是天经地义，只有让对产品完备陌生的用户利用产品才能暴露问题。

再附上书中一句话：

记住，统统的错都是产品和我们的错，用户绝对没有错。

3. 慎重地考虑一些细节的改变，在没有大影响的条件下，不要对稳定的版本做一些鸡毛蒜皮的动作

案例：

我自己是一个对细节哀求比较苛刻的人，因此在我刚做产品的头几个月，我会特殊想要去改动产品中一些细节不到位的地方，比如某个地方没有对齐，某个地方按钮大小不一致，某个地方可以增加一个发送人的信息等等。

我当时说服自己的情由是：反正改改也快的。
但有时候也会惹得开拓们很不愉快，可能在我们看来某个随意马虎修正的细节在他们眼里牵连较大不易修正，又可能他们以为这样的修正不好或者没故意义，有更加值得修正的地方。

总结：

我认为不是细节不主要，而是要拿捏好哪些是主要的细节。
在敏捷的背景下可能某些用户很少会进入的页面细节轻微毛糙一点问题也不大，主要的是要把核心体验做好。

书中提到的一个相似的原则是：

我们要区分哪些是雪中送炭的功能，哪些又是锦上添花的功能。

雪中送炭是基本功能，对用户很有用，产品缺了这个功能根本跑不起来。
比如 E-mail 系统里的“收发邮件”；

锦上添花的功能是指非必须的，用户有时用得到，有的话会给用户的利用带来方便，比如在发 E-mail 填写收件人的时候，系统根据你输入的内容自动提示你曾经发送过邮件的联系人

在资源有限的情形下我们要完成「雪中送炭」的功能，在资源有盈余的情形下我们再去完成「锦上添花」的功能。
个人认为敏捷开拓也是相似的思想。

4. 制订开拓周期时，技能职员会以为无法评估开拓量

这是我感想熏染最深的一点，每次我们产品会议到制订工期的时候都是最沉默的时候，开拓职员们会以为无法评估工期，由于有些功能他们也没有做过，不知道实现要多久。

案例：

APPlan里面有一个功能是即时谈天（IM），我们须要接入第三方做事，但开拓们无法评估所须要的事情韶光，但对付我们产品来说，我们是须要有一个开拓日程来把控整体进度的，特殊是某些和客户互助的项目，我们须要担保在截止日期之前交付。
因此工期的制订在我在公司期间是产品团队和技能团队最大的抵牾。

实在我认为双方都没有错，站在技能职员的角度来看对一个完备陌生的功能确实不好评估一个周期。
因此后来同事提出了一个方案，便是技能职员评估一个开拓可能的周期范围给我们，而不须要一个精确的韶光。
这样我们产品团队也能对全体开拓的周期有个大概的把控。

总结：

这样的方案也和书中的不雅观点契合，开拓量是非评估不可的，但我们在初评的时候许可偏差存在。

5. 不要试图知足所有的用户

不要试图知足所有的用户，统统皆看性价比

案例：

在做第二个项目的时候，我们和用户打仗得比较多，我们也很乐意去根据用户的反馈优化产品。
但我当时犯的一个缺点便是我考试测验去知足所有的用户。
由于用户的反馈乍一听都是有道理且有说服力的，由于他们才是真正利用产品的人。
但有些时候用户的反馈会太过片面，可能他会反馈一个就他自己有利用场景的功能。

Minfo的查看已发关照的功能中能够看到用户的回答内容，当然用户能够在任何时候对回答内容进行更新。
一个用户就向我们反馈希望能有一个类似日志的功能能够保存用户对自己提交内容的修正情形。
他也剖析地条理分明，说用户随时都可以修正太过随意，须要这样的一种留档。

后来我们开拓了这个功能，但创造实际利用险些没有。
乃至连提出这个需求的用户他自己后来也没有用。

总结：

我后来也反思。
第一点是我们对用户的反馈还是要有最少的判断。
第二点则是实在某些时候用户的反馈也并不是他自己的刚需，可能有些时候我们找用户访谈，希望他给我们一些反馈。
某些时候用户会出于不好意思或者碍于面子，可能会较随意地提一些建议，那这种时候我们就更须要自己的判断力了。

6. 需求的性价比

绝对不能由于某个需求的实现难度很小就立时去做，也不能由于另一个需求的实 现难度大就不做。

案例：

可能是自己和工程师打仗太多，以是在考虑需求的时候非常看重实现难度。
我会站在技能职员角度考虑以为一个需求实现难度太大而把这个需求砍掉，而并没有拿捏好这个需求的性价比。

按照书中，也便是这个需求的商业代价/需求的实现难度。

当我创造自己这个问题的时候是我在和UI小哥谈论需求的时候，由于他相对我而言不理解技能，因此对技能实现没有顾虑，只是提出自己认为好的方案。
技能职员们一开始当然是抗拒的，但是当被说服并且实现之后，我们创造这样的方案比我们在技能实现上退一步的折上钩划效果要好得多。

例如APPlan中有一个任务界面，UI小哥提出每个任务条款背景从纯色改成插画背景，一开始我以为太花哨，但实现之后看起来产品有活力了不少，更讨人喜好。

还有一个例子便是名师辅导界面，一开始只有老师的姓名和简介，但后来UI小哥主见加上老师的亮点先容，性情标签，从业履历等信息，一下子让老师的形象更加亲切了。

总结：

这些例子也验证了有些时候我们更该当看重需求的性价比而不单单考虑需求的难度。
当然性价比高低的判断就须要一定的产品履历了。

7. 项目晨会和项目日报

项目晨会和项目日报都有进行过，但后来由于以为压迫感太大且任务有时候不能细化到逐日这么仔细，因此后来取消了。

案例：

我们曾经实行过一段韶光的项目晨会和项目日报。
我会在晨会上理解各位技能职员今日的事情操持，然后不才班前确认今日操持的完成情形。

但后来创造不适用，缘故原由是：技能职员们以为将任务分割整天每天天的事情操持太过于细化且带来不必要的压力，效果不如定一个一周操持然后周内让技能们自己安排韶光。

后来改成了周会的形式，实行效果也还不错，因此晨会和日报就取消了。

总结：

项目晨会和项目日报无非便是为了督匆匆公司完成事情操持，实在只要能达到督匆匆的目的，形式是什么并不主要。

我想每个公司都有一个内部的考察机制去担保事情操持的完成，这就够了。

8. 项目发布的韶光

案例：

项目发布的韶光，我当时一样平常都定在周五，现在看来是一个比较重大的缺点。
由于项目发布前我们会进行测试，而万一测试出来的问题比较多，那么技能们就又要修复，可能会拖得比较晚。
周五大家又归心似箭，那这时候产品和技能的抵牾就又会凸显了。
按照书中，周二和周四晚上是比较好的韶光。

总结：

这些教训见告我：周五绝对不是一个项目发布的好韶光，至少在创业公司是这样。

9. 别忘了给大家买夜宵

案例：

这是书中的原话：

「买夜宵」只是传达一个意识。
便是作为产品团队的带头人，在大家以为怠倦或者须要增强大家士气的时候，须要想些办法鼓舞大家的士气。
比如项目发布确当晚，比如项目启动大会。

这一点实在老板做得比我好很多，他会在以为士气低落的时候请大家用饭，也会在外出的时候给我们带点下午茶，也确实能带来提升士气和缓解气氛的效果。

总结：

有时候花点心思在团队培植上，每每能更好地提升团队事情效率。

10. 关于产品需求文档PRD

案例：

关于PRD，我们产品团队实在也做过一些思考。
我们考试测验用过很规范的模板，也考试测验过把这些规范的模板进行精简。
但一个很大的问题都是，我们的技能职员每每不看PRD。

由于我们是创业公司，统共便是十来人的团队，大家坐在同一个办公室里，很多不清楚的点口头互换就能办理。
而且技能们以为看产品的切图和高保真图就能完备理解了，他们不喜好看大段大段笔墨的PRD。

但实际情形是：技能职员们并没有完备理解产品的意图，很多细节，例如输入框的限定还是须要用笔墨的办法去约定的，如果技能们不看完备按照自己的觉得来，那末了出来的产品给人的觉得就相称随意了。

末了我们采取了高保真图+注释的办法来替代PRD，事实证明这样的方案效果不错。
笔墨注释就在高保真图阁下，技能们不得不看，产品们写起来也方便，都是最最主要的信息才会写在上面。

总结：

我认为PRD的目的便是要通报给技能职员们产品要做成什么样，PRD只是工具。
那既然是工具，我就相信针对不同规模不同情形的公司，就一定会有这个公司最适宜的PRD。

作为创业公司的产品经理，就有任务发掘出最适宜公司情形的PRD形式。

写在末了

这一年的产品之路自己也走得磕磕绊绊，由于自己刚刚入行，履历也还不敷，深知山外有隐士外有人。
这篇事情总结更多的是写给自己的，但也希望自己的一些感悟能引起一些共鸣。
但无论如何，这都是是我自己回顾过去这一年有感触并且想和大家分享的东西，如有不雅观点过于片面，还望各位前辈予以示正。

2018，与诸君共勉。

本文由 @陈小乐 原创发布于大家都是产品经理。
未经容许，禁止转载

题图来自 Unsplash ，基于 CC0 协议