我这里所指的『坑』不是一个贬义词，因为经历过这些『坑』的磨练之后，你会积累更多宝贵的经验。注意，我这里要说But了，在你没有填补好这个『坑』并且走过去的时候，你会因为『深陷其中』而异常的痛苦，甚至想要放弃，相信我，这些感受我也都曾有过，所以，我们今天来一起看看这些『坑』都是什么，如何避免，又如何后知后觉。

1、凭感觉，跟着感觉走

首先，我不得不承认，有一些有天赋的、以及后天通过多年经验积累起来的『产品经理』真的完全是凭着感觉去做事的，用户的需求是什么，功能又如何设计，完全跟着自己内心的感觉和经验去走，没有任何的数据、理论支撑，我很佩服这些人，我觉得他们很厉害，但这些人不是我们今天要讨论的目标。

回到正题，当你接手一个需求后，当你挽起袖子准备大干一场的时候，你已经开始『深陷其中』了。首先，你会分析能满足这个需求的功能有哪些，回顾起同类竞品是如何处理这类问题的，等不起市场的用户调研，这时候逻辑和流程已经在你的脑海中飞快的运转了，确实，除了想当然还能怎样呢?

建议：

我得赞你的效率和反应速度，but，做之前先冷静下来分析清楚这里面的来龙去脉，最快的和最合适的，永远只有后者能让用户接受，并且可以形成良性的循环。我建议你在自己没想清楚的时候，不要想当然的去做。你可以去找目标用户听取需求(倾听)，你可以绘制用户画像(需求和功能是否对上了?)，你可以寻求团队的支援(头脑风暴发散思维)。这个问题是『产品经理』在成长过程中需要面对的比较大的问题之一。

2、沟通不足，信息缺失

来，我们回忆一下我们经常输出的产物，①、竞品分析;②、PRD文档;③、产品原型：④、数据分析;⑤、产品规划，等等。

这些产物的作用是什么?

—沟通，高效的沟通。

作为产品的爸比，产品就是你的孩子，『产品经理』所输出的任何产物都是为了让内(研发、设计、测试、市场、运营、推广等)与外(用户)明白，产品的特点是什么，产品有哪些功能，产品能解决什么问题。

但是请你注意，沟通一定意味着信息的缺失，最后你可能悲哀的发现有人居然没有理解这里面的精髓。

建议：

说清楚故事的：time、where、How，把功能像故事一样描述出来，带有场景的功能，能够让别的小伙伴更好的理解你的出发点。

倾听能解决大部分问题，因为你知道了对方的问题在哪里，而不是你的问题在哪里。

3、没有把产品原型放到该有的位置

『产品经理』应该画原型吗?不用怀疑，我的回答是肯定的。因为作为『产品经理』，你需要拥有输出想法的能力。这个与『交互设计师』的原型并不矛盾，而且可以提高彼此的配合默契。

但是现在很多『产品经理』觉得有『交互设计师』画原型就好了，自己本身不需要了，试问如果团队每个成员不能理解你的想法，那最后的后果会是什么呢?你脑补下，那是一翻什么景象。

建议：

在项目初期、迭代初期，绘制简单的交互线框图，与团队成员进行产品特点、产品应用场景、产品目标用户的深入交流，绝对有事半功倍的效果。

4、无休止的需求变更

需求变更，是多少项目的梦魇。

刚上线没多久的功能就要下线，你想研发同学心里作何感想?当初加班加点做出来的功能，就这么付之东流了。你说能没有情绪吗?在项目过程中不断变更需求，导致项目需求不可控，项目进度不可控，产品被无限的延期。

建议：

需求变更虽然是梦魇，但是其实是在迭代过程中非常正常的情况，因为有很多细节的部分要到迭代中才能想清楚，看清楚。

需求优先级排序，这时体现『产品经理』另外一个很重要的功力—核心需求的控制能力。对变更的需求进行排序，根据轻、重、缓、急进行分类，由此判断出哪些需求我们这个版本中处理，哪些下个版本处理，这里体现『产品经理』的另外一个功力—决策。

为什么很多公司要招有相对丰富经验的『产品经理』，原因也是如此，核心需求的把控能力、决策能力，这两项是在工作种不断积累起来的。

5、这是BOSS要加的

这个我想不用我说太多了，不管是创业型团队还是大公司，都有这样的问题，而且很严重，甚至很多项目都因此而流产。并非BOSS的能力不行，而是很多时候在项目中的问题BOSS并不清楚。

建议：

首先你需要明白BOSS这个想法的真实理由，其次你要让BOSS知道你的想法。双向的沟通后，不要急着去改变BOSS，而是作为『产品经理』的你，去理解BOSS为什么要这么做?你们的高度本身就有差别，看到的远近程度也必然有误差，所以这时候需要你们回到同一水平线，了解彼此真实的想法。

在几个来回之后，如果你真的有能力，提案都是有理有据，那么BOSS会慢慢信任你，后面你操作项目会顺畅很多。

总结这5点，可能不完整，但是我想在某一程度能让我们理解自己问题到底在哪里。

FROM 互联网的一些事