入门产品经理遇到的常见问题

1.老版本看着太丑不顺眼，动辄改版

这种情况在产品经理来到一个新公司后时有发生。原因有二，一方面可能是极度想通过这件事努力证明自己，另一方面或许是他对原有的产品看不过眼，就像很多公司的开发工程师在接手别人代码后经常说“写的真烂还不如自己重新编码”。

问起改版的原因，产品经理的回答很可能是界面太难看了——要是我来重新弄一遍，保管又漂亮又好用。这里又不禁想到布棉老师提到的Craigslist，如下图所示。

我相信论长相而言，我们国内大多数产品也不至于丑过这个网站吧？对，就是这样一个创建于1995年、没有1张图片、土的掉渣、只有30左右名工作人员的产品 却在全球50多个国家设有分站，创造了超过谷歌排名第1的人均产出、年营收超过3亿美元的成绩。所以，产品本身的定位与价值内涵没有搞清楚的时候，不要轻 易去否定任何事——此时美丑根本不是任何问题。

2. 设计两头堵，觉得很世界就很圆满了

曾经和一名产品经理讨论一个界面条目展示模式问题，他设计了列表模式，我问道“块状模式也不是挺合适的吗？”他回答“那就再加一个模式切换就OK”。我追问“瀑布流也很好啊，”他紧接着说“那模式切换中再加一个选项就解决了”。

我 接着问：“那默认显示什么模式呢”？他想了想说“那就做一个用户行为调研，或者我们系统中记录用户的行为数据，看看用户更喜欢哪个模式就不行了？而且我们 系统再加上一个偏好设置功能，让用户自己可以设置默认显示的模式不是更简单吗”？他好像受到了很多的启发：“反正用户想到的想要的，我设计上是都能支持 的！”

这样做似乎很恰当——用户自己有了很大的主动权，我们也“似乎”让用户有了更多的主动权。但问题是，会有多少用户来进行这个设置，他们在使用这个功能时会不会产生选择恐惧? 这一个产品的功能越多，就意味着用户的选择准确性和疑惑性增加——会更迷糊而无从选择。

我相信在很多产品的实际设计过程中，大多数人都会遇到这样的问题，我们不妨想象，本来只需要1个门的大厦，我们在1面墙上安装上10道门，第一次来访问的客人是否会发蒙？

张小龙在讨论谈移动互联网产品设计原则时提到“不要让用户选择”就是这样的一个考虑。比如“同一个页面之内，有多个入口；同一个功能，有多个实现方式;同一个界面，有多个展示方式。

这对于用户来说是一种痛苦而非享受，因为他们只会因此而感觉到困惑和恐惧。用户宁可采取重复操作漫长而固定的操作路径，也不愿意使用多变的快捷方式。”

3. 就加那么一点点功能

销售和市场经常会找到产品经理，说用户有一个很简单的需求要求尽快加上去，甚至有时候产品经理凭空想到了一个点子，觉得加上去产品会马上性感很多。于是迫不及待的找到开发说就这么简单功能，而且用户又非常着急，分分钟开发就搞定了——如此想非常危险！

产品是一个有机的综合体，每一个功能模块都是其中的组成部分，彼此之间关系复杂，有可能单纯加一个功能会导致整个系统的逻辑变更以及系统底层的技术风险，这 就像冰山一样，我们看到的永远是表面的一点点，增加一个功能，牵扯到的是产品设计、交互设计、视觉设计、开发、测试等一群人的后续支持，仅仅就工作量而言 就有可能超出计划节点，更别说由此带来的用户使用风险及技术实现风险。

有效的控制方式是做好完善的需求变更管理，将一切纳入到正常的开发计划中，团队彼此做好充分的沟通与讨论，确保这事靠谱。

4. 原封不动“山寨”，自己没有太多想法

信息化如今高度发达，从产品设计的资源角度给了我们极大的便利性，但纯粹的创新设计毕竟少之又少，设计启动后一般是先去找国内外同类产品之后“山寨”。

从竞争和公司发展角度，除去外人“鄙视”的眼光问题，山寨不失为一种快速实现的模式，毕竟没有必要都重复制作轮子。

