007. 《淘宝十年产品事》目录初稿

最近赶工了一下,主体框架完成,Word统计净136k字,大家看看目录如何?内容正在内审ing

1. 引言:故事要开始了 3

初心:为了么会有这本书 3

本书的写作特色与局限 3

本书的主要结构 5

本书的产品定位 6

2. 从“商品”说起 7

001. 一个买家的淘宝之旅 7

002. 产品经理都是分类控 10

003. 看似“完美”的类目+属性 12

004. 解决问题,而不是做产品 14

005. 谈感情,还是谈利益 16

3. “淘~~”就是导购 18

006. “淘宝”的由来与首页 18

007. “导购”到底是什么玩意儿 22

008. 被别人打败,不如被自己打败 24

009. 向超市学习,前后台类目拆分 27

010. 旧的新概念:SPU/SKU及其他 29

4. “搜索”的启示 32

011. 从通用搜索到淘宝搜索 32

012. 效率与公平,买家与卖家 34

013. “阿基米德”与卖家的抗议 37

014. 从技术到业务,解决“局整矛盾” 40

015. 事关体验,导购的“皮子”与“里子” 42

016. 心态的修炼,从罚人到渡人 44

017. 从商品到产品,一站式的理想 47

018. 最懂你的搜索,垂直化与个性化 49

5. “电商”还是商 51

019. 广告,从招财进宝开始 51

020. 电商参与商业的轻重程度 54

021. 从淘宝团购到聚划算 56

022. 淘江湖的遗产:无心插柳柳成荫 57

023. C2B与预售,交易的未来 62

024. 指路明灯,聊聊数据产品 64

6. “下单”之前 66

025. 支付宝、交易系统的诞生 66

026. 购物车的救赎:促销和运费模板 71

027. 第一代营销工具,商户平台诞生 73

028. 第二代与第三代营销工具 75

029. 我的淘宝?是你的淘宝吧 79

7. “交易”之时 82

030. 纠结玩意儿,到底何时减库存 82

031. 虚拟交易攻防战:从自动发货到直充 85

032. “拍卖”和“秒杀”,让人欢喜让人忧 87

033. 终极“大统一模型”?交易平台化 90

034. 选择相信,卖家能不能拒卖 92

8. “付款”之后 95

035. 有关“货”的进化与退化 95

036. 售后保障非小事 97

037. 评价系统的早期优化 99

038. 对“亲,给好评哦”的反思 103

039. 选择用户价值,有关申诉 105

9. 淘宝体的“旺旺” 108

040. 贸易通与淘宝旺旺 108

041. 阿里旺旺的分分合合 111

042. 顺“我”者昌,逆“我”者亡 113

043. 系统化思维,反垃圾的智慧 117

044. 聊聊未来的移动与无线 119

10. 以人为本 123

045. 别了,产品经理的能力模型 123

046. 产品经理练级攻略 130

047. 前辈谈产品与产品经理 132

048. 淘宝在产品经理培养上的探索 137

049. 给想转行做产品经理的同学 141

11. 尾声:从《人人》到《产品事》 144

2009,人人都是产品经理 144

2010,江山不幸诗家兴 146

2011,人生得意须尽欢 149

2012,淘宝十年产品事 150

006. 谈感情,还是谈利益

以前,淘宝有一个很大的竞争对手叫Ebay Ebay在中国的前身叫易趣,后来被Ebay收购了。一开始我们怎么把卖家从易趣挖过来?那时候淘宝的创始员工,用了很简单的一招,就是跟卖家不停的聊天,打感情牌。

顺便提一下淘宝为什么有花名,花名不是马云想出来的,而是从实践中战斗出来的。当时,我们在淘宝的论坛上整天跟卖家热火朝天的聊天,有一个著名的ID叫小宝,韦小宝大家都知道,韦小宝有一个特征,老婆多,卖家就开玩笑说你既然叫小宝,那其它的淘宝女小二就都算你老婆吧,叫剑屏、双儿、阿珂啊,小宝一听有道理,大家都起了花名,加上马云个人狂热的喜爱武侠小说,淘宝就这样有了花名文化。

