KOL专访：B端产品经理的成长与思考

Q1. B端产品经理和C端产品经理的主要差异？

** 答:** 关于B端产品和C端的产品各自的概念，很多地方都可以查到，在这里不做过多阐述。
个人认为B端和C端产品经理，从处理需求的方面，大致体现在以下几点：

1. 分析方式：数据VS理解
C端产品经理由于产品特性的原因无法与用户做大量的沟通，所以就会根据用户所产生的大量数据，来进行用户行为或用户心理等方面的数据分析，从而判断用户的真实需求；

B端产品经理则会天天面对大量的用户需求，所以需要结合其在企业中的角色、岗位等诸多因素，来还原这个需求所出现的时间、场景以及用户心理，从而判断用户的真实需求；

2. 思考角度：简单场景化VS复杂场景
C端产品的核心功能大多数是为了满足某类用户群体在某个特定场景下的痛点需求，场景相对单一；

B端产品的核心功能大多数是为了满足多种角色共同去完成一件事或一个流程，场景相对复杂。

所以C端产品经理在看待功能需求的角度上，更多的是从单一用户群体去考虑它能否满足我的用户在这个场景下的需求，而B端产品经理则需要从多个不同的角色去考虑它能否满足每个角色的不同需求，同时B端产品中的各个功能模块有很多耦合，所以还要考虑到一处的变动所能影响到的其他地方。

3. 设计方法：具象VS抽象
C端产品的场景会相对单一些，因此产品经理在设计时更偏向于功能的场景化，或将更多的精力放在交互设计、用户体验优化等方面；

B端产品的使用场景和业务流程会相对复杂，因此产品经理在设计时除了考虑业务流程是否完备、严谨，同时还需要关注功能模块的抽象分类、交互逻辑的统一性、角色权限，以及对其他功能的影响等问题。

4. 处理节奏：快速验证VS流程严谨
C端产品经理尤其是在产品初期时，往往需要快速验证的市场对功能的认可度，因为一旦耗费大量的精力去做一个功能，对产品的风险极大；
B端产品经理在上线功能时，即使再快再简化，也要保证业务核心流程是否能跑通。

Q2. 如何判断自己更适合做哪个？

答： 我们在招聘的时候曾尝试着用面试者的性格、心态等因素去判断是否合适，但这似乎并无法判断出来。所以我认为，与其在C端和B端产品经理中抉择，倒不如在众多行业中抉择，在一个行业扎根沉淀下来，这样无论是做C端还是B端，都会更得心应手。

Q3. 新人如何提升对业务逻辑的理解？怎样探寻支撑功能背后的逻辑？

答： 作为新人，在遇见问题的时候，一定要多听取用户或者业务部门描述与需求，因为你做的是B端产品，可能并没有过多接触过他们的业务，所以要尽可能的弄清楚他们的各种问题，比如：角色是什么，在什么时间，在什么业务场景，为了解决什么问题，为什么要解决，也就是通常所说的5个W：who，when，where，what，why。与此同时也要多追问自己问题的本质是什么，因为一个需求往往需要剥离2-3层才能露出本质。

多看友商的产品是如何处理这个问题的，理清他们的思路是什么，同时多问自己，他们这么做的原因是什么，他们舍弃了什么，优点在哪，弊端在哪。

多思考这个需求在自己的产品中如何设计，能否解决用户的需求，会产生什么样的影响，不能为了满足这一个需求而影响了这个功能甚至整个产品。

总结来说就是多听，多看，多问，多思考，没有捷径可走，只有量变才能产生质变。

Q4. 如何识别伪需求？

答： 在拿到需求进行过滤之前，首先你要清楚自己产品的边界在什么地方，以产品边界为前提，再去判断你就会发现，一些看似“很好”的需求就已经可以排除掉了。

什么是产品边界？西餐厅里卖猪肉炖粉条，港式餐厅里卖卤煮，协作平台中对工作任务的搜索支持语法命令……

但事实是，大多数的需求都是含糊不清的，并不是一眼就能看清楚是否在你的产品边界之内。这时候你就需要通过问、想等各种方式深入的探究和思考，把它们“虚伪的面具”层层剥离，甚至有些隐藏的比较深的，只有当你开始去做了、想了，才会发现其实这并不是个真正的需求。或者有些需求当你深入思考之后，其实会发现其实你的产品中已经具有了这个功能，只是用户并没发现或者使用到而已，这时候你可以把这个需求降解为一个用户体验的问题来处理。

那是不是所有的真需求，我们都要做呢？当然不是！你还要清楚自己的产品结构是什么样的，然后视情况而定。

你会遇见一些需求提的真的很好，也看到有一些竞品中有可以解决这个问题的方法，但作为产品经理的你千万不要轻易掉进“陷阱”，他们的方法未必适合你，参考竞品只能给你提供一个思路，但不能完全指导你去设计产品，你要找到适合自己产品的方法，如果为了做需求而做，最后很容导致整个模块变得千疮百孔。

