近两年来，我一直努力把产品竞争力评价和产品定义的逻辑统一起来，你能够定义一款车，自然也就有能力评价一款车的竞争力。反过来，产品定义的方法应该与产品评价的方法在逻辑上是一致的，否则产品战略无法形成闭环，就会变成规划、设计、开发、销售各部门自说自话，很难针对整个链条进行优化。
今天我继续承接本月初那篇文章《透过产品可以看到车企几乎所有问题》，介绍我对产品评价与产品定义整体逻辑的思考。借此先更正之前文章的一处错误，吉利几何A并非纯电平台。写上一篇文章的时候基础资料搜集不扎实，如有误导大家非常抱歉。
这个整体逻辑首先由下图所示：在进行产品评价时，我们需要针对这款车目标用户和使用场景的特征，理解目标用户在具体使用场景下的产品需求，然后才能做出真正有意义的产品评价——也就是评价每款车是否能够在真正的使用场景中满足用户需求，哪些方面满足了，哪些方面仍有问题。至于在具体场景下的用户需求，无非就是用户希望在每个具体场景下，这部车能够完成哪些工作（功能需求），以及这些功能的实际能力（性能）和使用体验。所以最终我们操作的产品评价都是针对一组特定的使用场景，站在目标用户的立场上，围绕功能、性能和体验展开的。
反过来，同样是上面那张图，产品定义也是同一个逻辑：图的左侧，也就是目标用户和使用场景，决定了用户对车的基本需求。这些需求就是目标用户希望这款车在具体场景中解决哪些问题（功能），带来什么样的综合感受（体验），以及每项待解决的问题做到什么程度（性能）。产品定义人员需要充分理解上述内容，然后再进入设计和工程环节：为了达到预期的用户体验，完成用户期待的功能（Function list），如何将设计和技术充分结合。同时为了让自己的产品既具备竞争力，又满足成本约束，每个功能做到什么样的性能水平是必须充分考量的，这个部分很大程度上取决于对标分析。也就是说，落到产品定义流程上，我们同样始于理解目标用户，确定使用场景，然后围绕着功能、性能和体验展开，通过设计和技术的创造性组合达成目标。
至于使用场景的选择，一方面不同人群对应着不同的生活方式，他们必然有最为看重或者最为独特的使用场景需求，这部分是可以数据化的。另一方面，在已知的细分市场之间，由于body type的差异，使用场景也会呈现出显著差异，这同样是可以数据化的。基于这样的数据，我们既可以用来进行产品定义，也可以拿来进行产品评价。
于是这套逻辑又回归到了So.Car的产品定义工具中来：在战略层我们选择需要达成的品牌定位，这种定位选择最终是要落实到目标用户和目标使用场景上面的。在体验层我们需要定义能够最大程度满足用户核心场景功能和体验诉求的产品方案。而到了产品层，我们需要让这个方案具有完备性：既要拥有魅力属性，也要满足所有的必备要求。
如果我们能够理解上述整个链条，我们就更加容易通过产品看到目前很多车企在产品规划、定义和开发流程中可能存在哪些问题。例如针对一些功能具备、但性能和体验存在严重偏差的产品细节，我们可以预计这个链条最有可能存在下面两个问题：
1、 产品定义人员与设计和工程团队没有充分互动：产品定义团队只是把用户需要具备的功能（很多时候还是配置）传达给了设计和工程团队，而设计和工程团队又是站在自己的视角上定义了最终的产品方案。最终这个方案能够实现定义团队要求的功能，但这个功能使用起来完全不是用户想要的。在这方面去年我在迈锐宝上看到的car play就是最恰当的一个例子：他把手机的界面等尺寸地投影在了一块七寸屏上，而且还不支持I-phone 电缆直接连接。
2、 工程团队与供应商之间缺乏充分互动：我们都知道国内主机厂绝大多数的前瞻技术本质上都是供应商推动的，于是这些前瞻技术在装车前就必须进行更确切的验证，否则极有可能出现卖家秀和买家秀对比的尴尬。几何A console上的那个智能透光表皮就是这样一个例子。
造成上述问题的关键，其实还是我们的产品定义过程中，对于什么是产品方案缺乏必要的呈现和讨论造成的。解决这个问题，整个链条就需要实现从围绕配置清单向围绕功能清单的转变。相关文章之前也有讨论，大家可以参考：《从Feature list到Function list，对应的是产品定义逻辑的迭代》。
最后，我们再说回产品评价：只有真正理解整个定义的逻辑，你才知道产品该从哪里入手展开评价，否则就会出现各说各话，或者只是讨论每个产品好不好看这类问题。至于针对产品细节的评价，如果只会拿自己的两个破拳头在那里展示空间大小，或者纠结在扭力梁还是多连杆这种话题上面的话，你离理解产品还有非常遥远的距离。