本人也看过不少的互联网产品直接山寨国外的成熟系统，连界面都属于像素级Copy（logo还算小改了一下）——或许无可厚非吧，但是还是建议这些产品经 理，在拿别人东西设计的同时要有自己的思考和发挥才是更重要的事情，直接原封不动的山寨意味着是顺着别人的想法走，自己本身没有核心竞争力——不管是设计 还是技术都如此，或许在产品发布的第一版能赚取眼球但一定是后继乏力。

在这个点上本人对特别某六零公司的做法深有感触甚至推崇， 大都是抢食其它小公司的创意和想法，但又扬长避短，发挥设计，加之本身的流量优势，于是每击必胜。所以山寨也好，抄袭也罢，都不可耻也不可怕，怕的是不消 化。核心需求是自己的主线不能缺失，解决方案层次可以参考别人的做法，但一定要有自己的思路和想法，如此才能山寨的更好，把前辈拍在沙滩上。

5. 不学习，固步自封

和上章节提到山寨很有关系的是，很多产品经理不主动且善于学习，在很多设计点上沿用自己很老范畴里的知识点，遇到过一个产品经理设计登录页面，还是用了N年前那种论坛注册的三步向导方式，如下图所示。

建议随便去网上搜搜别人的做法，大多都不会是这种设计（除非产品有特殊需求），实际上如此做法带来的并单纯是用户交互繁琐的问题，折射出来的是不去参考借鉴 与学习，对于产品经理而言，这更可怕一些。另外一个故事，2014年面试过一个90后的产品经理，我问你手机上安装的自己喜欢的App是什么？他回答说是 Tom猫，就是会说话变声的那个——拜托！这个软件在几年前就已经风靡全球了，你现在才刚刚知道。

所以作为产品经理或者准产品经 理，应该每天给自己留出足够的时间来不断充实自己，实时刷新自己的知识体系。微信公众号和网站都是很好的渠道（比如人人都是产品经理、优设网、CEO来 信……非常多），另外豌豆荚每周会推荐非常实用、创意、或经典的App，可以安装试试，相信能有不少的收获。

6. 考虑理想多，忽略产品的其它状态

我们做原型、做产品的逻辑设计，经常考虑的是在合理的理想情况下的界面布局、跳转规则，但是有时会忽略其它状态；比如一个列表页面，在没有任何数据的状态、 理想数据条目状态、数据量特别多的状态，可能会更多考虑是理想数据条目状态。我在另一篇文章《优雅的初始页》中曾经提到，所谓初始状态页，实际上是极限状 态页面设计中的一种，极限状态页面包括初始页面与极多状态页面，如下图所示：

初始状态就是刚刚开始使用的界面，极多页面我们可以理解为当数据量非常大的时候，整个界面的效果，这里不阐述具体的解决办法，只是要提醒忽略的同学，这些不 同状态都很重要。另外提醒一下，伴随着用户操作以及我们定义实体对象属性不同，在不同的场景下的相关界面与规则定义也是如此，比较好的办法就是绘制比较详 细的逻辑流程图，把每种不同判断场景下的规则明晰定义。

7. 过度追求完美，导致进度失控

实际上控制产品迭代是开发经理 的职责，但是最初的产品迭代计划是产品经理共同参与制定的，互联网产品都讲求极简与精致，在研发进度管理都在做最小化可行产品（MVP， Minimum Viable Product），通过MVP前期主要走通技术环节、实现产品设计初步目标以及试探市场反馈，后期要依赖于快速的产品迭代进行完善和修正。

道 理大家都懂，但是在迭代的划分角度，从实际操作的角度来讲，真正做到或者最好的少之又少。这其中的原因很多，比如赶进度、老板的死命令等等，但是其中一个 是产品经理的患得患失心理，总觉得缺失了功能产品就不完整，觉得若干小功能放到前一个迭代也不会影响太多，最后导致产品计划的臃肿和开发风险的加剧。

所以在定制迭代计划时，最最可怕的就是追求所谓的完美，从产品的生命周期来讲，不会有一个完美的产品存在，永远也不会有，我们能做的是让产品尽量满足一个时期的核心需求，用20%的精力解决80%的问题，如此而已。

作者：朝阳陆（微信：yak1982）
来源：人人都是产品经理
链接：http://www.woshipm.com/pmd/137349.html