这篇工作总结更多的是写给自己的，但也希望自己的一些感悟能引起一些共鸣。

从16年9月走上产品之路开始，到现在也已经一年多的时间了。我很感激公司给予我的成长环境，我们是创业公司，而我负责整个公司的产品线。

和从成熟的互联网公司的产品助理开始做起相比，劣势可能是没有一个更有经验的人能够带着你少走一些弯路，任何事情都需要你自己来摸索。但更多的优势是：你能有一个机会去以全局的角度去看自己的产品，去做产品规划，对我而言既是机遇也是挑战。

这一年以来走过了不少弯路，也经手了多个产品。产品团队从我独身一人也扩充到了四人。有过和技术们闹矛盾彼此不说话的场景，也有过在工作之余大家敞开心扉彼此理解的释怀。

在年假这段时间里，我好好地又看了一遍苏杰的《人人都是产品经理》这本书。发现和刚做产品那会儿看相比，又有了不同的体会。在有了一定的实践经验基础上再看，发现自己能够把书中的某些理论和实践相对应起来，那种「纸上得来终觉浅」的感觉少了很多。

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

工作回顾

这一年多的时间以来我个人主要负责了三个项目。

• 第一个项目是一款服务于校园的短信平台，也是我们创业的启动项目。这个项目也在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 协议