我们今天分享几个产品经理工作的内容，要特别注意的工作细节，都是我这几年工作中的一些总结，大家可以参考看看。
1、要持续关注市场
互联网行业，无论是哪个赛道，都属于技术型的，如今的技术大家也知道，日新月异，尤其是AI加持下，发展更快了。
所以作为产品经理，不能故步自封，要开放，要持续关注相关行业的市场动态，持续关注那些新技术，看看头部公司是怎么做的，市场上又出现了哪些新产品、新功能，这个对于你的产品设计帮助很大的。
2、设计产品，先明确产品定位
我们在设计产品的时候，第一件事就是要先明确产品定位，你的这个产品，是要做什么，为什么做，用户群体是什么，有哪些功能，等等。
先去想，方向比你的努力会更重要的。
3、要找到真正的用户
这里的用户，指的是真正去用你产品的那些人，比如你做一个产品，你的老板让你这么做，但是他不是你的用户，真正使用的是下面那些人，那你一定要以使用的那些人为主。
老板的话必须听，因为他是老板，但又不能全听，因为他不是你的用户。
我最近就遇到这样一个问题，公司的财务付款报销流程，有人反馈，老板往下推，要求怎么着怎么着，他的出发点是好的，从全公司维度看，但是你的关于功能的优化调研，一定要以公司全部员工出发，因为他们走付款报销，他们在用，你的老板不会去报销的。
甚至于部门的负责人考虑点都要减少，因为他们用得也很少，一个月都没有报销一次的，他们最多是参与审核，可以考虑审核这个点，更多的，他们是关注下面的人用起来是否合适。
所以，找到你真正的用户，解决他们的痛点，这才是根本。
4、要多跟用户沟通
产品经理对接需求，一定要去跟用户沟通，有事没事的，多去聊聊，看看他们最近使用系统有没有什么问题，有没有一些改进的想法。
很多人其实都是被动型的，你不去问，他不会说，尤其很多岗位，可能没有跟你直接对接，中间有一些对接人，转述来转述去，味都变了。
所以你多去跟他们聊聊，可能会有很多意外之喜。
5、要精细化需求分析文档
需求分析是需要很细的，因为我们的需求分析，需求方案会涉及到用户确认，需求文档又需要你的开发团队处理，尤其是后者，如果你很粗，一句话需求，技术也不知道该怎么写代码。
所以要写细一点，一是可以让开发测试更好地理解需求，二是也可以存档，便于后续的产品经理查看。
6、重点信息同步一定要邮件
这个我很多文章都提过，就是为了防止后续的问题扯淡。
说白了，同步你们是一回事，自己留有证据也是，万一你事后不认，这个就是用来打官司的。
哪些一定要邮件，比如发版说明、方案确认、重点问题处理（刷数据等）、上线确认等等。
你觉得需要对方知晓，或者需要他的上级批准审核的，且内容比较多的，方便查找的，这些都要。
7、要想方设法跟用户宣导新功能
我们公司每个季度会有满意度调查，我们部门也参与了，分数其实挺高的，但有一项我很意外，大家不知道每周上线的内容。
其实我们上线之后，会有邮件发送每个部门的需求对接人的，但是大家还是不知道。
所以我调整了几个方案：
1）继续保留需求上线精准信息同步，在需求池管理同步提需人员和涉及人员，会有钉钉即时提醒。
2）发版邮件改为发送全员。
3）每个子系统增加本期发版功能提醒，大家一进入系统就可以看到，这也是很多系统比较喜欢做的发版设计。
4）每个菜单更新功能说明。
5）重点功能，让负责的产品经理去宣达讲解。
我们要考虑到，很多用户就是小白，你觉得很简单的功能，他们不懂的，更何况他们也没有全部功能权限，你的一些需求描述，他们也不知道干嘛的。
多去为他们考虑下，多去宣导一下。
8、学会用数据去沟通
数据是不会骗人的，你费劲心思搞了很久，投入了大量人力、物力，最终上线的这个功能，只给公司带来了很少的收益，这个就是问题，数据摆在这里。
或者说排需求优先级，你的需求价值就是这点，我们花一个月时间去做，只能节省你们每天5分钟的工作，这也没啥提效的，还花了技术部这么多资源，这也是数据。
用数据去沟通，很有说服力。
9、要学点技术，并且要多听技术的
产品经理如果不懂技术，也还好，至少前面几年是可以的，初级、中级这种，但要再往上升，不懂技术，会难一点了，因为缺少技术，会让你缺少很多判断的依据。
我们学点技术，对于需求可行性判断是更友好的，也能更好跟技术沟通。
当然，我们的沟通，不是为了班门弄斧，你那点技术，还是差很远的，但至少他们聊的，你能了解大概。
另外，还是要听下技术的建议的，你的一些方案，技术实现上是怎样的，是否合理，是否有其他更好的方案，他们都可以给你参考，对于你的产品设计，帮助很大。
10、要学会方案替代
比如用户给你提个需求，需要系统帮忙处理下，一些工作流程的文件存档，便于查询。
如果你觉得需求不合理，驳回是一回事，还是要解决用户的问题的。
这里就可以找个方案替代了，比如跟他说可以找一款文件存档工具，比如Microsoft365、腾讯文档等，又可以存文件，又可以共享，这就可以解决用户的问题。
11、一定要有成本意识
抛开成本谈项目都是耍流氓。
真的，公司预算就这么点，跟你说要在很短时间内实现一个功能，说字节、阿里都是这样的，这就扯了，你不看人家多少技术团队，人家的成本有多少。
我们跟老板聊项目的时候，也要把成本加上，这个功能要上线，价值多少，我们技术部要投入多少成本，这个是否划算，等等。
12、项目管理要留有余地
我们在做项目管理，或者最简单的需求排期的时候，一定要预留一部分异常处理、临时紧急问题处理的时间，不能说得太满了。
把自己的时间压缩，你的所有的工作，从产品调研到需求设计到最终的开发、测试、上线验收，都要压缩，需求上线是个长流程，中间可能出现的问题很多，就算没问题，突然插入个临时需求，或者系统出现bug处理，这些都会耽误时间的。
所以，这些都要考虑进去，要不然，就会影响项目进度。
13、要允许用户需求变更
所有的流程外的内容，按道理讲，都是不合理的，这些紧急需求、需求变更，都是。
但是，任何事情都是相对的，存在又是合理的。
很多需求，我们在前期需求调研时，想得再多，问得再细，在开发过程中，或者上线后使用时，会存在一些跟需求不一样的点的，我们要允许这种情况发生。
可能是用户提需问题，可能是我们调研问题，我们的最终目的是解决用户问题，做好产品，记住这个就好。
可以加个需求变更流程，允许用户触发，毕竟人无完人。希望简单的文字对大家的产品工作有些帮助。
