抽象能力的重要性

以前写过很多产品经理相关的文章，最近在做新项目，有一些新的看法。

即抽象能力的重要性！

什么是抽象能力？简单来说就是在特性里找到共性。当然，这个能力不只是产品经理需要有，我觉得大家都应该要有，对自己还是很有用的。

给大家举几个例子解释抽象能力。

例子一

首先是使用明细的例子。假设现在和大模型交互，已经支持了文本、语音交互，本次项目要支持视频交互，同时因为视频交互耗费token比较多，想增加页面让用户能够看到使用明细。要求文本、语音的使用明细也能看到。页面展示有两种设计方案

A：请求id 视频交互 消耗token

B：请求id 交互类型 消耗token

方案A就是没有做好抽象，突出视频交互，其它交互类型用-表达。短期看是可以的，但后续如果支持其它多模态的交互呢？是不是用户也分不清了。方案B就清晰很多，能够很好的适应后续的扩展。

其实选择方案A的原因能够推测出来，因为是跟着视频项目一起做的，所以主要考虑或者主要突出视频交互了。

例子二

对于会员体系，免费用户和付费用户的权益有不同的使用次数。如外卖分为及时达、慢慢送，免费用户对及时达、慢慢送有次数限制，付费用户及时达有限制，慢慢送无限制。要求对用户的用量做提醒，促进用户购买转化。

这个需求是很对的，而且作为一种产品形态也很自然。这也有几种产品设计方案。

A：对于不同会员的不同权益，根据其是否有限、无限的次数，根据是否为新老用户，根据当前权益用完其它权益是否用完，进行不同的提示

B：对当前权益进行余量和耗尽提醒，同时告知其它权益的剩余情况

我想要的是方案B，因为够通用。想几个后续可能得扩展情况就知道了，如果增加了新的权益，如果现有权益的次数进行了调整，A方案都需要进行变更。而且恐怖的是，A方案的复杂度不是线性的，很可能是指数级的。

为什么会选择方案A呢？我觉得主要是因为简单。按照现在的会员体系和权益分叉就行。

例子三

还是上面的例子，假如说要coding实现权益核销（使用），怎么做呢？

A：对于不同会员的不同权益，根据其是否有限、无限的次数，进行核销

B：无会员概念，全部权益化，根据用户请求类型，选择对应的权益进行核销

我会选择方案B。因为核销和会员每什么关系，核销适合权益强绑定的，有对应的权益且有剩余，就核销，否则核销失败。这样的一个好处是，无论后续加多少会员、多少权益，核销逻辑是统一的，改动范围控制的很小。否则后面如果增加新的权益、新的会员类型，A方案需要四处找修改位置。

这也是抽象能力，或者说建模能力。

总结

佛教里有着相的说法，也有见山是山、见山不是山、见山是山的境界，这和我刚才聊的抽象能力特别契合。希望我们后面能够多多的抽象。