今天在知乎看到一个问题:
作为产品经理或产品负责人，你可能会忽略哪些实际上很重要的小事？
我觉得这个问题很有意思，所以这篇文章就试着从我的角度来回答一下。
既然题目讲的是鸡毛蒜皮的小事，我就不说产品经理的一些最重要的事了，比如:
个人认为最重要的四个素质:沟通能力、专业能力、理性思维、逻辑思维；
执行产品经理的基本工作内容；
……
让我们试着从不同的方面列出事情。有哪些我认为同样重要，但可能别人不这么认为的“小事”。
合作方面
▍在合作过程中积累更多
产品经理经常需要和不同的人沟通和联系，比如公司领导、运营、交付、业务、商务、设计、开发、测试等。
不同的人会站在不同的立场，出于不同的目的给你他们的需求或者反馈。
在他们需求合理的前提下，你是不是直接按照他们的诉求去做了？还是多问问他们？
当运营商需要你的配合时，不要认为你是无关紧要的。你要多看看他们的活动类型，多想想他们的分销渠道，问问你为什么选择他们。
当开发人员聚在一起交流技术细节时，不要认为这不关他们的事。多听，多了解他们是如何实现需求的。
设计师给你设计设计稿的时候，不要只是收了稿就完事。和设计师交流，问他们为什么。
老板觉得自己要提前做好某个需求，不要只是把自己放在执行的位置上。他应该多想想自己为什么这么做，会给公司带来什么好处，公司最近有什么变化。如果不懂，可以试着问；
……
这些从各个角度来看都是很有价值的实用知识。都是你需要阅读专业书籍才能看到的东西，或者甚至可能是书本上找不到的。现在，你已经通过你的需求学会了一切。怎么能浪费这么好的机会来补充自己各方面的知识呢？
别说好处就是耍流氓。这样做的好处如下:
对和你一起工作的其他人和他们的职位有更深入的了解；
慢慢积累自己的各方通用知识框架；
基于前两个优势，相互沟通会越来越顺畅；
之后在需求时间的预估和项目进度安排上会更加确定。
在合作过程中，问为什么。这个在之前的文章里已经解释过了，这里就不多说了。
▍摆正了与各方关系的心态。
人们应该纠正对产品的几种态度，那就是:
不要把设计师、开发人员、测试人员当成实现需求的机器；
不要把运营、分销、业务、boss等人当成只提需求的臭傻逼。
经常在各个地方看到产品的人都在吐槽，比如:
简单的移动位置，放大，我也无法理解为什么美工做不到；
一个简单的功能，代码狗看不懂逻辑，太弱了；
老板只会提需求，太坑了；
……
如果你用这种对立的态度看待你的伴侣和你的团队成员，你怎么能和所有人搞好关系？人家跟你关系不好，也不可能跟他们愉快地共事。
如果你想让别人尊重你，你就得尊重别人。
这样做的好处是:
合作伙伴可以在愉快和相互尊重的氛围中工作；
对于个人来说，是一种素质的提升。
产品本身
产品视角下的▍思维
站在整个产品的角度思考问题，而不仅仅是站在产品的立场上。
比如这个版本的要求已经确定，这个版本的上线时间也已经确定。但是因为某些原因，运营和投放需要下一个版本的大战役和投放，需要产品方配合开发一些东西。这时候我们该怎么办？
如果只从产品立场考虑问题，会觉得这太临时了。如果承担做，不仅要临时增加工作量，还需要重新和设计师、开发商沟通，调整方案。他们也可能因为暂时的工作量而产生一些负面情绪，你要理性/感性地安抚他们。
但是，考虑到整个产品，这又是一件需要做的事情，最好做。毕竟整个团队在数据压力下，需要用一些外在的方法来带来新的工作和日常活动，对整个团队都有好处。
再比如:一些小白产品总是纠结于一个公司，是产品更重要还是运营更重要。总觉得公司重视运营，不重视自身，这让我很难过。
其实这个想法没有任何意义。如果整体考虑:需要强运营的产品，自然以运营为主；需要强大功能的产品，自然把重点放在产品上。
对问题的重视只是量的问题，而不是质的程度。考虑如何对产品好，这是最需要纠结的问题。
这样做的好处是:
对整个产品更好，不会因为产品的个人考虑而偏离或停滞；
对个人发展有好处，不断锻炼自己的整体思维。
▍更多地与团队合作伙伴交流业务。
有时候，能看到产品的人会抱怨他们的团队成员。比如我们组的人，不关心需求，只知道怎么做，做了就犯错误。真的很无语。
这个时候，其实你要反思了。是不是因为你从来不跟他们沟通为什么需要这么做，才逐渐导致这种情况？
当然，我也知道，并不是所有的开发者和设计师都对为什么要做这个要求感兴趣，但是如果你连这个都不知道，你又怎么能指望大家去设计开发出你想要的东西呢？
在沟通每个版本的需求时，不妨跟他们沟通一下每个需求的原因，无论是来自数据分析结果、用户反馈，还是公司高层出于战略原因。
毕竟我还是坚信基于理解的需求实现从长远来看是“安全”的。
这样做的好处是:
基于理解的设计和开发，或许可以在照顾现有需求的前提下，考虑到一些可能的坑和未来的变化；
时间久了，大家会觉得更像一个团队。
▍在看数据结果之前辩证了数据的真实性。
许多产品经理经常说:
从数据结果可以看出，巴拉巴拉巴……...
几乎是口头禅。
但是我想告诉你，如果数据本身是错的，那么你所谓的数据结果就是扯淡。
你可能会想，数据怎么会错呢？当然:
可能因为不同平台的算法不同，数据和你真正想要的算法不一样，导致错误；
可能是开发埋点的时候出错了，导致出错；
可能是开发实现某个相关功能时，实现方式的不同可能导致数据偏高或偏低，从而产生错误；
……
数据错误的可能性很多。所以，在说“从数据结果就能看出来”这种开场白之前，首先要知道数据本身是否有错。
这样做的好处是:
不会在错误的数据上浪费时间；
对数据分析有更深的理解；
更容易得到真实的数据结果。
▍产品材料必须以书面形式保存。
这是一件非常非常非常重要的事情，请记住。
刚入职的时候发现公司里没有产品文档可以分享。明白产品基本靠多使用；要修改一个函数，基本上依赖于处理程序的内存。
这是一种非常传统和不科学的方法。一旦处理者离开，接收者分分钟就被迫离开，开发者可能要找到相应的代码，只解决了解大概情况的问题。
其中，最重要的是产品增删的进化史和相应的需求文档。
这样做的好处是:
出现问题或者需要优化的时候，可以根据文档找到具体的参考；
从历史中了解变化有助于需求管理；
促成项目的移交。
▍要求应该完全靠岸。
工作中，经常需要和第三方沟通对接需求。这个第三方可能来自公司外部，也可能来自公司内部的其他团体。
有些产品认为既然是技术对接，技术对接之后什么都可以做，然后就把什么都扔给技术。但事实真的是这样吗？
也许流程可以先梳理一下；
也许对接文件可以让对接方先做好准备；
也许测试环境可以让对方先设置好；
也许要配置的接口可以由对方先设置；
……
与第三方对接存在很多漏洞(文档不规范、接口不好、对接时间长等。).产品最好在对接前期就做好准备，这样对接的时候开发者会更方便省时。
尽量把对接控制在可控范围内，而不是任其发展。
这样做的好处是:
和你合作的开发者会更舒服；
对接时间相对可控，所以计划上线时间相对可控。
▍在拉人参加会议/讨论之前要做好准备。
越到后面工作，越讨厌开会，有时候甚至是一小撮人的讨论。为什么？
往往没有讨论的重点。
有重要的观点，但都是集思广益。
是的，头脑风暴是好的，但同样的事情，如果每次会议都是头脑风暴的形式，那就很让人心烦了。
所以，无论是开会还是讨论，都要把讨论的话题和围绕话题的一些点列在前面。这样大家就可以根据栏目内容进行有条理的讨论，更容易得到结果，从结果中把事情做好。
个人思考
▍不要害怕变化
比如产品比较小的时候，可以有很多需求，很多方向，大家都在不断调整。这时候可能会有一些因素(公司要求产品盈利等。)，而你原来安排的下一版的需求做不了或者需要延期，那就优先考虑其他的。也许这时候你已经完成了所有的需求分析。一旦改变了，你就得赶紧做点新的。
这时候你该怎么办？
其实我理解很多人会因为个人原因拒绝这个改变。每个人都是人。他们怎么会不明白呢？
但是，产品制作者不能这么做，因为你的坚持可能会导致团队做错事。
这时候需要考虑的不是增加个人工作量的问题，而是整体产品好不好的问题。如果确定是为了整体产品更好，那么就该抛弃个人的负面情绪，顺势而为，好好执行。
这样做的好处是:
对整个产品和团队成员都有好处；
顺便锻炼一下自己的应变能力和心脏承受力。
▍把罐子放在你的背上。
产品经理是需求的起点和终点。只要你在线，就说明你允许这种在线行为。
如果程序上线后出现大bug，某个功能被用户诅咒致死等等。，产品经理要学会承担责任。如果他不能承担责任，他至少应该先把锅背上。
端正态度。不要因为开发代码bug太多，测试不给力就出问题。毕竟你才是最终决定要不要上线的人。
这样做的好处是:
团队信任你；
学会承担个人责任也是很大的成长。
▍看着系统灵活地运转
举个例子:一般公司都会规定版本上线的时间。但是如果App在上线前发现大bug或者影响体验的bug。那我该怎么办呢？是不是延迟上线，修好后再上线？还是不管怎么样，系统说涨，那就涨？
不同的人有不同的选择，但出于对产品的考虑，选择前者是否更好？
一上线，bug反馈papapa，崩溃率papapa，用户差评papapa。这真的是你想看到的结果吗？
这时候你又要因为这些papapa而去修复重装一个新版本，好曲折。
当然，我并不是鼓励不遵守制度，而是说灵活地遵守制度。毕竟情况复杂，人活着。
▍实施理念:成功落地本身比理念更重要。
很多人会说“我想法很多”“我思维活跃”，但真的有你想的那么重要吗？
我也这么认为之后呢？它必须被执行。如果你不能执行，那么你的想法什么都不是(当然这里排除了单纯依靠想法来融资。毕竟你的执行是找人为你的想法买单)。
不要看重想法，但也不要太较真。真正创意意义上的想法，我觉得，注定是少数。而大部分产品经理，你要知道你可能暂时没有这个能力。
你以为我看着你的能力去死吗？不完全是。其实所有的创新都是基于空的，都是基于对大势、环境、行业或者用户的深刻理解。没有一定的经验是出不去的。我个人是不相信意外的。
既然暂时不能创新，那就做好当下，在实施的过程中积累，为未来做好准备。同时，从结果论的角度，我们也要对结果负责。
▍的节 *** 不应该太高，但底线必须是
很多产品经理吐槽产品之间互相学习。先不说你们的产品长度差不多，就说你们像素级抄袭。这其实是一种愚蠢的行为(电商公司看起来都一样。你能说他们抄袭吗？)。
我不是反对这些人的想法，而是说:
应该借鉴什么功能，用什么形式表现出来，都需要根据不同产品的特点来选择和体验。即使借鉴，也做了很多思考和改进。不同的是，有些产品可以借鉴成功，有些则不行。
跨界借鉴在行业方面更有意义。
如果你不能理解正面的解释，那就反方向想想:互联网上有没有什么产品功能或者产品形态是真的没人做的？如果真的没有，那你就去帮人家创业吧。
既然是现有的东西，人家的坑都帮你踩过了。为什么不借鉴现成的东西，根据自己的产品进行改进呢？是不是所有的坑都要自己去踩才满意？
大家都是成年人了，不要相信抄袭是可耻的。你应该认为从中学习是有益的。
大家都是成年人了，不要太依恋自己的爱豆。乔布斯不是所有人。
以上，“产品参考”的观点是想说明，在思考很多事情的时候，我们不需要一对一。解决问题的方法是好的，我们不需要给自己设一条无形的线。如果我们做不到这一点，那我们就做不到。那样的话，你会自杀的。
虽然不需要那么道德，但还是有底线的。与违法乱纪相关的事情不能做，这里就不赘述了。
好了，暂时想到这么多。如果你觉得有什么要补充的，可以在评论里告诉我~
注:本文由人人作为产品经理原创发布。如需转载，请联系产品经理官方授权。作者:killifer，微信微信官方账号:killifer，金融资讯&工具产品经理。脑洞大、笑点低、间歇性“问题”的理工科实力比女生强。
欢迎分享，转载请注明来源：内存溢出
微信扫一扫
支付宝扫一扫
评论列表（0条）