需求挖掘及业务梳理能力

很多产品经理入行一段时间后，感觉自己没什么话语权，就是一个产品功能设计师；要啥产品功能，要听业务方的，产品功能做成啥样，要听开发人员的。自己两边受夹板气，没有一点儿成就感，更看不到未来，就有点怀疑人生了，难道这就是产品经理的工作？

如果自己是乙方，给公司外部的甲方做产品，再遇到强势的甲方，感觉自己更难了。被甲方的需求牵着鼻子走，每天小心翼翼地设计、修改产品功能，最后还不一定换来甲方的满意。

虽然说“客户是上帝”、“客户虐我千百遍，我待客户如初恋”，但是，宝宝心里苦，宝宝难受啊！好歹自己也挂着一个经理的头衔呢，自己每天小心翼翼的“侍候主子”，简直就是对经理头衔的侮辱，啥时候能真正享受一把当经理的感觉呢？目前这工作没有一丁点儿成就感。

先安慰一下，宝宝们别伤心，别难过，当你意识到当产品“功能”经理的苦，想寻求突破时，问题就解决一半儿了。就怕意识不到问题，认为产品经理就是转达一下需求、画画原型、写写产品方案、跟进一下开发，这就坏菜了。

那么，剩下的一半儿，该如何解决呢？我把自己的三点经验分享给大家，但愿它成为你职场迷茫的灯塔，指引你披荆斩浪、奋力前行。

一 、产品技能提升

产品技能是任何阶段产品经理的核心技能之一，但是每个阶段的水平不一样，所以在往高阶产品经理晋级的路上，初、中阶段产品经理仍需要学习产品技能。

1. 需求挖掘及业务梳理能力

有些产品经理苦于自己一天天做产品功能设计，其实是“只见树木不见森林”的看法，仅关注到了产品的点，没关注产品的面，更没从业务全局角度去看待产品。

尤其是B端产品，支持的业务复杂，产品逻辑多，产品经理更要在日常工作中，有意识的去注意需求挖掘与业务梳理能力的提高。

若开始没有规划新产品的机会，可以多留意现在的产品逻辑，通过产品逻辑倒逼自己去理解业务逻辑，倒逼自己去理解产品是如何解决业务问题的。当业务逻辑理解多了，自己就能独立从纷杂的业务中，逐渐抽象出业务逻辑了，进而就能依据业务逻辑和要解决的业务问题，来设计产品逻辑。

我曾规划过一款机票竞价系统，开始的需求是财务部同事发邮件提出的。需求描述很简单，就是想把采购人员QQ人工单线询价及Excel记录的订单搬到线上，以避免数据链条不完整、人为的偏向某供应商搞徇私舞弊。同时，也想规避Excel漏单的风险。

我想一款B端产品需求不会这么简单，估计核心问题没有全部暴露出来。

首先，考虑这款产品的需求方全不全？其次，考虑每个需求方关心啥？要解决什么问题？业务现状是啥？期望是啥？再次，这个系统都需要和哪些系统对接？这些我还没搞清，仅接到财务部的一个邮件，不敢贸然行动，别说看到冰山一角了，可能连冰山的影子都没看到。

这里要说一下，对于B端产品，一般会涉及到企业高层、中层和基层操作人员，这三层需求方。像这款机票竞价系统，还要涉及财务、机票运营这两个部门的基层需求方，还涉及公司外部的机票供应商。如此看来，还有大部分需求方的需求都没了解，当然不能贸然行动了。

我做这款产品的公司不大，便先去找CEO了解需求，听听他的想法。经了解，他的需求是自动竞价与票量平衡，并期望激发供应商自动降价的意愿。看见没？CEO关心的是采购成本和采购风险，避免一家独大，而不是期望与某家供应商结成战略联盟，让其成为大供应商。尤其是系统自动选择中标供应商、票量平衡，这两个核心需求及背后的原因，财务部是提不出来的。

接下来，我又去找机票运营部门了解了需求，他们主要是减轻工作量，提升工作效率相关的需求，在这里不展开说具体内容了。看见没？都是屁股决定脑袋，机票运营部门既不关心CEO关心的那套，也不关心财务部门关心的那些。

除此之外，我又详细调研了未来和机票竞价系统对接的上下游系统、及相关的需求方。同时，我与对外部供应商代表进行了沟通过，听了他们的想法和建议。最后，经汇总各方需求及问题，结合自己对机票竞价系统未来的构想，才把业务需求转化成产品需求，梳理出产品的关键逻辑。

这里举两个有代表性的例子。

一是梳理了机票竞价策略，这是既能保证充分竞价，又能做到票量平衡（避免一家供应商独大）的核心。

二是详细梳理了出票后旅客改期、升舱的改单流程与逻辑，从而规范机票退改流程，避免依赖机票运营部门的Excel表格记录订单产生的乱结算现象。

其实，需求的挖掘与业务梳理，也是产品经理的基本功，只是需要持续的修炼。初、中阶产品经理在需求调研时，容易犯调研片面，需求挖掘不深等问题。

上述通过一个例子，给各位成长路上的产品经理，进行说明在需求调研时，调研范围一定要全面，B端产品需要涉及高中低三层人员。同时，还说明，要抓住需求背后要解决的核心问题，以核心问题为抓手，梳理业务逻辑。

