产品业务方向是什么业务产品是什么意思

作为提需求的业务方，如果对产品理解更深，则会和产品经理配合的更好，借力产品实现目标。

这是一篇产品经理自我审视、自我施压向着更高要求出发的文章。

如果是优秀且有责任的产品经理，他们会主动贴近业务，了解业务价值、目标和策略，在此基础挖掘需求，帮助业务提效增长。但实际情况下，并不是所有的产品经理都有这样的意识，或者有意识但能力不够。

作为提需求的业务方，如果对产品理解更深，则会和产品经理配合的更好，借力产品实现目标。一方面在业务过程中遇到困难时会思考是否可以产品化解决。一方面是面对“不靠谱”产品经理提供的不客观的评估方案时，可以有一个衡量的尺度。本篇就业务视角去看，如何才能更好的理解产品。

一、什么样的问题适合用产品来解决？

互联网产品或系统，核心价值就是利用计算机的计算能力以及互联网的连接能力来解决业务过程的低效问题。细盘下来，遇到如下3类情况是，可以考虑产品化来解决：

1. 重复劳动

重复劳动背后一定是固定的不变的流程，且被反复执行，这是最适合产品化来解决的。

最简单的例子就是工业生产线，生产可口可乐都是同样的步骤不停重复，机器代替人工可以提升准确性的同时可以大幅度提升效率。

又比如另外的例子是：每天早晨要看业务指标完成情况，每天都要导出相同的源数据、通过excel做透视图、生成曲线图。这种也可以数据看板产品来解决这一重复工作。

2. 空间障碍

互联网可以解决那些不依赖空间，但又因空间限制导致低效的事情。

比如视频通话功能在春节拜年没法一一拜访好友时，可以解决三五好友通过视频群聊聚一起寒暄唠嗑。

又比如合同签约，原来需要书面签好寄给对方，受制于快递文件的物理空间限制，收发合同效率低。电子合同在线签约产品的出现，就可以让合同传递瞬间完成，省时省力。

3. 精确度

用人做的事情具有创造性，但精确性并不能完全保障，而且因人而异。财务系统的出现就可以在精准精确上完全替代人用计算器加减乘除的工作。

4. 高频刚需

互联网及计算机另一个核心价值就是通过规模效应降低边际成本。当一个系统、一个功能有很多人用，且很高频的用时，产品系统就会有较高的投入产出价值。

滴滴打车、美团外卖之所以快爆发、高估值的背后就是打进了高频和刚需。但如果是1个月只有你1个人要做1-2次供应商的成长分析，就没多大必要做数据看板产品。这种不高频受众小的需求在资源部是特别充裕时还是通过导出数据，单次单独分析来的划算。

当业务上遇到瓶颈困难时，或发现有重复工作的倾向时，可以看看是否符合上述4点条件，如果有1条满足的话，就可以考虑产品化。拉上产品经理一起，阐述清楚目的和价值。绝大部分情况下，产品经理都会针对设计合理的产品方案并且推动上线。

二、如何判断需求实现的可行性？

前面提到绝大部分的产品经理都会帮助业务解决问题，但不可避免遇到能力不强的产品经理，他们有时候给出的评估可能并不客观的。

这种情况下，作为业务自己为了拿结果，可以自己对评估的结果进行合理性判断，但需要加强对产品系统的理解。

下面会花较大篇幅重点介绍产品系统，希望让完全没接触过产品的人看完后也能对产品运行有个概要的理解。

计算机的系统运作是明确、理性有逻辑的，。也就是说在产品中，都是可以用逻辑关系解释清楚的，不存在说不清楚关系的功能，就连随机函数在计算机的运行内核里也是明确的.逻辑关系主要有如下几种：

流程步骤型：先如何 → 再如何 → 然后如何，一步一步的。跟玩密室逃脱的道理一样，你必须开一个门，才能进入另外一个门，再进入另一个门，最后打开通关。场景型：当场景=A时发生什么；=B时如何；=其他时如何。比如VIP会员9折，高级会员9.5折，其余原价。是否型：一个条件满足了是怎样，不满足是怎样。比如淘气值是否1000以上，是的话买88VIP要88元/年；不满足则是888元/年；

产品的系统绝大情况就是以上3种逻辑的排列组合。举个例子，比如创建商品时，鞋服类的需要额外上传尺码对应表，并且鞋、上装、下装要传不同的尺码表：

如上简要流程（实际要复杂的多，作为业务理解到这个环节基本够用）就包含涵盖了流程步骤、是否条件、不同情况的处理等。需要强调的是，逻辑梳理过程中，需要遵循结构化思维的MECE原理（相互独立、完全穷尽），比如在给“人”做分类时，可以通过“男、女”区分，也可以通过“年龄段”区分，但不要用“老奶奶、年轻人（这样是不穷尽的，还应该有老爷爷、年轻男人、年轻女人）”这样来分。这样可以保证划分的维度是清晰的，并且能够穷举所有的场景。

