什么是产品？或许有些人对于这个司空见惯的概念，并没有一个很清晰的答案，或者不知道如何去回答。我们常常会去了解其中的深层逻辑，却忘了记住产品的基础与底层逻辑。作者分享了他关于产品底层逻辑的理解，希望对你有所启发。

各位，产品到底是什么？

饭店服务员的微笑属于产品吗？你健身房的冷气算不算产品呢？

是不是有点惊讶，我们对于这么一个司空见惯的概念，第一反应却是没有一个非常清晰的答案，或者都不知道怎么去回答；大脑为了“高效”往往会封装好一个个概念，方便我们去记忆，但这也让我们丧失了探索一个熟悉概念背后底层逻辑的机会；我们先看下三个常见的产品定义观点：

观点一：产品是有形的实体，企业咨询或者饭店服务员的微笑等都不算产品，是服务；

观点二：产品是指被人们使用和消费，并能满足人们某种需求的任何东西（来源百度百科）；

观点三：产品是企业与用户之间交换价值的载体。

这三个观点在其视角可能都对，但是这三个观点都不便于我们更好的理解产品的底层逻辑，也不能成为我们的产品设计策略总纲；

下面同大家分享下我对产品底层逻辑的理解，先抛出产品的定义：

“人人都可以是产品经理”，做产品的都知道这句话，其实这本质上说的是，任何一个人都有解决问题的能力，只是解决的问题或大或小，提出的解决方案或体系或片面而已，这也反向说明了产品的本质就是：针对对问题，提出解决方案；

这个定义面有两个关键词【问题】+【解决方案】，下面我们重点看下这两个关键内容。

一、是问题不是需求，需求和问题不同

需求是怎么诞生的？

当我们想从A状态受促进转化因子影响转换到B状态时，就会产生一个新需求，如下所示：

在促进需求变化的因素（后续文章会详细说）触发时，我们就会想着从A状态到B状态，但是从A到B是有客观上存在的阻碍（注意是客观上的存在，不是主观上的），这些阻碍就是问题，而不同的人面对不同的问题就会产生不同的需求（比如下面举例，古代需要马，现代就是汽车）；

举一个经典例子，辅助大家理解下：

作为一个打工仔，我现在每天步行上班（A状态），但消耗时间太长了，而且还腿疼(问题)，那么我如果骑马上班的话（B状态），这些问题都不存在了，所以我想要一个快马；促进需求诞生的条件是：效率；问题是我上班太慢了，最终的诉求是快马，当然生活在当代的我就是汽车。

这也回答了另外一个问题，需求和问题的具体转化逻辑：问题+场景+人群 =>需求，由于场景和人群不同，相同的问题也会产生不同的需求；

1．需求是建立在问题的基础上，是由问题演变而来

问题可以在促进因子下转变为多个需求，可以通过这个办法建立行业需求图谱，能把行业需求都规划出来，做到提前洞察。

2．对产品经理来说，需求并不全面

需求好比半命题作文，用户已经填补了一半，给设计者留了另外一半；需求的通用表达式就是：用户想要什么；并不包含用户为什么想要这个，用户已经限定了范围，如果产品设计者不能够深入思考，能发挥的范围就不怎么多了，这样设计出的产品就会存在很大的问题；

3．问题较为客观，需求是主观的

问题是描述的一个客观存在的现象，但需求都是人在结合自己的实际感受加工出来的，人会在特定情况下会说谎或者表达模糊错乱，那么所谓的需求就是虚假的，就是大家常说的伪需求；这个也解释了乔布斯福特等大佬们秉持的观点：用户说的不可全信，也不可不信；

4．问题相对稳定，但需求容易变化

由于需求的主观特点，会因为场景和人群的变化而变化，不会特别稳定，所以我们在讨论需要时须时刻关注时间因素的影响；但是问题相对比较稳定长久；

二、是解决方案，不只是满足诉求的形式

什么是解决方案？解决方案就是所有解决问题的策略的体系性汇总；怎么理解这段话呢，我举例说明下：

我惹我女朋友生气了，我的需求是想要哄她开心，那我的产品是什么？这个问题就比较好的解释了产品的定义为啥落脚在解决方案上；

