产品经理经常遇到的问题

每个产品经理在开展一个项目的时候，都会受到各种各样的问题，最烦躁的就是面对问题却不知道怎么去入手解决，就像参加达喀尔拉力赛——在这项刺激得要人命的赛车运动里，没有地图，你怎么走？

今天要跟大家分享的内容，就是想给你一份地图，告诉你这些问题的方向，当你明白了制约产品发展的因素，就可以想办法来规避和利用这些因素了。

产品经理是对人的基本素质要求很高的一个职位，而对于一些刚入行的初级产品经理来说，经常会遇到各种各样的问题。回想自己做产品的这几年来大大小小遇到的问题不计其数，大到整个产品的方向，小到一个图标的像素与颜色值，今天我就来说说产品经理经常遇到的问题，希望能对大家有所帮助。

1、无从下手问题

我接下来该怎么做，这是我在产品群里面听到的与我刚开始做产品时遇到的一个问题，而遇到这个问题的产品汪们一般有一个共同的特点就是，入行不久的野蛮生长型产品汪。

野蛮生长型产品汪是之前一个同行定义的，我觉得野蛮生长这几个字形容的很贴切，野蛮生长型产品汪有这些特点，没有经验、没人指导产品工作、大多数奋斗在创业公司，而且还是挑大梁的，对产品知识的强烈渴望。在这个APP泛滥的年代，这类产品人员会越来越多。

对于一个没任何经验，也没人指导，还要去做决策与把控一个产品的人来说，有一种凌乱和无力感。有这种感觉的原因是因为所做的决策没有足够经验或者足够产品知识去支撑，也就是说没底气。而现在书上说的东西看了会觉得很虚，不实用。

前段时间我的一个朋友刚入行做产品没多久，公司交给了他一个项目，他要我推荐一些书给他看，我就把我刚入行所看的书推荐给他，他说这些用户研究，用户体验，信息架构什么的讲的太虚了，不实际。看了还是不知道怎么做，问我有没有像工具书那样，教你第一步怎么做，第二步怎么做的书，现在是有很多这种方法论方面的书籍，但这些书对于没有任何项目经验的人来说看了，只知其表，不明其理啊，会造成天天用户体验什么的这些专业名词挂在嘴边。

第一个问题，感觉产品知识很虚，虚的原因归根结底还是没有经历一个从0到1的完整的产品流程，只有经历了，书上所讲的知识才会引起你的内心共鸣，没有经历过的脑袋当中很难有这些概念或者说这些概念不强。

第二个问题，很迫切的想要知道接下来该怎么做，产品知识比较广而杂，遇到问题后很难从杂乱的知识储备当中拟定有底气的解决方案，光凭自己看书或在网上看文章博客获取知识很难吧这些知识串联起来，形成一个自己的产品知识体系。

所以，前期要做的是把所获取到的知识归纳整理，形成自己的产品知识链条，再次获取到新的知识的时候。把这部分的知识对号入座的归纳到你的知识链条下并加以分析与理解，当你的产品知识达到一定的储备量的时候，你再遇到问题的时候你的思路就比较清晰了、不会像之前那样漫无目的毫无头绪的瞎抓。

这里推荐用思维导图的方法去整理知识，好处谁用谁知道。

2、项目失控的问题

产生这种情况说明项目管理已经存在大的问题了，要做到的是提前预知，避免这种情况的出现。

万一出现了，首先要深入了解原因，多问自己问题，是人的原因吗？因为开发是新人？负面情绪引发懈怠？还是沟通不畅？再看如何解决。

（1）、项目内搞定

项目内可以搞定吗？回答这个问题的关键是找关键路径。看从非关键路径是否可以抽调资源到关键路径上，这是要注意关键路径的变化，如果没法解决，项目外解决。

（2）、项目外搞定

项目外也就是看项目管理三角形，在资源、时间、范围上找解决方法。

（3）、跨团队的资源协调

要清楚的认识到，我们不是去要资源，而是要取得一致目标。是我们大家一起要把这个事情做出来，讲讲清楚要做什么，得到认可，把事情变成大家的事情，而不是变成对立。要有结果，要及时反馈（具体可查看马海祥博客《产品经理必备的7个特质》的相关介绍）。

3、团队配合问题