回到感情牌,小二把卖家引到淘宝平台,通过免费留在了淘宝,那时候淘宝跟卖家的关系是非常紧密、非常融洽的,大家就像一家人。但是,有了类目属性以后,整个关系颠覆了,2007年小二们已经尝到这种痛苦了。老小二们说,以前发一个新产品,论坛发一个公告,叫好声一片,后来发布任何一个产品改进功能,总是一片骂声,为什么这样?最早就是由于类目属性造成的,骂的很搞笑,他说这次改进是不错,但是我还是要骂你一声,即使给他一个很好的功能,也要被骂,那会儿的一些产品经理是很沮丧的,刚进来的时候,大家非常在乎用户的声音,我们知道做产品经理最在乎的就是用户,本来希望通过用户的赞美声音给自己提升信心,结果被挫伤得一塌糊涂。

一起来看看这个招骂的类目属性吧,以前商品从01万,到10万,到100万,到1000万这样的数量级,虽然整个分类不停在变,但只有类目的改变,卖家是不受影响的。为什么这么说?比如服装,小二在后台分一下,分成男装女装,那么,有的服装就会挂在男装下面,有的会挂在女装下面,我们的小二会通过工具,用关键词来判断,把商品都挂到新的类目下,所以卖家该怎么卖还是怎么卖。

虽然会有错误,但错误不多,排查错误的工作可以由卖家自己搞定,工作量不大,就是移移类目。但是有了属性以后,问题来了,属性一修改,比如男装这个类目,每个商品是什么属性值,小二是管不过来的,需要卖家自己填,否则就强制下架。

可能有的同学要问,为什么不能用一个默认值“其他”,至少保持这些商品在架上?因为属性的引入就是因为商品太多了,如果为了避免下架,而把很多属性值为“其他”的商品保留在架上,就违背了提出属性的初衷。假想一下,那样商家添加属性值的动力就会低,然后前台出现很多“虽然有属性值,但是无法筛选”的商品,将全是垃圾数据。

所以,下架后,卖家就只能一个一个填,每个商品算1分钟好了,如果500个商品,就是500分钟,那一整天就废掉了,他就忙着在那里填属性值,不然就没办法上架。这样的话,类目调整一次,他就歇业一天,而类目调整不是只有一次,而是经常性的,所以,你能理解卖家的痛苦了么?

而更大的痛苦还在于小二和卖家之间出现了不可调和的矛盾……

矛盾的关键就是,小二越来越喜欢调整类目和属性了。

大家都知道,类目层级越深,意味着买家流失越多,买家要找到一件商品,一级一级走下去,所有的结点都是树状的,而有了属性,路径就变成网状的了,它的路径变短,转化率变高,买家体验变好,假设属性值调到一级类目以后,他可以通过服装到品牌,通过服装到男女,通过服装到材质,买家可以更快通过“类目+属性”找到他想要的商品。当然这个例子比较极端,但事实就是小二们开始把类目树变浅,利用更加灵活的属性来替代类目的分类作用。

我们再来个实际的例子帮助大家理解。

最早只有类目的分类是男装,然后上衣,然后T恤,然后polo衫,四级。有了属性以后,polo可以变成款式,甚至T恤也可以变成款式,这样类目变成了男装、上衣两层了,到上衣以后,既可以选品牌,也可以选款式,也可以选其他材质,两级就可以完成了,还多了很多其他属性可以筛选。

