1. 任何事情要考虑全面，逻辑链条清晰。
很多人认为产品经理就是能想出牛逼的点子的人，其实这只是副业，个人认为把产品流程的设计的顺利圆满且没有遗漏地完成才是天职。
比如，作为涉及用户单端付费产品的产品经理，除了考虑正常购买流程，每个环节的错误页面有补全吗？每种问题的处理情况想到了吗？遇到网络信号不好时界面会是如何的？用户没登录、没绑定支付、没支付成功的时候交互如何？用户登录失败、绑定失败、支付失败的交互又是如何？
所以，这可能是你初步想象到的正常页面逻辑：
这可能是实际的页面逻辑：
这其实是做产品时最常忽略的事。
2. 抛弃功能谈体验其实是在耍流氓
看到一些很炫的 APP，尤其一些很炫又相对比较成功的 APP，我们会误认为它们的成功完全归功于用户体验。
就我从业以及观察来看，不夸张得说，包含交互、视觉在内的用户体验，在用户需求尚未满足前，都是废物。满足用户需求是 1，而用户体验是可以在 1 后面添加的 0.
见过不少 3D 效果做得简直像科幻电影里特效的 APP，给别人演示时一片牛哔赞叹。这样的 APP 有用吗？有用，但能看到的目前只有一个用途，就是拿出来让大家围观...
当然，并不是否定逼格不会影响用户视觉体验。但当你作为用户来用的时候，比如电商，作为大而全的电商网站，更多信息展示显然是比界面简洁更重要。
所以永远记得，先满足需求，再考虑加特效，duang duang 什么的。
3. 理解需求背后的原理和原因
产品经理很多时候是需求承接方，需求来自老板/同事/用户。
这时候，一定要分清一件事情，这件事情是非常非常容易被搞混的，就是：他们给你的是明确无误的需求还是只有实际的方案！
比如同事海外市场广大，我们的产品要扩展海外市场，需求的背后可能只是因为他的一个朋友给他提过这样一个建议，但如果不进行调研，上手就做，结果可能就是赔本赚吆喝，更有甚可能连听都没人听。
任何人（包括用户，严格说尤其是用户）给你提需求时，有时候只是根据自己的需求拍脑袋想了一个方案建议你做，但作为产品经理，要做的是理解其背后真正的原因或者原理，转化为更合适的产品方案。
4. 有写文档或者做记录的好习惯。
大公司会有详尽的文档撰写要求，但初创团队和小公司考虑到效率问题都很少有写文档的习惯。
许多人会觉得口头表述和口头确认是初创时期自然而然的工作方式，实则不然。即使最粗糙的产品功能说明文档、交互文档和需求文档，都要比任何事情全靠口头解决要好。文档和记录是规范产品研发的重要参考，是当大家有了争执可供确认的凭证，以及最后产品版本验收的查验标准。
半个月后，没人记得现在做的这个功能当初为什么决定要做，像这样尴尬的问题就不会出现。
5. 考虑将来可能的变化。
除了空间维度上要考虑更多情况，在产品方面，还要考虑时间维度上的状况。
包括但不限于：
• 版本的命名和意义（不要让用户困惑）
• 版本的更新周期（不要让用户觉得烦）
• 强制改版的情况（旧的功能无法使用。强制改版显然不宜太频繁）
• 将开发功能的预备（与技术沟通未来将开发的功能，提早在代码层面有所准备，以防经常做太多改版）
• 提前考虑埋点的情况（用来做用户行为分析）
• 要上应用商店的应用，在做以上这些考虑时，一定要把审核时间算上
6. 正确地完成事情，是衡量产品经理称职与否的标准。
很多人问我怎么才算合格的产品经理或者产品负责人，我都会说关键词在于“完成”和“解决问题”，而不是“创造”、“创新”、“更美”和“更牛逼”。后者当然也重要，但应当只能算是锦上添花。
如前面所说，产品经理不是那种闷头想牛逼点子的人，而是把老板对产品的定位落实到方案上、把同事们的需求落实到功能的配合上，把用户对产品的反馈落实到迭代改版上的人。
以上是产品从业的一些思考，觉得不仅是做产品工作，其他岗位也可以参考一二。
