光阴荏苒，日月如梭，一元复始，万象更新。我们还未觉察到年从指尖悄悄溜走，年就已纷至沓来。回顾总结，反思不足。下面我用真实的工作案例，与你探讨产品工作方法和心得，期待对你有所裨益。
我的：
这一年的产品工作和成长，我总结起来，有4个keyword：Team、Ownership、执行力、产品力。
Team
某个饭局上，我的一位产品朋友告诉我，他跟开发撕逼了，突然觉得好累，争吵的原因是他的产品方案没有得到开发同学的认可。说实话，我挺佩服他，敢跟开发同学叫板。但互联网行业是一个极其讲求团队作战的地方，每个人各有所长、各司其职。
我之所以把Team放在最前面，正是因为如果没有团队，其他一切都是空谈。一个人单枪匹马能做成的事情，非常有限，包括个人的精力是有限的、个人的力量是薄弱的、个人的思维是局限的。合作才能实现和创造更多的价值。融入到团队中，也才能让我们自己学习、成长得更快。
那么产品经理，在一个团队中担任什么样的角色呢？我想：
首先，应该是一名服务员，服务好团队的所有人，做别人不愿意做的杂活；其次，是一名掌舵的舵手，把控方向和进度，把项目成员凝聚在一起；同时，还是一名救火队长，出现问题时第一时间解决；最后，是一名专业的背锅侠，遇到锅要当仁不让地背起来，意味着产品经理是最终的负责人。团队的核心是什么？
我理解，是成员之间默契的配合、是相互包容带来的凝聚力，从而发挥出来的团队爆发力。那产品经理首先要做的，便是与成员“和睦相处”，避免每日菜刀相见。
如何与设计师相处？
首先，要让设计师在设计之前，就十分清楚我们想要什么、我们不想要什么。因此，当面充分沟通讨论是十分必要的。
其次，给设计师足够的个人空间，要避免我们过多的主观意见。虽然产品经理对设计也有自己的想法，但是打心底里，要相信设计师比我们更加专业，而往往设计师也会给我们惊喜。网上有个段子，产品经理在设计师的屏幕上指指点点，设计师默默把菜刀摸了出来。
最后，切忌反复修改需求，尤其是作品完成后，再让设计师大改。
例如，我们在设计信息流不感兴趣功能时，用户点击“不感兴趣”按钮后，会在原位置，重新推荐一篇文章。我们希望通过设计，让用户感知到推荐的过程。我把这个功能的设计初衷，和希望给用户传达的信号，与设计师做了充分的讨论。
最后，设计师制作了一张gif图，一个桃心从空到满的变化过程，旁边配上文字“猜猜你喜欢”，在新推荐的文章展示前，会加载这种gif图，整体的体验非常友好，给了我们很大的惊喜。我录制了一张动态图放在文末，稍后可以看下最终呈现的效果。
如何与开发工程师相处？
第一，亲身教训，不要去随意打扰开发的写码时间。开发一天的黄金写码时间，只有两个小时。有时候，追一个bug会让开发同学抓狂。有一天下午，由于对某个“个性化策略”有疑问，我三番五次地找开发同学讨论，最终导致开发同学禁不住发飙了，因为我不间断地沟通，打乱了他写代码的节奏，导致他难以专心写代码。最后，经过调和，我们约定普通的需求讨论，尽量在上午时间沟通，下午让他专心写代码。
第二，和开发同学的沟通，是一个良性互动的过程。
一方面，切莫把开发同学仅仅当成是一个写代码的，他们对产品也有自己的理解，及时让开发同学了解用户的情况、产品的数据等，对他们的开发工作也有裨益。另一方面，我们也要善于倾听开发同学的建议，在某些层面上，开发是最懂产品的人，因为这是他亲手一句代码一句代码垒出来的。最后，仍然是：切忌反复修改需求。如何与运营同学相处？
运营是与用户走得最近的人，经常与运营沟通，能获得更加全面的用户信息。我们需要做的，是给运营同学足够多的支持，当运营需要帮助时，第一时间协调资源解决。
例如：运营内容的同学，提出“10分钟级内容实时点击数据”的需求，通过线上实时数据，及时更换效果不佳物料。评估下来，这个需求是合理的，并且对收益帮助较大，因此我们投入人力开发。运营同学有了好帮手，提高了效率，才有更大的发挥空间。
其次，产品经理和团队成员，要经常“对一下”和“问一下”。
“对一下”：我们在工作中，说得最多的就是“咱们对一下”。这是我在进入职场环境中，体会最深刻的一个词：对一下需求，对一下方案，对一下进度等等。千万不要不耐烦，这个简单的工作，能够保持团队成员思想、理解、行动、步调的一致性，避免因理解偏差，导致出错。
“问一下”和“对一下”类似，比如：我看到信息流中推荐了一篇旧闻“全运会-男子百米谢震业10秒04夺冠苏炳添摘银”，我马上通知运营同学下线稿件，似乎问题解决了，其实这条badcase反馈的问题，不仅没有解决，反而被掩盖了。
出现旧闻，是审核标记错误，还是算法推荐时丢失了时间参数，或者是前端缓存未更新导致旧闻展现，还有没有其他case，能不能复现？
起初，我觉得这些是技术问题，产品经理不需要了解底层原理，但当leader向我了解情况时，我发现自己一问三不知，事情并不在我的掌控之内，假如真的发生事故了，我可能都还全然不知。
因此，不过于限制自己的边界，遇到问题，抱着请教的态度，向周围同学及时问、大胆问、主动问、勤快地问、厚脸皮地问，深入地问、追根究底地问、辩证地问，切莫担心会失去面子、也别怕招人烦。问到的知识都是自己的。
而如果我们不问，往往会给自己埋下一个坑，等产品上线后出现bug，投诉的用户涌进来，这时候才着急忙慌地去排查。有一次做ABtest，我对“放量的人群维度是否一致”有些疑问，但没有及时询问开发同学，结果导致数据出来，我在做分析对比时，才发现数据差异过大，不是我设想的方案，只能重做，有苦说不出。
最后，关于团队，千万别把平台的产出、团队的成绩，误以为是自己的能力，沾沾自喜。随时保持谦逊的姿态，会让自己收获更多。
Ownership
这事我负责——领导者这事我搞定——顶梁柱这事我来做——左右手这事我要学——基层员工这事找谁啊——团队多余之人这事不怪我——团队垃圾这事没人教——团队落后分子这事为什么我来做——团队寄生虫
虽然这是一则鸡汤段子，但我的实际感受却很深刻。我特别喜欢每层楼梯墙上的座右铭，每天爬楼梯是我锻炼身体的方式，我摘录几句给大家感受下：
其中第2层楼梯上，讲的便是Ownership：“同样一件事，只有心怀Ownership才会做得更好”，用老话说便是：把工作当作是自己的事情，有主人翁意识。
有人说，这个简单，我有Ownership，那么请问一下自己，你是否会在吃午饭的间隙，思考怎么解决一个用户的反馈，你是否会在清晨上班的地铁上，思考如何去优化某个交互的体验，当项目出现问题，无人说话时，是不是自己第一个拉着大家讨论解决方案。Ownership不是一句空话，而是这些实实在在真真切切的小事情。
有人说，Ownership是负责人才需要的，但很多时候我们在项目中，并没有担任重要的工作，是不是就没必要心怀Ownership了？我记得，去年我们部门在突击某答题项目时，起初我并没有领到任务，主要工作是熟悉需求文档和设计稿。
剩余的时间，我便拿起手机，不断使用和体验APP，邀请好友安装体验，发现其中的bug，进而报给开发同学。反复多次，其他同事遇到bug，也会汇总给我。就这样，很自然地，我成了组内最熟悉我们APPbug的人。
在后续的一次集体扩大内测中，在几个工作群中，我自然地承担了答疑的角色。对于每位同事提出的问题，我都立即做出判断，并给出解释和反馈，最终，通过这件事儿，赢得了大家的信任和口碑。
当然，也有人会说，我就是一个打工的，何必这么拼命。每当你这样想的时候，其实也意味着，你放弃了成长的机会，放弃了对自己的挑战，放弃了自己未来的可能性。
当我在没有Ownership的时候，做项目只是机械地执行，遇到困难，第一时间想到的是反馈给leader寻求帮助，面对困境，不敢踏出去一步。当我心中充满Ownership的时候，我心中的想法是：我来主导，我来总负责，遇到困难，第一时间想办法，面对困境，努力找相关接口人协调资源，寻求解决办法。
有几位产品朋友，向我吐槽部门经常有一些杂活儿，很苦恼，例如处理用户反馈和投诉、给团队买夜宵、搞团建、布置场地。我想当你有了Ownership之后，你不会再为这些问题困扰。
执行力
执行力分为很多层面：
第一层面，是个人执行力，自身的干活速度、做事效率；第一层面，是外部执行力，包括项目内部的研发上线、协调外部资源、推动外部门力量。推动并不是说，每小时去催一次进度，这样只会让对方不甚其烦。有效地推动，是合理的规划和安排，并在过程中及时check问题。第三层面，最难也最重要的，就是尽可能做正确的事儿。错误的决定，不仅会把方向带偏，甚至推倒重来。这时候不仅错过黄金时间，队伍的心气都会没了，产品经理个人信用也大打折扣。那如何才能做出正确的决策，这方面我也在学习的路上，我在后文写了几点自己的经验教训。我先举一个“如何开一场有结论的跨部门沟通会议”的案例，来讨论对执行力的理解。由于我们的产品经常涉及多个部门间合作，因此跨部门沟通成为了我产品工作的常态。那么，如何保证跨部门沟通顺畅、有结论。
举例：我们这次跨部门会议的主题是：在产品中接入商业化广告。
第一次开会，仓促进行，在会上我们讨论了可以接入的位置，进行了头脑风暴。由于每个位置是否确认可以接入广告，内部没有确认过，只能列入待定。每个位置有多少曝光，点击量预估多少，这些数据都没有提前准备，因此也无法准确预估出收入，更难以做出决策。
会议开的时间很长，开了两个小时，但最后的结论是：这些方案，我们回去再评估一下。两周之后，广告还没有接进来。
第二次开会，反思上次的问题，做了如下改进：
（1）会前，准备工作做足
充分了解各方的诉求，求同存异，互利共赢，这是合作的基础。我们作为媒体方，有多少流量，预估收益价值等，列出我们的优势，对方才会高优先级推进这项工作，因为从他们的视角，我们只是众多接入广告的媒体方之一。
预约相关人员时间，尤其是，要尽可能邀请能做决策的人员参与。
会前准备好相关方案：在什么位置接，接入什么类型的广告：CPT、CPC还是CPS，什么样式的广告：文字链、图文、橱窗，可能存在什么问题：文字链的长度是否符合要求、图片的尺寸比例是否适配。部门内部先沟通达成一致意见，个别问题，内部来不及开会的时候，可以在工位上，当面简要沟通。切忌在跨部门沟通时，自己的同事一脸懵逼，这时候自己也会被束缚了手脚，不知道哪个工作，能够落地，不敢发言表态。
（2）会中，提高效率
按时参加：会前10分钟，与各方再次确认时间。如果是视频或电话会议，提前15分钟调试设备，不要因人员迟到、设备故障，干扰会议节奏。
会议一开始，务必介绍一遍需求背景，否则很多同事是不了解情况的。我常犯这个错误，自己很理解这个项目，但参会的人，他们可能对这个项目，不是十分清楚前因后果。一开始就懵，后面会上讲的内容，更是听不懂。
同步现阶段进展、陈述问题，尽可能用图、表的方式，更加直观地展示，配合简要文字突出重点。
讨论解决方案：对于这种大会，切忌在现场，召集大家头脑风暴、现场讨论怎么解决。效率低不说，还常常讨论出很低质的方案。方案是提前沟通准备好的，会上主要是评审方案可行性和check每一项具体工作如何落地。
会议得出结论后，在下一步工作中，每件事情约定好负责人和时间节点。
（3）会后，同步会议结论
通过发送会议纪要邮件，同步结论，忌长篇大论。把结论、负责某一项工作的人，完成时间点列上。同时，可以创建一个工作群，方便后续沟通。
这样开下来的会议，一般能够得出可行、落地的解决方案，跨部门项目得以有效推进。
产品力
刚进入时，我的一位指导人告诉我：“你要思考，当你某一天离开的时候，我们的产品，有哪个功能、哪个页面，是你做的，它还在线上服务着我们的用户”。快两年过去了，我始终记得这句话。
目前，我负责日活数亿级的产品，设计和推动了几处重要的产品功能迭代，尤其是今年完成了信息流产品新的里程碑，内容导出量增长两倍半，收入涨一倍半。
下面分享几点我对产品力的理解：
（1）与用户沟通
请问您多久与用户交流一次？
我最密集的时候，每天至少和2名用户QQ交流。我们日常可以通过查看用户反馈，了解用户的意见和投诉，也可以直接和用户对话。在用户面前，我就是一个专业的客服，帮助他们解决问题。
我的经验是：
一方面，尽可能把用户当作小白，用户需要的往往很简单，没有我们设想得那么高级。另一方面，要听用户的，但不要照做。网上说张小龙，在负责QQ邮箱产品时，制定“//10”规定，即每月查看论坛个用户的反馈并回复、