所以,小二就有非常大的热情调整类目属性,可以提升转化率,小二来说是帮助KPI的大好事,对消费者也是好事,只是对于卖家来说,今天忙这个类目,明天忙那个类目,每天忙商品,每天被下架,然后上架。如果只是改一次,卖家也是能接受,但这是周期性的,比如,“风格”这个属性是季节性的属性,有时候会把它提得很前面,直接提升为一级类目的公共属性,这样意味着今天男装的类目长成这个样子的,明天的男装类目那个样子的,一天到晚变来变去,而且悲剧的是,卖家也都知道这些调整是合理的,但是一年到头这样调整,意味着他一年到头都在编辑类目,还得专门养两个人在那里,一天到晚改类目,痛苦无处排解(这个问题,到2008年有了个很巧妙的解决方案,这是后话,暂且按下不表)。

淘宝和卖家之间的兄弟感情破灭了,当然卖家不会走,因为还有利益。靠感情维系的关系是脆弱的,靠利益维系的关系是稳固的,从这个意义上讲,淘宝和卖家也都在逐步成熟。

2006那一年,我们还做了一个产品,就是SPUSPU = Standard Product Unit,标准化产品单元),这是一次对商品的“产品化尝试”,但没有放在整个商品体系里面,而是单独建立了SPU库,主要针对书籍的,因为有很多商品的分类可以分得非常精确,现在大家都听过“标品”这个词,标准化的商品,它确定了品牌、型号以后,就会得到一个唯一的产品。这套SPU的初衷只是针对一些标品的,所以它的设计没有办法融合到整个商品体系里面去,就用了一年就废掉了。现在淘宝的SPU与这个初衷不同,又是后话。

2006年年底的时候,类目属性的故事就差不多讲完了,这也是淘宝早期商品体系的整个架构。商品这个词比较专业,其实,大家更喜欢叫“宝贝”,为什么?我想,这一定和“淘宝”这个名字有关,接下来,我们就来聊聊这个有浓郁“导购”味儿的名字,以及导购的一些话题。

004. 看似“完美”的类目+属性

2003年一直到2006年下半年,过了三年多,我们才引入属性,这是一个革命性变化,为什么这么久?一方面,淘宝小二对业务的理解有一个过程,商品管理的本质是分类(再深究一步,分类是为了更好的匹配供求关系),今天很多小二都能回答出来,但当初能够回答出来的很少;另一方面,商品数量是逐步增长的,这个问题到2006年才变成成一个会死人的问题,对产品经理来说,问题总是太多,资源总是太少,什么问题是会死人的,才优先解决。在0405年,用类目分下去,还不会死人,到06年商品数量已经破千万了,意味着这样分下去就没办法分了。

这个时候,淘宝有一个的传奇产品经理——一灯,提出了属性的概念,属性很好的解决了上一节提到的两个问题。与类目相比,属性更离散、更灵活,类似Tag一个商品只能属于一个类目,但可以有多个属性,今天大家都能一下子想到这个概念,但在2006年,不容易。

品牌是一个属性,性别、颜色、尺寸、材质也是属性……属性下面会有值,即属性值,比如品牌下面有杰克琼斯、耐克、诺基亚、苹果,所以,属性的本质还是为了分类。

其实,最早有属性的类目是食品,淘宝上卖食品,食品监管部门说食品有些标准化信息必须有的,比如,批文、生产日期、健字号。当时对食品类目做了十几个属性定义,每个商品有不同的属性,不同的属性值,最早这个属性只是用来描述的,而不是用来分类用的。淘宝的很多产品,都是灰度发布的,比如先用个别类目做属性的试点,就是一个例子,虽然这个例子有点被动,但思路很有价值,可以小范围试错,优化,成熟之后再大规模推广

回到属性,我们讲到类目之外又有了属性,属性下面有属性值,其实有的属性值还会变成子属性。子属性是为了更好的分类,比如像品牌和子品牌(或系列)。品牌是属性,阿迪、耐克、匡威是属性值,同时,阿迪又会是一个子属性,它的子属性值为“Performance系列(三条纹),Originals系列(三叶草)和Style系列(圆球型LOGO)”。如果没有子属性的概念,那又会出现没有子类目一样的情况,太多的属性值并列,导致无法筛选。

