你如果是信奉极简主义，恨不能把主页改成这样：
当然，逼格高了，感觉用户视觉上舒服了。但你作为用户来用的时候，发现作为大而全的电商网站，更多信息展示显然是比界面简洁更重要的。
所以永远记得，先满足需求，再考虑加特效，duang duang 什么的。
3.理解需求背后的原理和原因
产品经理很多时候是需求承接方，有时需求来自老板，有时需求来自同事，有时需求来自用户。这时候，一定要分清一件事情，这件事情是非常非常容易被搞混的，就是：他们给你的是明确无误的需求还是只有实际的方案！
比如，老板的需求可能是这样的：
给我做个客户端实时记录美甲师 GPS 的功能来。
作为忠贞不二的员工你可能就落实去了。但实际上，你需要搞明白老板为什么这么做。在再三的追问下，老板可能就告诉你他的原因是：
因为美甲师经常会为了奖励刷单，也就是不出门让朋友来下单。GPS 用来帮助判断这个。
所以你理解了老板的需求，那么下一步做的时候就清楚了：要查美甲师是不是刷单，没有必要实时做记录，这样增加美甲师端的流量消耗，也增加了服务器的负担。正常的接单时间都会大于半小时，因此完全可以将功能改成：
每半小时记录一次美甲师的 GPS。
任何人（包括用户，严格说尤其是用户）给你提需求时，有时候只是根据自己的需求拍脑袋想了一个方案建议你做，但作为产品经理，要做的是理解其背后真正的原因或者原理，转化为更合适的产品方案。
4.有写文档或者做记录的好习惯。
大公司会有详尽的文档撰写要求，但初创团队和小公司考虑到效率问题都很少有写文档的习惯。
许多人会觉得口头表述和口头确认是初创时期自然而然的工作方式，实则不然。即使最粗糙的产品功能说明文档、交互文档和需求文档，都要比任何事情全靠口头解决要好。文档和记录是规范产品研发的重要参考，是当大家有了争执可供确认的凭证，以及最后产品版本验收的查验标准。
半个月后，没人记得现在做的这个功能当初为什么决定要做，像这样尴尬的问题就不会出现。
我平时用的记录工具都很常见，供参考：
Evernote | 你的工作空间 ：会议/讨论的记录；零散想法/点子；脑图
Keynote (PowerPoint) ：交互；用户体验的想法
Sketch ：交互
Numbers (Excel) ：数据/信息的结构
5.考虑将来可能的变化。
除了空间维度上要考虑更多情况，在产品方面，还要考虑时间维度上的状况。
包括但不限于：
版本的命名和意义（不要让用户困惑）
版本的更新周期（不要让用户觉得烦）
强制改版的情况（旧的功能无法使用。强制改版显然不宜太频繁）
将开发功能的预备（与技术沟通未来将开发的功能，提早在代码层面有所准备，以防经常做太多改版）
提前考虑埋点的情况（用来做用户行为分析）
要上 App Store 的应用，在做以上这些考虑时，一定要把审核时间算上
6.正确地完成事情，是衡量产品经理称职与否的标准
很多人问我怎么才算合格的产品经理或者产品负责人，我都会说关键词在于“完成”和“解决问题”，而不是“创造”、“创新”、“更美”和“更牛逼”。后者当然也重要，但应当只能算是锦上添花。
如前面所说，产品经理不是那种闷头想牛逼点子的人，而是把老板对产品的定位落实到方案上、把同事们的需求落实到功能的配合上，把用户对产品的反馈落实到迭代改版上的人。
举例来说，作为淘宝的产品负责人，你最重要的工作就是让用户很方便、很顺畅地买到想要的商品，其次是让商家很方便、很顺畅地售卖自己的商品，再次是让平台的营销活动很方便、很顺畅地进行。其它的都不重要。
而作为百度的产品负责人，你最重要的就是让用户很方便、很顺畅地搜到自己想要的东西。
我简单粗暴地总结了这样一个对比表格，你可以感受一下：
因此，对于产品经理或者产品负责人来说，“整体使用流畅、没有硬伤”比“这个功能真酷真炫真牛逼”是更令人值得骄傲的褒奖。
7. 让大家喜欢也是很重要的小事
