产品经理3000问 | 这些细节性的问题，你可以参考

说大道理谁都知道，说设计流程、说工具使用，百度或者谷歌一下搜索一下也能告诉我们答案。但是工作中的细节，因为每个人碰到的情况不一样，而这种细节性的问题是没有标准答案的，需要具体问题具体分析。这一次，让我们来一起听听起点学院金牌讲师团的导师们，针对我们在工作中碰到的具体问题，给出了什么样的参考答案？

Q41：需求挖掘。在领导市场都对产品大方向没概念摇摆不定时产品经理一个人该如何确认大方向？

如何寻找切入点，挖掘有效需求？如何培养自己的市场能力，行业需求把控度，如何学习发现市场的机会点？

答：这些问题都会在《产品经理训练营》里帮大家解决的。

如果说你真的是一位职场新人，整个产品的市场方向是领导或是市场人员决定，我个人觉得你真的无法对市场方向进行左右。哪怕方向不对，也要朝着既定方向去做，在这个过程中去通过市场反馈决定要不要做一些调整。

如果你相对来说具有一定的经验，你可以围绕着这个方向的用户真实需求去提出建议，去切入。可以做竞品分析和老板一起讨论，产品的市场方向是朝着相对有红海的地方去发展，还是找一个竞争相对较小的蓝海，先去把这个蓝海占住，做一个领先者，然后再向其他方向拓展。

我个人觉得没有必要在方向的问题上纠结，一切都需要去实践，在这个过程中，你会更了解用户、了解市场，可以在实践中逐步进行修改。

Q42：APP和公众号、网站定位，渠道多如何分配功能？

答：APP和公众号、网站具有不同的特性，所以渠道分配上也不一样。

网站是PC时代为了宣传自己的一些资讯、功能而做的形态，但现在如果只是为了宣传产品、介绍一些基本的资讯，网站已经不是一个特别好的选择。不管是什么产品，现在做网站无非就是官网，更新的速度也不会太频繁，只是在某些渠道被访问、被搜索的时候的一个承载页面而已，在网站上也不会提供特别多的服务。

不管是app、网站还是公众号都要根据具体应用的类型，应用到底为用户提供了什么服务而去决定。即使是现在，有些服务仍然通过网站去实施，比如说他是TO B的业务，他的用户主要使用场景就是上班的时候，显然这个时候用网站去提供服务，是更科学合理的。

大部分TO C的业务要具体来看，是不是想和用户保持一个高频的联系，用户是不是高频的使用这个应用。这是决定要不要把功能做APP的一个关键。

另外才是说就是这个服务的功能多少与复杂程度，如果复杂度比较高的话用app来实施比较合理，如果是相对比较简单的信息查询、交互用订阅号和公众号就足够。

所以还是看你在做什么样的功能。补充一点，我们在做某些产品的时候，app和网站、公众号是齐头并进的，APP是提供重要功能，公众号用来推送基本的资讯和简单的传播，同时公众号可以为你的APP带来流量。比如说有些做生活服务的公众号，更多的是提供同城玩乐资讯，同时又打造了一个APP去把这些有共同爱好的粉丝转化为APP的用户，他的网站去介绍这个服务，其实主要是为了搜索，被收录，所以他的网站并不会提供更多的服务。

Q43：需求评审的时候怎么控制会议节奏，还能使与会人员有参与感？

答：需求评审是产品经理日常的一个工作，也是非常令人苦恼的：

因为开发人员和老板的不认同，所陈述的内容永远会被PK，在评审中改掉很多内容。 既定时间会被拖延。

需求评审会上，某个特定的需求会引起很多的争论。如果需要控制节奏、让参会人员有参与感，那就是要开发和测试人员积极发言、并且提出相关的问题。

首先，你所表达的功能逻辑他们是否了解，实现上有没有更深层次的细节问题？这个要让大家从不同角度谈一谈。如果之前评估没有完善这些问题，那这时候谈可以避免一些风险。 再者，你可以让大家围绕着这两点展开讨论。但是千万要注意对需求的讨论千万不要太过发散。

评审会议上最容易发散的问题就是对需求本身价值的讨论，这种讨论更多的是考验产品经理把控需求的能力。如果在讨论的时候，产品经理直接跟技术人员讲你要做什么，那技术就会挑战你的想法；所以你要先跟人家讲用户场景，用户反馈也好，就是做的需求背景和能带来的价值，然后再讨论功能实现的问题。

还有容易在技术的可行性上进行发散，产品经理提出了需求，然后技术人员从技术角度进行否定，那么两者就会争吵起来。也许会发散出其他的解决方案，但这个方案并不是产品同学一开始想要的。所以当遇到这种技术实现性的问题时，比较好控制的方式是在需求评审会之前，建议产品经理先把这个需求跟技术负责人进行沟通，事先了解技术实现的可行性、工作量。

把不可行的方法在会下进行纠正，这样在评审会上就可以让大家围绕着功能本身去进行细致的技术评审，大家就不会去挑战它本身的可行性。评审会集中在技术实现上的细节、逻辑问题的缺漏，这些是很有价值的，是一个很好的补充。

如果还是集中在一个点上争论不休，很简单，不管是产品经理还是项目经理，可以把这件事情打断，就是说这个需求已经被大家认可且实现上也没有大的问题，只是细节上存在争议，在A.B方案上的选择上存在争议。会后再各部门进行沟通，小部分人的争议不需要浪费大家的时间，而往往需求评审会会浪费在这些时间上。

如果遇到这些问题，我觉得都可以用这种方法进行调剂。

Q44：接手产品的时候业务逻辑已经被市场人员搞的很复杂，怎么破？

比如同样的点，竞品都只做一种，我们要做3种。想做减法，突出核心功能时，市场却说不行，这些都很重要，不能简化，你没干过市场你不懂。太复杂，做是能做，但技术难度成几何级增加，随之带来的是：bug激增，改进艰难；看似把用户的需求都讨好到了，实际是让用户不知所措。

答：看题目，感觉像TO B的产品。一般TO B的产品具有很强的市场导向性，需要市场人员去洽谈项目合作，用户会对项目产品提出各种需求，市场人员为了拿下项目合作一般都会顺应用户的需求，这就导致功能越来越复杂，这是TO B产品的一个共性问题。

如果面对题目中的情况，建议做一个功能包，把所有需求整理排成版，把所用用户需要的做基础包，把个性用户的需要的应用做成拓展包，这样可以解决产品功能过于复杂，让用户不知所措的难题。

Q45：目前担任APP的内容开发（内容运营），但是同时兼顾一些产品优化意见收集等其他零碎功能，不知道未来的方向是怎样，很迷茫。