真正坚强并且心态健康的人，被朋友出卖、被亲人误解、被爱人抛弃，也不会对人性失去信心。
-----罗永浩
产品经理日常最频繁的工作3个字：做需求，因此挑战产品经理基本功的是需求挖掘。最近在工作中碰到一个需求挖掘的场景分享给大家
产品经理的需求来源因工作职位的不同，需求来源方向也是小部分不同。不管是移动端产品经理还是后台产品经理，甚至是数据产品经理等，业务的需求是每个产品经理都要遵守的基本产品设计规则，没有业务的产品是无法解决用户需求，是无用的产品。
一个挖掘需求的对话
不知道你有没有下面类似场景
业务人员A：“我们即将要上线一项新的服务，能不能为我们这套服务提供商家和客户管理的工具？”
产品经理：“你们需要这个工具干什么呢？“
业务人员B：“我会将客户的反馈问题进行整理，统计。反馈给相应的商家，让商家知道客户反馈的问题有什么类型，给予商家最好的反馈”
产品经理：“你们需要收集的数据类型是什么？最终收集的数据还是需要人工处理吗？“
业务人员A：“收集的是用户图片、文字、语音消息，我们将有用的反馈挑出来集中给予商家，帮助商家得到最精确的反馈，最后用户可以得到更好的体验”
产品经理：“那既然这样你们是如何管理这些图片、文字等数据内容？”
业务人员B：“我们目前是用excel管理，我们希望可以在系统上管理”
产品经理：“你们开始服务了吗？有多少内容要收集每天”
业务人员A：“我们还没开始服务，但希望有这个系统“
产品经理：“.........."
产品经理：“或许你们可以用2个微信群解决这个问题，一个微信群是客户意见收集群，一个是商家意见推送群”
业务人员A、业务人员B：“好像是的”
上诉场景就是一个需求挖掘的过程
需求就这样被拆解，明确的知道最终业务人员其实是可以通过2个微信群来管理即可。而且考虑产品上线后的不稳定周期，至少微信群的效率也是非常高的。
需求之外的必备元素
通过上诉过程，产品人可以知晓业务人员需要是什么，我们应该提供什么样的产品设计方案可以满足业务人员需求。
需求到落地，还需要时间和资源2个因子。没有资源的需求是没办法落地的，没没有充足时间的需求也是无法落地。
需求在接到手里后，我们需要知道对方需要的业务需求时间，再来安排我们上线的时间点。
资源也是同理，例如上诉场景其实希望是做web端产品。那么对于客户端的资源抢占就没有。所需要的资源是设计、后台、前端资源。
上图复杂的设计稿是想突出如果这个需求需要大量的设计资源。那么其前端或设计人员的工作量与时间长度就会拉长。整体产品上线的时间就会越来越低
整体上线的时间有时候业务人员也没有给出。在产品从0到1的时候，并没有运营需求或活动需求，整体时间的规划也没有。为此我们此时加班的情况是较少的，毕竟没有必要反复的产品上线。
好啦，今天的分享就在这里，我会坚持每周分享2篇
另外我个人第一本书籍《从零到壹：PM改变世界的点滴》电子档正式上线这本我归纳222篇产品原创，涵盖产品经理面试、算法、交互等不同维度的内容，如果你感兴趣可以打赏后留言你的邮箱。我会在每天中午12点左右发送到你邮件中（希望大家勿外传支持，支持版权）。如果你需要预览书籍大纲，可以跳转链接
