C端或B端产品，产品经理如何管理 ？
一：B端产品经理和C端产品经理的主要差异？
个人认为B端和C端产品经理，从处理需求的方面，大致体现在以下几点：
1. 分析方式：数据VS理解
C端产品经理由于产品特性的原因无法与用户做大量的沟通，所以就会根据用户所产生的大量数据，来进行用户行为或用户心理等方面的数据分析，从而判断用户的真实需求，这里要提醒的产品设计之初就要想到这些功能，以免上线后没有数据；
B端产品经理则会天天面对大量的用户需求，所以需要结合其在企业中的角色、岗位等诸多因素，来还原这个需求所出现的时间、场景以及用户心理，从而判断用户的真实需求；
2. 思考角度：简单场景化VS复杂场景
C端产品的核心功能大多数是为了满足某类用户群体在某个特定场景下的痛点需求，场景相对单一，就是C端产品，对于用户要满足某一类群体；
B端产品的核心功能大多数是为了满足多种角色共同去完成一件事或一个流程，场景相对复杂，B端业务流程是满足需求的重点。
所以C端产品经理在看待功能需求的角度上，更多的是从单一用户群体去考虑它能否满足我的用户在这个场景下的需求，而B端产品经理则需要从多个不同的角色去考虑它能否满足每个角色的不同需求，同时B端产品中的各个功能模块有很多耦合，所以还要考虑到一处的变动所能影响到的其他地方。
3. 设计方法：具象VS抽象
C端产品的场景会相对单一些，因此产品经理在设计时更偏向于功能的场景化，或将更多的精力放在交互设计、用户体验优化等方面；
B端产品的使用场景和业务流程会相对复杂，因此产品经理在设计时除了考虑业务流程是否完备、严谨，同时还需要关注功能模块的抽象分类、交互逻辑的统一性、角色权限，以及对其他功能的影响等问题。
4. 处理节奏：快速验证VS流程严谨
C端产品经理尤其是在产品初期时，往往需要快速验证的市场对功能的认可度，因为一旦耗费大量的精力去做一个功能，对产品的风险极大；
B端产品经理在上线功能时，即使再快再简化，也要保证业务核心流程是否能跑通。
二. 如何判断自己更适合做哪个？
我们在招聘的时候曾尝试着用面试者的性格、心态等因素去判断是否合适，但这似乎并无法判断出来。所以我认为，与其在C端和B端产品经理中抉择，倒不如在众多行业中抉择，在一个行业扎根沉淀下来，这样无论是做C端还是B端，都会更得心应手。
三. 新人如何提升对业务逻辑的理解？怎样探寻支撑功能背后的逻辑？
作为新人，在遇见问题的时候，一定要多听取用户或者业务部门描述与需求，因为你做的是B端产品，可能并没有过多接触过他们的业务，所以要尽可能的弄清楚他们的各种问题，比如：角色是什么，在什么时间，在什么业务场景，为了解决什么问题，为什么要解决，也就是通常所说的5个W：who，when，where，what，why。与此同时也要多追问自己问题的本质是什么，因为一个需求往往需要剥离2-3层才能露出本质。
多看友商的产品是如何处理这个问题的，理清他们的思路是什么，同时多问自己，他们这么做的原因是什么，他们舍弃了什么，优点在哪，弊端在哪，毕竟看的是表象，只有自己才了解你的用户，你的产品，背后为什么这么做，是有自己商业逻辑的。
多思考这个需求在自己的产品中如何设计，能否解决用户的需求，会产生什么样的影响，不能为了满足这一个需求而影响了这个功能甚至整个产品。
总结来说就是多听，多看，多问，多思考，没有捷径可走，只有量变才能产生质变。
四. 如何识别伪需求？
在拿到需求进行过滤之前，首先你要清楚自己产品的边界在什么地方，以产品边界为前提，再去判断你就会发现，一些看似“很好”的需求就已经可以排除掉了。
什么是产品边界？西餐厅里卖猪肉炖粉条，港式餐厅里卖卤煮，协作平台中对工作任务的搜索支持语法命令……
但事实是，大多数的需求都是含糊不清的，并不是一眼就能看清楚是否在你的产品边界之内。这时候你就需要通过问、想等各种方式深入的探究和思考，把它们“虚伪的面具”层层剥离，甚至有些隐藏的比较深的，只有当你开始去做了、想了，才会发现其实这并不是个真正的需求。或者有些需求当你深入思考之后，其实会发现其实你的产品中已经具有了这个功能，只是用户并没发现或者使用到而已，这时候你可以把这个需求降解为一个用户体验的问题来处理。
那是不是所有的真需求，我们都要做呢？当然不是！你还要清楚自己的产品结构是什么样的，然后视情况而定。
你会遇见一些需求提的真的很好，也看到有一些竞品中有可以解决这个问题的方法，但作为产品经理的你千万不要轻易掉进“陷阱”，他们的方法未必适合你，参考竞品只能给你提供一个思路，但不能完全指导你去设计产品，你要找到适合自己产品的方法，如果为了做需求而做，最后很容导致整个模块变得千疮百孔。
当然，非通用性需求也是伪需求的特征之一，但如果当你不好做出判断时，建议先放一放，要尽可能的记得你的客户曾提到的需求，当你看见越来越多相同的问题时，就该重视起来了，所以要注意放下，要有工具记录归类，要不然就会丢弃或没有聚合。
PS：不要小看任何一个需求，一个视觉的问题或者一个交互的问题，其本质可能是因为功能的缺失。
五. 怎样确定需求的优先级？
作为B端产品判断需求优先级的维度有很多，例如通用性、需求类型（通常情况是功能需求＞交互需求＞视觉需求）、影响客户量级、和产品方向的重合度、对业务影响的重要程度、和产品结构的契合度、研发成本、竞品是否有……等等，最终优先级视情况而定。
例如：有些需求虽然不是那么重要，但是对一些重要的客户影响很大，可以安排临时插入到迭代或者安排到最近的迭代里。
有些需求很重要，但是可能会影响很多地方或者需要很多其他功能的辅助，就可先往后放放。
还有一些需求确实很好，但是对现有的研发团队来说，需要耗费很长的时间，优先级也会调低很多。
- 点赞
- 收藏
- 关注作者
评论（0）