2. 产品业务架构能力

无论是C端产品的后台，还是纯B端的产品，都非常注重产品的架构。是不是有些初、中阶产品经理，没有规划从0到1产品的自信？是不是大家遇到过产品改不动的情况？这类都属于产品架构能力的问题。技术同学负责产品的技术架构选型，产品的业务架构、功能逻辑是产品经理负责的。

第一版产品一般产品功能不多，但是非常注重业务架构的构建。这就好比盖房子，毛坯房算是第一版，居住功能不强，但是若毛坯房的结构不好，后续再怎么精装修也难以改变房子的大布局。所以，第一版产品对产品业务架构能力要求比较高。

现实工作中，初、中阶产品经理经验不丰富，再加上从头做产品的机会本来就少，所以多数时候初、中阶产品经理负责产品功能的优化，或产品版本的迭代。建议大家在负责产品的日常功能完善时，多留心产品的业务架构、功能结构。

这样边学边用，一是不至于现有产品跑偏，二是哪天有机会做新产品时，就不会胆怯，三是当你看着自己规划的新产品落地时，成就感会大增，就感觉自己有点产品经理的意思了，不再仅仅是产品功能经理了。

CRM（Customer  Relationship  Management  客户关系管理）的业务架构相对简单。

我以曾做过的一款CRM为例，谈一下产品功能架构的规划方法。我认为产品业务架构规划应该考虑“流程、功能、数据、扩展性”这四个方面。

我规划的CRM是一款支持销售落单的产品，从主流程上分为线索、商机两个阶段。每次获得用户的购买需求，称为一个线索。经和用户沟通后，有进一步沟通意愿的线索，转化成商机。

在分成如下图的两个阶段后，就把每个阶段的流程逻辑整理出来。比如一个用户可以多次留线索，一个靠谱的线索只能转换成一个商机，针对一个商机可以给用户提供多套购买方案等等。

这个主流程逻辑看似简单，其实非常关键，它决定了你的产品是否符合销售跟单的大逻辑，决定了后续往上堆功能是否顺溜。这就好比房子，承重墙位置、结构设计的合理，在后续装修时，就能支持更灵活的隔断设计。

主流程逻辑确定以后，要对其细化，细化到每个可以落地使用的流程。比如上述主流程中，有些线索不能转化成商机，就需要在线索阶段结束掉，无需再往商机阶段流转。在比如商机成单后，要把成单数据传给财务及其他业务系统，在什么节点，满足什么条件时才传递，这些流程都要细化清楚。

各种流程理清后，需要整理每个流程每个阶段的功能与数据，都需要提供什么功能，需要什么数据，每种数据间的逻辑关系，这些都要整理清楚。整理这些有两个目的，一是验证流程逻辑的合理性，二是逐步把功能推向落地。

比如线索需要从线上活动对接过来，需要支持Excel导入、需要支持手工输入等等，这些数据都需要什么字段、都需要什么格式、不同途径来的线索后续流程是否一样等等。这就要提供线索获取功能，并且需要支持不同的获取方式；并且需要考虑需要获取线索的哪些数据。

再比如在商机阶段，每个方案需要获取方案报价信息，成单后需要获取后续服务信息。那么，就需要针对每个商机的方案做接口的数据对接。这些与外部系统的数据对接，在产品业务架构规划时，也需要考虑清楚。

再说扩展性，产品改着改着改不动了，主要因为产品业务架构扩展性无法满足企业业务变化的需要。所以，在产品初始规划时，需要充分论证、考虑后续业务变化的可能性及业务场景。同时，在日常产品功能优化或增加时，也要考虑为未来业务场景的变化，提供必要的功能预留或功能扩展的支持。

其实，这点儿不难理解，就好比城市规划建设，今天的城市规划与建设，需要考虑后续一二十年甚至更长的经济、人口等情况的发展。否则，就会引起劳民伤财的大拆大建。

3. 项目管理能力

很多公司由产品经理承担项目管理工作，所以对初、中阶产品经理，持续提升项目管理能力也是非常有必要的。

产品经理关注“做正确的事儿”，项目经理关注“正确地做事儿”，这是两种不同的工作方式。所以，产品经理需要有意识的提高项目管理能力。

要从“目标、资源、进度、风险”等几个方面均衡考虑，当遇到情况时，需要从这几个动态方面寻找最优解。如果从项目经理专业术语的角度来讲，在范围一定前提下，需要寻找“质量、成本、时间”三角的动态平衡。

这里提醒两点，一是对于项目延期的风险，早暴露，早周知，早想办法，避免最后自己背锅；二是遇到困难后多想法利用资源，别自己扛，你的上级、技术、运营等等都是你的资源，想办法把资源利用起来，能利用多大的资源就能做多大的事儿。

二、商业思维与行业认知

产品经理由低阶往高阶走，除需求挖掘、业务梳理、产品业务架构等“硬技能”的提升外，更应该注重商业思维、行业理解这些“软技能”的提升。硬技能决定了，你能不能把手头的活儿做好，软技能决定了你能走多远。一个是让你低头把活儿干好，一个是让你抬头看路，指引方向。