当时在小公司小团队时这个问题不显著或者说不严重，后来到大团队时我发现这个问题就比较严重了，主要的就是，各自做各自的，不相配合，一般来说，有两个方面：

（1）、产品团队内部工作流程混乱

不管是小型项目也好，大型项目也罢，多多少少会出现以下的一些情况，没有产品规划，团队成员不知道为什么要做这个产品，也不知道下一阶段要实现那些功能，产品的目标用户群是谁也不知道，或者对目标用户群比较模糊，需求评估，优先级定义，等这些需求分析必须要做的工作没有按照需求分析的流程走，当然，苦逼的产品经理有时候会身不由己，大家都懂得。

产品成员各自有分工，各自会负责一些功能模块或者独立的产品，没有考虑到功能模块之间的耦合度和关联关系，都只负责自己的事，没有站在全局的角度去思考问题，有关联的模块事先也没沟通好，导致的后果就是改需求，严重的会导致产品出问题。在写产品文档的时候，一些很重要的功能没有与开发商量，自己理所当然的就往下写了，结果在开发过程中需求频频出现问题。

（2）、产品团队与其他团队配合的工作流程混乱

产品团队与开发团队、运营团队之间配合出现问题，主要的点有这些：

①、开发按照自己的想法进行开发，产品也没有及时去评审开发结果，直到上线时才发现开发出来的东西与自己想要的差得太远。

②、因为产品团队事先没提运营方面的需求或者双方沟通的不够，上线后，运营团队准备不足，导致发布后效果不佳等问题。

总结发现，很大一部分问题是因为团队之间沟通不够与协作不畅导致的。目前国内外有一些不错的团队协作工具，如trello、effevo等，可以利用这些工具把各个团队链接起来，这样测试、产品、开发等团队把任务、计划等都记录在这个上面可以很好的提高效率，辅助沟通，帮助记录，从而避免因沟通与协作不够而出现的问题，例如：开发把任务写在上面，这时就很清楚的知道每个需求完成的时间点，从而对每个需求进行跟踪检查，这样就可以很好的保证产品质量。

4、沟通问题

关于沟通问题，主要遇到的情况是：信息不同步、信息传达不准确、偏重口头沟通。

（1）、信息不同步

主要是有的成员知道，有的成员不知道，有可能出现的问题就是不知道的成员做的一些工作有可能白费了。

最近就遇一个比较典型的问题，在开发过程中，因为时间原因开发计划有小变动，而这个变动没通知到测试（自以为测试知道了），庆幸的是没造成工作白费。

（2）、信息传达不准确

主要是对信息理解的偏差，按照自己的理解和想法去执行，也没有与信息发布者进行反复确认，从而导致工作返工，造成资源浪费。

（3）、偏重口头沟通

经常遇到的就是有些需求没写到需求文档中去，或者是漏掉的，在开发过程中就口头与开发讲解，有些逻辑复杂的需求，在口头讲解的现场是无法想得很全面的，也没有及时更新到需求文档上面去，会造成需求实现有偏差或者隔了几天都忘了这事了。

解决这个问题的方法就是永远不要“我以为”加沟通、沟通、沟通重要的事情说三遍。

5、产品经理建立威信的问题

其实产品经理需要建立的不是威信，而是信任。这里提到一个非常有趣的概念：Johari Windows（乔哈里之窗）。乔哈里之窗能够用来展现、提高个人与组织的自我意识，也可以用来改变整个组织的动态信息沟通系统。

乔哈里之窗把人的内心世界比作一个四格的窗口：

The Open Arena：开放区，自己和他人都知道的领域。

The Hidden Facade：隐藏区，自己知道别人不知道的领域。

The Blind Spot：盲区，别人知道但自己不知道的领域。

The Closed Area：封闭区，双方都不了解的领域。

真正有效的沟通，只能在公开区内进行，因为在此区域内，双方交流的主题是共知的，沟通效果是会令双方满意的。实际沟通中，很多情况下信息不对等，处于封闭区，导致沟通无效，要使得沟通更有效，需要增强信息的真实度、透明度，进而扩大开放区，扩大开放区的方式可以经由自我坦诚，或经由反馈。

如果在团队管理的过程中，遇到能力强但固执的项目成员怎么办？

（1）、识别出其固执的原因。

