我作为一名还没毕业的大三狗来说，已经成功进入社会，并且拿到了一份很有发展空间的offer，已经是一个不错的开始

在还没入行前，对产品经理工作有着极大的兴趣，并且幻想产品经理就是坐在办公室，喝着下午茶，思考如何做一款改变世界的产品

当我正式入职产品经理，担任其职责后，才知道原来并没有我想的那么简单

产品经理的日常工作

上午九点半，吃着包子喝着酸奶，挤着电梯到了公司

打开电脑第一件事就是看新闻，浏览行业动态及社会资讯；半个小时后，查看昨天下班前留的工作便笺，对今天要做的事及接下来要做的事有个了解

接着就开始设计产品2.0分享模块原型，做原型也是一个费脑筋的活，产品功能设计符合用户需求是前提，界面布局则需要符合用户习惯，中午吃完饭午休后，下午就被技术同学拉去会议室协助测试和针对文档上的一些问题进行提问，有些问题在写文档时疏忽掉了，现在被问到，如果是很简单的问题，能直接给出答案，那就直接给出，但是如果这个问题还没有考虑清楚，就记下来，会后再细想，再给出合理的解决方案，吃完晚饭，接着干，（加班已是常态，不多说）

加班是干什么？当然是完成今天未完成的工作，或者学习产品相关知识，之后，就该写日报，对今天的工作做个简单的总结，也对明天要做的事做梳理记录在便笺上，然后就可以打卡下班了

以上只是选取的产品整个流程中的一个小的阶段，可能不具代表性

工作心得

在半年的工作中，经历了产品从无到有的过程，产品1.0到2.0的大改版，需求调研，原型设计，文档撰写，团队协作，测试上线，没有涉及的就是上线后的数据分析

需求调研，一定要明确知道上级（或boss）的想法，不然，则在调研后得到的产品构思与上级想要的不一致，一步错，步步错；其实，你的上级（产品总监或老板）他们就是一个大产品经理，要做什么产品是他们来定的，所以需求调研之前一定要清楚的知道他们想要做什么产品及以后产品发展方向

原型设计，我就不多说了，面对设计与开发，低保真足够，面对boss或者投资方，则需要尽量高保真

需求文档PRD，一直是用word撰写的，但是使用word撰写的PRD的可读性比较低，一个App的一个PRD一般来说都在100页左右，程序员写代码就是比较累的，还得看看上百页的文档，有时连我自己都有点看不下去；业界有一种很流行的需求文档形式，使用Axure来写PRD，可读性较高，可以尝试

团队协作，与设计师沟通时，许多新人容易犯一个错误，就是在对设计师做的图有质疑时，直接告诉设计师：这个按钮这样画不太好，我想的是应该画成这样，用x色更好看。。。为什么不能这样和设计师沟通？这样做间接的质疑的设计师的专业性，设计师有自己的想法，在提出质疑时应该问的是为什么这样做，或许你会明白其原因，还可以发现是否是设计师对原型理解出现了问题；PM做的低保真原型告诉了设计师这个页面有什么功能，按钮，设计师在保证功能上作出美而符合用户习惯的效果图。置于与开发人员沟通则难度就很大了，特别是对于技术不是很了解的PM，建议把开发人员的关系搞好，这样沟通的友善系数就提高了，再去沟通技术上的问题就没那么大的面子与心理压力了，当然，这还不够，更重要的是去多了解技术，多与开发人员沟通，这里推荐一个微信订阅号给大家“给产品经理讲技术”

置于测试上线，这个在大公司是有专门的测试部门，有很多初创型小公司是没有这个部门的，所以这个工作一般就是PM和技术人员同时兼任这项工作，PM这边对产品的需求是最熟悉的，能够一眼看出哪里出现了问题，而技术人员这边对产品的代码结构最熟悉，能够快速的知道如何去改，并且能和PM直接沟通改进方案及可行性；我们还是以公司有测试部门为例，测试部门会把测试结果编写成文档提交给产品部门，这里就需要产品经理对这些测试结果进行一个优先级排序，开发人员会根据这个排序来安排修改bug的先后顺序；那么如何进行优先级排序？致命级，导致程序无法运行的问题；严重级，使用户无法完成主要操作流程的问题；一般级，不影响到操作流程的使用；次要级，界面与UI图有细节不符的问题；根据bug的严重程度做优先级判断是产品经理需要具备的能力，不然，产品快到上线时间节点了，开发人员还在改一些界面上的小问题，还有一个严重级的大问题还没改，这可就麻烦啦

这些都只是偏产品设计方面的一点经验，还有很远的产品路需要走

以此共勉，为了产品梦！！！