品牌和系列,在现实中也是有从属关系的,比较适合把系列挂在品牌下面,这样一个品牌有相应的系列,另外一个品牌有另外相应的系列,所以说,属性和类目一样,也是一棵树——属性树。这是属性与简单Tag的差别,Tag没有结构,更加松散,上亿的商品没有办法用如此松散的Tag来管理,所以,属性有结构,并且,也有级数的控制。

我们再来看看属性值的管理,大家有没有发现属性值和属性值其实是不同的?有的比较简单,属性值是离散的,比如性别只有两类——男、女,最多加上“中性”。有的稍微复杂一点,比如手机的品牌下面有苹果、诺基亚、三星,服装的品牌有杰克琼斯、耐克等,但小二很难列全,因为这个东西是不断变化的。还有的更复杂一点,比如重量,它是一个连续的值,没有办法全列出来。用一个表格简单的表示一下上述三种属性值,如下:

属性值分类

是否可枚举

是否可输入

说明

1,如性别

小二能枚举完全

2,如品牌

小二无法枚举完全,需要卖家帮忙

3,如重量

客观上有无穷多的属性值

属性值在客观上的不同,导致了产品上的一些区别,这三种从上到下,有两点值得说说。

第一,管控的尺度是越来越松的,比较容易理解,枚举不可输入——性别,是人都能列全,我们直接定了。枚举可输入——品牌,我们设想一下,如果品牌不能由卖家输入,卖家发布商品的时候就可能找不到自己的品牌。这时候怎么办?大家很容易想到解决方案——增加“其他”。但这样会使得我们永远不知道某些品牌,所以,可输入起到一个信息采集的作用,因为这类属性值小二是不可提前预知的。系统通过用户输入的行为进行一个排序,比较重要的就跳出来,小二把它加到可选范围里面去,这样属性值就更完善了。而不可枚举,是放开让卖家自己玩的。

第二,分类的功能是越来越小的。一般来说不可枚举的东西,是不可以分类的,这意味着这个值是描述性的。比如说尺寸、体积、重量,这种是不可枚举的,因为这种东西直接拿这个值做分类是没有意义的,但是有些时候可能会按区间来做分类。比如颜色,它某种程度上跟价格一样的,因为颜色稍微变一点,就可以分出来,但是有谁能够说出20种以上的颜色?很难,如果你把几万种颜色描述出来,那对用户没有意义。所以产品经理就在做简化的动作,我们归归类好了,比如说红色、蓝色、灰色,再细一点,天蓝色、天青色,再加个“其他”,这样来分的,把一个不可枚举的属性变成了可枚举的区间。

有了这些属性以后,怎么跟类目搭上关系?

首先,属性只能挂在叶子类目下面,非叶子类目其实也有对属性的需求,但那是通过另外的方式来实现的,下文谈到公共属性的时候,会说到这个问题。

其次,类目和属性是有关联关系的,这避免了某个类目下无关属性过多导致的麻烦举个例子,对于T恤这个类目来说,假设父类目是男装,品牌这个属性肯定是需要的,材质也是必须的,颜色也是需要的,尺码也是需要的,但性别不需要……我们发现,有些属性适合放在这个类目,有些属性不适合放在这个类目,所以,我们建立了一个很重要的关系,就是类目属性,这是淘宝的专有词汇,类目与属性是有关联关系的,某个类目都有自己特有的属性。

那么,类目和属性怎么跟商品关联上?其实很简单,卖家发布商品的时候,先从根目录选到叶子类目,再选择这个叶子类目对应的类目属性的各种属性值。前台,买家在挑选商品的时候,也能从类目和属性两个维度筛选。

至此,我们对整个商品的描述很完整,也很完美,有了属性以后,我们分1亿商品都能轻松搞定,假想当时,设计出这套体系的产品经理们,一定非常有成就感。但是,接下来新出现的问题才是更严重的,大家想想看,这个看起来非常完美的体系会有什么问题?