29 | 产品分析的套路（中）：解决什么问题？

前端时间就遇到客户说想要一个点赞功能，后来聊了发现，他想要的是内容社交，但是做项目跟做自己产品不一样，项目根据时间/人力成本来，后来领导也说：需求已经确认了，就不要调整了，😭😭，有点无力感。 二爷，能否抽时间，说说做项目产品与做自己产品的区别，发现做项目一开始没规划好，项目后期很难做好了，任何改动都会被视为成本

二爷说的对，每一个用户需求其实都应该按照这个思路去处理，先问清楚需求的本质是啥，很多时候也许你觉得是这个原因，但是实际上，用户深层次的原因很有可能不一样，甚至都有可能会相反，不理清问题就出方案，可能南辕北辙。

感谢邱哥的分享。总的来说，就是需求方知道自己要干嘛，但是他们不知道自己要什么。还是拿我自己在工作中的经历来说，有一次需求方跑来跟我说他要一个白名单功能，这个时候他要的就是一个字面上理解的白名单功能，但是在后续的沟通中，他渐渐说明白了他的最终目的是能够更灵活的监控某些用户，对某些用户或者选择相信而无需审核，或者重点审核。所以总结起来，他是要一个对用户打标签的标签管理系统，用过标签的不同，既可以支持白名单功能，也可以支持灰名单功能，还可以支持黑名单功能，当然后续还可以支持其他的特殊要求。 需求方说能不能在后台的这个页面上显示更多的用户信息，能够通过用户信息来辅助内容的审核，沟通之后就会发现，其实他要的是一个CRM系统。 通过更多的沟通和分析，可以将需求方提出的各种看似割接的需求通过系统化的方式去解决，通过实现单个功能背后的系统化目标来做方案，也是能大大提高产品的持续适应性和拓展性。 当然这个时候还需要考虑公司内部的技术资源的支持能力。不过总归大方向确定了，再规划单个方案，行动起来也会更有连贯性。

产品经理接到的需求通常不是真正意义上的“需求”，而是提出需求的人，基于某一个需求提出的“解决方案

今天在讨论直播新需求时，我突然发现之前的想法都过于关注解决方案本身，思维就容易陷入其中，只盯着问题，想要让更多订场用户了解智能服务，可是要加上创建直播功能就不符合我们最初要解决的问题。 静下心来去思考这个需求背后的逻辑，其实可以通过更多运营或是页面表现优先级上的区分来强调新功能，并且辐射更广。转念焕然开朗。 这些天也在同样进行用户和产品分析，解决方案可以无穷无尽，然而最为关键的还是问题以及对应的场景。

这就是腾讯提倡的每周拜访1000个用户，抖音提倡的“离用户近一点、再近一点”

产品经理接到的需求通常不是真正意义上的“需求”，而是提出需求的人，基于某一个需求提出的“解决方案

说下刚刚经历的一个事。后台系统，有个B功能是A的后续。A功能会展示一个页面，用户点击确认后进入B功能，B功能也是展示一份一样的信息的页面，上传一些附件后，再次确认。A和B有较大可能是一个人进行操作。A有可能被系统自动确认。这样的场景下，我觉得设计成一个功能2个操作是很自然的事。我们的PM设计成2个功能就算了，把B功能的上传附件嵌入A的列表页，却又不提供从A到B的直接跳转；B功能的上传也放在B的列表也，却需要点到B的详情页去确认！ 完全没用脑子在做交互的感觉。关键还是个级别不低的PM。我就吐槽一下，我怕憋不住打人！

问题，归根到底就是产品的真实需求，而不是使用者直接提供的解决方案，这就需要产品经理一步步刨根问底了。 想起刚工作时，老板给我们的一个要求就是没事多使用自己开发的产品。但多数同事对这种要求很排斥，理由是白天一天都在搞这个，下班了还搞，太无聊了。工作这么多年才明白老板的初衷，他可能希望员工深入产品，作为产品的直接使用者，发现产品中不合理的地方，也就是邱哥说的"共情"能力。 邱哥最后一段我也深有感触，很多领域的知识其实都是相通的，相互间都有可以借鉴的地方。

从二爷的文章可以看出二爷做的产品肯定是很具人情味的