（2）、和其身边的朋友多沟通，对其个性和行事风格等更多了解。

（3）、使其承担责任，成为某个课题的owner，自我价值实现。

（4）、多搞团建，和团队融合。

（5）、不能被团队认可，请出项目组。

另外，PM对技术方案影响越少越好，要认清PM的职责，是带领团队在竞争中取胜。要识别出可以对技术方案或业务拍板的关键人物，他们去负责（具体可查看马海祥博客《产品经理做决策时要注意的一些问题和要点》的相关介绍）。

6、跨团队的资源如何协调？

要清楚的认识到，我们不是去要资源，而是要取得一致目标。是我们大家一起要把这个事情做出来。讲讲清楚要做什么，得到认可，把事情变成大家的事情，而不是变成对立。要有结果，要及时反馈。

PM对技术方案影响越少越好，要认清PM的职责，是带领团队在竞争中取胜。要识别出可以对技术方案或业务拍板的关键人物，他们去负责。

这里又涉及到PM正确的心态应该是怎样的：

（1）、善假于力，融会贯通。对人，要知人善任，了解团队，了解成员的长处短处。对事，项目管理各个环节都要融汇进去。

（2）、正向关注，助人自助。对人，给人机会，也要慎重淘汰。对事，接受挑战，积极正向。

7、需求变更频繁问题

需求变更频繁问题在团队中是一种司空见惯的现象了，貌似到了变更是正常的，不变更就不正常了的一种境界了。变更可以原谅，但不要频繁。

变更的原因可能是因为外部或者内部的原因，外部原因是指公司环境，市场环境，老板的决定等原因，这些原因可能是无法抗拒的，但内部原因是可以避免，如：尽量避免自己的逻辑不清晰，加强对文档质量的把控，不清晰或者不确定的地方多与团队成员沟通，不要抱有到时候再说的想法等。

8、考虑理想多，忽略产品的其它状态

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

初始状态就是刚刚开始使用的界面，极多页面我们可以理解为当数据量非常大的时候，整个界面的效果，这里不阐述具体的解决办法，只是要提醒忽略的同学，这些不同状态都很重要。

另外马海祥提醒大家一下，伴随着用户操作以及我们定义实体对象属性不同，在不同的场景下的相关界面与规则定义也是如此，比较好的办法就是绘制比较详细的逻辑流程图，把每种不同判断场景下的规则明晰定义。

9、过度追求完美，导致进度失控的问题

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

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

所以，在定制迭代计划时，最最可怕的就是追求所谓的完美，从产品的生命周期来讲，不会有一个完美的产品存在，永远也不会有，我们能做的是让产品尽量满足一个时期的核心需求，用20%的精力解决80%的问题，如此而已（具体可查看马海祥博客《产品经理该如何解决产品跟不上运营需求的问题》的相关介绍）。

10、如何度过产品需求的空档期？

产品经理如何度过产品需求的空档期？对于这个问题，简单来说，有以下几点建议：

（1）、看数据，数据分析做产品优化以及迭代准备；

（2）、做客服，了解用户心声，了解用户对产品功能的反馈和建议，提取关键点，也为迭代优化做准备；

（3）、看竞品，了解行业动态；了解竞品是否推出新功能，为什么推出某新功能，能否适用自己产品；了解整个行业的大方向，判断自己产品是否偏离轨道；

（4）、项目跟进，跟设计和开发沟通，能否如期完成，是否遇到困难，沟通调整方案（这点你已描述）

（5）、跟运营了解产品上线后的运营方案，协作优化运营策略等；

（6）、开发后期可以做下黑盒测试工作，看看开发初期效果；

（7）、根据自身能力的不足以及自己的兴趣爱好，补充一些相关知识。

以上就是对自己刚入行所遇到一些问题的归纳与反思，希望对你们都有帮助。

马海祥博客点评：

在工作中，每一个人都会遇到很多问题，面对问题，我们应如何解决，如何处理，怎样把问题化小，最终使问题消失，这些都是值得探讨的。

有时，问题与困难并非导致工作开展艰难的原因，而决定因素往往是你对待困难的心态，看待困难的角度不同造成了困难过后的结果不同，多数人苦恼的原因大多是因为他们面对困难时的负面，消极的情绪，而非困难本身。