那些年，我掉过的产品坑（一）

根据自己在产品工作中碰到的问题做一个总结，期望这样的总结能成为自己更优秀的垫脚石。也许它们让一些人看来有些幼稚，但是每个人的成长都是螺旋上升的，没有人可以直接造第三层楼。

▏会议主持

产品经理每天有开不完的会是很正常的。那么如果是自己主持一次会议，第一，与会人员最好控制在10人以内，人一多，效率就会急剧下降，你一句我一句，1小时的会议拖成2个小时也是很有可能的（经常发生）。很多时候会后找相关负责人单独沟通，有时候效率更高；第二，与会时间最好控制在45分钟以内，把要讨论的问题提前发邮件通知到各位，让大家心里都有数，开会的时候控制好各位的思维，不要太发散，有时候大家自认为的和实际的可能不一致，会出现大家不在一个频率上的尴尬情况，所以需要主持人把控好，及时提醒纠正。

▏思考换位

很多时候我们产品经理做出一个功能会觉得自己很牛，自己就是对的，把「用户体验」当作说词，那么，我们要冷静回想一下，这真的是站在用户的角度考虑问题了吗？自己很喜欢自己的设计，你能保证用户也喜欢吗？自己能把逻辑讲得头头是道，用户懂你的逻辑吗？你是商业目的为先，还是用户体验为先？你是希望用户快速做决策还是把大量信息堆在用户面前让用户自己选？不同的答案就会产生不同的设计结果，需谨慎考虑。换位思考其实挺难的，你不能保证自己想切换思维的时候就能切换，具体怎么提高，我总结了两种方式，一是做用户访谈，不用很高科技，拿着原型问问身边的同事，他们想要什么，你会发现很多的想法跟自己完全不同；二是看心理学的书籍，看看别人都是怎么考虑问题的，跟自己的思路有什么不同。

▏沟通表达

沟通能力作为一名产品经理来说再怎么强调它的重要性都不为过。首先，沟通的过程中不要和别人发生不愉快，这是最基本的，也就是要会说话，包括说话的方式、角度、语调、声调，换句话说，要让别人愿意听下去，先不管讲的内容是什么。这些事情搞定后就要升级沟通能力了，也就是每个产品经理都会经历的需求评审、交互评审、设计评审、技术评审等环节，俗称PK。这个过程会和形形色色的人沟通，每个人的性格都完全不一样，而且同一个人在不同时间段的状态也是差异很大的，比如在你和他讨论之前他可能刚刚跟另外一个产品经理「争吵」完，情绪还没缓过来，这个时候找他去沟通，就会超出自己的预估，也有可能刚接到电话得知老婆跟别人吵架了，思绪还在老婆那边。所以要对环境作出快速正确的判断，然后达成自己的目标。总的来说，遇到这种情况，通常应该尊重理解对方，学会换位思考，这是很重要的。其实每一次的PK都是类似谈判的过程，可以用一些有效的谈判方式来进行沟通。还要说一点，沟通前，得自己先把问题逻辑想清楚，自己这边先过关。

▏原型制作

我看到周围的一些同事用什么原型软件的都有，有人用 Axure，有人用 photoshop，有人用sketch，有些人甚至不用软件，一直靠文字和截屏来说明问题，这些都可以，哪怕直接口头表达，都没问题的，只要能达到目标就行。但是就我观察到情况来看，在需求评审时，如果没有原型，开发会抱怨，因为一旦牵扯到逻辑或交互的修改，很难表述清楚，在开发的脑海里形成不了具象的概念；如果有原型而且包含颜色丰富的视觉，交互会抱怨，因为这抢了交互设计师的工作，每个人都需要存在感。所以我比较推荐的做法是画灰度原型，而且要尽量精准，什么叫精准，不同的元素要用不同的灰色对比度，文案要用实际真实的文案，而不是随便写几个汉字，这样大家在评审事就能专注于功能、交互、文案等信息了。另外对于原型软件的选择上，我的原则是越轻便越好，在最短的时间内完成目标就是最好的，因为自己负责的是移动端，一般就使用「墨刀」这个软件，用了一段时间非常不错，也推荐给大家。

▏文案细节

我听说有些公司在制作一款 APP 时会把APP中的文案部分单独拿出来给一个公关部门负责，产品经理只要负责功能就可以了，我觉得这种做法是很愚蠢的，我们是产品经理，不是功能经理。不能整体把握会让自己的视域变窄，要不得。我们在设计APP的时候不能只关注功能逻辑，文案也很重要。文案在哪儿呢？一个就是我们打开APP很明显就能看到的各种标题、段落文字，一个就是各种输入框中灰色显示的提示文字，还有当我们触发不正确操作时弹出的 Toast 上的文字，这些都需要我们去关注，比如一个 APP 中，有些地方写「手机」，有些地方写「手机号」，有些地方写「手机号码」，是不是考虑需要统一下？有些地方写「请填写」，有些地方写「请输入」，是不是考虑需要统一下？有些地方用全角括号，有些地方用半角括号，是不是考虑需要统一下？功能改进能看出一家公司的创造力，文案细节能看出一家公司的专业度。不注重细节的产品经理也永远都只会是个功能经理。

要转载我的文章，请带上作者名称，原文地址的超链接，不允许修改我的标题，如果你无法全部满足上面3个要求，请不要转载，欢迎大家举报。