▏会议主持

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

▏思考换位

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

▏沟通表达

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

▏原型制作

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

▏文案细节

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

▏思考问题的全面性

如果要对一个功能进行改动，一定要把功能前后的流程想清楚，要留意这些改动会不会影响到别的部门或团队（利益）。比如有个功能叫「意见反馈」，基本每个 App 都会有这个功能，如果把这个功能入口放的层级浅一点，那么用户反馈量会增加，增大了处理这些反馈的同事的工作量；如果把入口放的层级深一点，那么用户反馈量会减少，降低了处理这些反馈的同事的工作量。与之对应的，如果把意见反馈功能的体验优化得很好，则降低了用户反馈问题的门槛，反馈量将增加；如果体验不做优化，用户提交问题的门槛较高，反馈量减少。

说的再简单一点，一个功能的改进也许我们觉得对用户的体验会非常好，但是可能会遭到其他部门的反对。所以思考问题一定要全面：用户输入的信息最后会输出到哪里？输出完后谁去对这些信息进行处理？他们是怎么处理这些信息的？这些都要考虑清楚。

▏产出物的一致性

版本迭代，首先产品经理产出 PRD，接着交互设计师产出交互稿，然后视觉设计师产出视觉稿、标注、切图。PRD里要写清楚每个功能点，包括文案、标点符号等细节，然后要保证交互稿的内容是和功能点保持一致的，视觉稿的内容要和交互稿保持一致。我们都知道一个很古老的游戏叫「COPY 不走样」，要求一个一个人往下传的时候尽量不要出现「走样」，这个游戏规则比较难，看了一两遍就不能回头继续让对方做动作了，但是产品不是，产出物就在那边，沉下心来去比对、去思考。

产出物的不一致，出现的问题就是在技术评审完开始进行开发时，工程师不知道该以哪个为标准，然后又要返工。当然出现的问题不仅仅是这一个方面，还有很多其他问题，不多展开。产品经理要对整个流程负责，交互稿的问题，视觉稿的问题，都是产品经理的问题，是产品经理的工作没做到位。产出物是否一致是衡量一个产品经理有没有入门或者说基本功是否扎实的重要因素之一。

▏需求PK的逻辑性

需求评审会上，经常会出现各种PK，一个人认为这样好，另一个人认为那样好，然后互不退让，争得面红耳赤，这其实是不明智的。评审这个功能到底行不行，把你的道理摆出来，把你的方案拿出来，别人凭嘴撕逼，我们凭行动。

回答一个功能需求到底如何，只要思考以下三个问题：做什么？为什么做？怎么做？三个问题分别对应着产品方向，用户场景，解决方案。把这三个问题想透彻了，PK时可以多自信一点了。

需求评审会中需要保持独立思考，不被带到沟里去。因为难免会碰到一类人他们喜好使用强盗逻辑去说服别人，这个时候要能快速分辨出来，然后进行制止。比如二分式思维，认为不是A就是B；使用了什么类型的论据，是否有来源；有没有在句子中使用带有观点倾向性的形容词……这些都要千万注意。