针对这个于是我产生了以下的想法；

1. 梳理解决问题的关键逻辑：不能讲理，态度要诚恳且积极且温暖且可爱，如果能有额外惊喜会更好，还要给他信心以后不再犯错；
2. 情绪策略：满脸笑容，表达温和，动作轻柔；
3. 言语策略：采用浪漫的语句，将过去我的好，换着法的各种夸奖她；
4. 送礼策略：准备一个平常她舍不得买的口红；
5. 保障策略：哭泣着写保证书，签字画押，保障以后不再犯错；

以上5点都是我为了解决女朋友生气了这个问题而产生的策略，所有的策略就构成了“哄杨胖子女友”产品，如果线上化的话，就是一款红女友开心的APP，这也就是大家可能比较容易接受的“产品”概念了；

友情提示：上述是说的是我惹我女朋友生气了，如果是你惹你们的女朋友生气了，场景和人群发生了变化，需求也会随着发生变化，那么可能策略可能就要变；假设她是包治百病，你就节省下万千言语和笑脸，带个包回去就行；假设她是热水万能型，倒杯55摄氏度的农夫山泉即可……

通过上面的定义，我们会发现解决方案有两层：

解决方案= 逻辑层+ 实现方式层

1. 问题的实现方式层就是与用户具体接触或者用户实际所得部分

这部分也是大家尝尝容易理解的，比如上面的举例中，我提供的口红，写的保证书这些都是实现方式层，我同样也可以换其他的实现方式，比如倒热水、买包包；

甚至开头提到的观点一就是把实现方式定义成了产品；而往往比较初级的产品设计者更是疯狂的局限在这层中，这也就是为啥高阶产品苦练了很哇塞的axure能力，但绝不会出现在他的简历中一样的道理；

2. 问题的解决逻辑层则比实现方式层更加底层，是解决问题的基础

不可见，同产品战略策略规划等比较类似的东西。

我哄女朋友开心，选择买口红还是写保证书，这些都承载体，而逻辑则是用真诚的态度去化解她心里的不快，用额外的惊喜来弥补她心中的不足，最后通过承诺来避免她担心未来再犯；所以逻辑层是产品设计的核心，这同样也是老板和产品设计助理的对待产品的根本性差异，前者是在逻辑层解决问题，后者是在实现方式层。

逻辑层是实现层的基础，有了逻辑层，我们就可以根据实际情况，当时的科技发展程度，可能利用的工具去相应的构建实现方式层即可；比如唐代哄女友开心送的是胭脂，现在就是包包或者口红，逻辑上都是投其所好，实现方式上，女友所好因为科技水平发生了进化。

那么，产品定位为问题解决方案的好处是什么？

（1） 更加底层和体系全面

避免大家对产品的理解局限在形式的认知上，而忽略了对其本质的探索和思考；解决方案会让我们不仅去考虑实现方式，同样也会考虑实现逻辑层，能够对一切可以解决问题的内容都纳入进来，保障用户问题的充分解决，诉求尽可能的满足；

（2）避免无用功的发生

看过思考快与慢的都知道，大脑喜欢走捷径，实现方式层是大家擅长的也是大家愿意做的，但这往往不靠谱，会让我们忽略了逻辑而关注于实现层，最后花费了很多精力，但问题没被完全解决掉；

（3）避免陷入为了做“产品”而产品，陷入主观视角中

我们的本质是解决问题，考量的是问题有没有解决，而不是停留在自己的感受中无法自拔，很多产品经理容易与用户“感同身受”，产出了一大堆策略，除了感动自己外，用户的问题还是真实的存在并没有被解决掉；

最后，我提一个思考：

大家有没有想过，假设我们知道了促进需求变化的条件，再根据成熟行业的发展经验，是不是我们就可以构建出比较全面的行业需求图谱呢？这样就可以更清楚的推演出行业产品的发展方向，以及可能存在的商机机会；感兴趣的朋友可以在评论区互动，我会在后续文章中发布该方向的内容；

以上是我对产品底层逻辑的理解和思考，希望可以抛砖引玉，对大家探索产品本质有所启发，辅助大家设计出更好的产品。