在上述的案例里，尺码表虽然穷举了一些CASE，但是不穷尽，还可以增加CASE4：帽类、皮带类等（这里大家可以思考，在做尺码表时如何划分才会保证没有遗漏？）

作为业务，需要自己判断可行性的时候，可以尝试着把自己的需求按照上述3种系统逻辑尝试绘制流程图，再看看每个环节是否通顺。如此经历多个项目后，再和产品经理沟通方案，会发现对系统逻辑的理解会越来越透，也越来越有感觉，新的需求要提时也大体知道能否实现了。

PS：刚才案例的CASE4，可以按照成人、儿童进行一级划分，然后第二级可以按照上半身、下半身划分。这样可以涵盖所有的鞋衣帽手套袜子皮带这些穿搭品。

三、什么样的需求实现成本高？

高实现成本一般会有几种场景：

1. 目前不具备实现需求的前提条件，得先实现那个前提条件

比如：需要用户能在电商APP里看到每个品牌活动信息时，业务和产品经理有如下对话：

产品：这个需求暂时没法实现，品牌得拆出来单独管理才行

业务：啥意思，不是有品牌吗？我建商品的时候，页面上有让我写品牌的

产品：那个品牌是你输入的，不能拿它做管理的

业务：为啥？

产品：…..

这样就很难聊了，我们还是详细解释下（这里需要耐心看个5分钟），下图：

这是创建商品时，填写品牌的页面，左边和右边是2个方案。左边采用输入打字的方式录入品牌，比如“阿迪达斯”这个品牌，我们可以写“阿迪达斯”，也能写“Adidas”，都是代表阿迪达斯，看似没啥问题。但如果需要对每个品牌维护背后的供应商时，系统只能把“Adidas”、“阿迪达斯”和 “供应商A”和都建立关系，如下图：

显然，这样的方式是不科学的，有明显的漏洞——

当有其他运营新建“阿迪达斯”的商品时，他极有可能写了一个“阿迪”，导致的结果是这个“阿迪”无法自动和“供应商A”形成关联，后续希望看“阿迪达斯”这个品牌的数据时也是痛苦万分。

但是，如果这个时候有一个现成的【品牌库】，情况就完全不一样了——

商品创建时，如最上面右图的方案，可以直接选择“阿迪达斯”这个品牌，这样未来统计阿迪达斯真正的销量，就非常简单清晰。因为只有一个“阿迪达斯”，系统天然的控制了不会出现“阿迪”和“Adidas”。而且当系统只有一个唯一的“阿迪达斯”时，我们可以很方便的在后面直接维护供应商A，甚至是实现需求里要求的营销活动。在系统里，2中方式的信息存储结构如下图：

商品信息存储时，原来商品里的品牌信息是以文本“阿迪”存储的，而后者是以一个数字存储的，这个数字可以和品牌库里的“阿迪达斯”完成一一对应。在产品系统里，一个内容是否支持额外拓展，就看目前的实现方式是否是以唯一的ID进行存储的。这个映射到生活中可以用姓名及身份证号来理解，姓名是可以重名的，而身份证号是唯一的。如果一个叫“李三”的人犯事了，不会按“李三”这个名字来确定身份，而是用身份证号来唯一确定。

刚刚有点跑偏，实际上在实现成本里，很多需求是需要有前提条件的。在APP里要看到每个品牌的活动信息，能实现的前提需要有一个【品牌库】，并且在【品牌库】里的品牌后维护了活动信息，如果没有的话，产品经理就会告诉你实现成本比较高。

同样再举一个特斯拉老板Elon Musk要在火星上居住的例子。这个需求也是实现成本高，但不是不能实现。成本高的原因是没法一步到位，需要第一步把人送上天，第二步火星上氧气不足无法燃油驱动，得有电驱交通，第三步是有人类方便获取的再生能源。所以他做了SpaceX火箭、电驱车特斯拉、太阳能源公司SolarCity。

2. 因为投产比考虑的实现成本

有些需求其实不复杂，但是需求价值小、频率又不高，这种情况下产品经理可能会认为实现成本高。

举个例子，某刚起步电商平台，业务谈了一个客户，这个客户自己也有商城，他希望双方双方接口互通，实现货源共享销售。这个需求如果要实现的话，其实把已有的订单信息、商品信息、物流信息、资金账户等重新包装成对外的开放的接口，虽然会涉及到较多的系统模块，但是工作量并不是特别大。但如果这样的对接需求只是个例，且这个客户并不稳定，产出贡献也不大时，产品经理会认为投产比的风险是大的，内心倾向于拒绝这个需求。

另外，一个需求也不会因为实现成本大就一定不做，投入产出比合理就可以考虑。比如一个电商平台基本的买卖关系都已经实现了，接下来要发力营销活动时，虽然一个营销系统的搭建虽然成本高，但是也会考虑去投入持续建设的。