当然，非通用性需求也是伪需求的特征之一，但如果当你不好做出判断时，建议先放一放，要尽可能的记得你的客户曾提到的需求，当你看见越来越多相同的问题时，就该重视起来了。

PS：不要小看任何一个需求，一个视觉的问题或者一个交互的问题，其本质可能是因为功能的缺失。

Q5. 怎样确定需求的优先级？

答： 作为B端产品判断需求优先级的维度有很多，例如通用性、需求类型（通常情况是功能需求＞交互需求＞视觉需求）、影响客户量级、和产品方向的重合度、对业务影响的重要程度、和产品结构的契合度、研发成本、竞品是否有……等等，最终优先级视情况而定。

例如：有些需求虽然不是那么重要，但是对一些重要的客户影响很大，可以安排临时插入到迭代或者安排到最近的迭代里。
有些需求很重要，但是可能会影响很多地方或者需要很多其他功能的辅助，就可先往后放放。

还有一些需求确实很好，但是对现有的研发团队来说，需要耗费很长的时间，优先级也会调低很多。

Q6. Worktile7.0改版增加项目模块是出于哪些考虑？

答：在7.0之前，Worktile一直是采用轻量级的看板管理的方式，为客户解决项目管理的需求。但随着越来越多中大型规模的企业选择了Worktile，看板式轻量级的任务管理在承载用户的业务场景时，显得有些力不从心，所以团队决心从零开始重新打造一款更加强大更能适应用户业务场景的项目管理模块。但是，标准化产品和客户个性化需求之间的矛盾一直是困扰各个企业SaaS服务厂商最大的问题，一方面要做SaaS化标准产品，另一方面在面对每个不同的客户时，又有些个性化的需求又需要满足，所以很多的SaaS厂商都陷在这个泥潭中无法自拔。

要满足客户的业务场景化，我们有两种不同的解决思路：
第一个思路是场景定制化，或者说场景垂直化，即客户需要哪个业务场景，我们团队去对应开发这个场景的项目模板。这种方式虽然可以满足需求，但是对客户的需求响应速度上不会很快，首先我们需要深入了解这个业务场景，才能够去做定制化开发。另外即便是同一个业务场景， 针对不同的客户在实际操作中也不尽相同，比如以敏捷开发为例，不同的团队在具体执行上也是千差万别，场景定制化开发在满足客户的个性化方面显然力不从心。

第二个解决思路就是积木化，即通过提供大量的底层元部件，把这些元部件根据客户的业务场景，组装成不同的项目模板，通过配置化的方式实现场景化。这些元部件可以看做是一个个的积木形状，最后组装成什么样子，取决于你需要什么。在Worktile 7.0中，我们提供大量了用于组装项目模板的元部件，包括：任务类型、状态、工作流、关联、数据源、组件、角色、事件、模式等等，客户并不会关心这些元部件是什么，有什么用，客户关心的是能用这些部件构造出他想要的业务场景，这就要求元部件要做的极具抽象，只有这样才有可能用最少的功能，最大化的满足客户的需求。
下图，就是运用这些元部件构造一个敏捷开发的场景模板的示意：

举个易懂的例子：
客户需要的是一个能代步的交通工具，首先我们提供了一些成品供客户选择。其次当这些成品无法满足客户的需要时，可以使用我们提供的不同样式的轮胎、动力源、刹车、方向系统、安全系统等等的部件，组装成一个自己想要的交通工具，同时我们的客户成功团队，也会根据客户的需求替用户组装好后并送货上门。

Q7. 目前使用频次最高的功能是什么？背后的原因是什么？

答： 项目模块。虽然上面说的看起来极其复杂，配置一个项目模板也不是个容易的事。但是，在实际过程中，却为客户提供了极大的方便，使用起来相较原来的轻量级看板管理反而更加简单。

例如：原来Worktile的任务中仅有一个未开始和已完成的状态，而中间所历经的各种业务节点都无法表现，客户只能在线下不停的沟通或仅靠约定俗成，这对企业来说本身就是大量的成本，而现在通过Worktile的项目管理就可以实现线上一键完成。

Q8. 相比其他企业协作平台，Worktile有哪些优势？

答： 首先，Worktile以项目管理为核心，通过8种应用从四种管理维度解决企业的项目管理、人事管理、行政管理、知识管理需求。

其次，Worktile将“协作”贯穿整个产品，打破不同业务部门之间的信息壁垒，从而大大提高企业的办公效率。

最后，在项目管理上大多企业协作平台都是平台提供什么功能，客户使用什么功能，而Worktile的项目管理在具有强大功能的同时，还有高度灵活的可配置性，从而让客户无需等待产品迭代，就可以通过自定义配置来实现项目管理中出现的绝大多数需求。

除此之外，我们还有极为强大、专业的客户成功团队和销售团队为客户进行服务，这也是产品优势中重要的一项。

Worktile,让办公更简单
原文链接：「PMcaff KOL问答专访-张尧」