今日兴致不错,就和各位道友聊聊,观主所理解的三种电商平台产品线规划策略(ps:根据不同行业、类型会有细微差异,以下仅供参考;尤其要注意,不要拿某宝来比对,人家是最终形态下的产物,早期和中期的电商玩不起,还是先把业务做扎实吧):
一、按使用流程分:
1.核心依据:以用户使用的流程为依据做切割和划分。
买家线:从找到平台到找到商品到完成交易到售后环节再到二次购买的一整条交易主线。2.举例说明:卖家线:从入驻平台到成为商家到开店上传到接单卖货再到售后跟进的一整条服务主线。
平台线:从服务买卖双方到活跃激励整个平台用户到拉新推广到服务保障到财务结算等。
不分先后:
a.搜索线(分类管理+标签管理+推荐逻辑+搜索算法+排序、展示逻辑等)3.人员要求:b.展示线(内容、广告位管理+首页+落地页+聚合页+seo/sem支持+专题、活动页、帮助中心等)
c.子频道线(按需设立:一般独立于平台主交易流程之外多子频道或者常态活动频道,都会设置一条单独的线来管理,如某宝聚x算、抢购功能、如某家居商城的装修资讯频道、如一些电商的论坛等,这条线相对较为灵活机动,类型多样)
d.主交易线(商品详情页+售前服务+购物车流程+下订单流程+支付流程)
e.买家后台线(会员中心+信息管理+虚拟钱包+售中、售后服务+订单管理+收藏、历史浏览等增值功能+用户成长和激励体系等相关延伸,不赘述)
f.卖家后台线(信息管理+商品管理+订单管理+财务管理+物流管理+库存管理+推广管理+店铺管理等+用户成长和激励体系等相关延伸,不赘述)
g.平台总后台线(平台总后台,功能在早期考虑到代运营和强管制需求,一般会包含并大于卖家后台功能,同时需要注意以下几点务必早做打算:权限切割、财务结算、客服系统对接、数据监控和埋点、用户成长和激励体系、客诉和服务管理以及商家管理等)
h.移动线(包含移动端app和微信和wap,如果是平台性质的,前期不推荐过早的介入移动端,当然看具体行业,移动线前期主要是将平台的功能精简并迁移,存在功能重叠严重,推广和开发成本高等问题,所以判断是否需要移动线应看公司战略,以及移动线的优势是否对业务有帮助,再做定论,观主经历过不少移动做个花架子或孤注一掷结果半途而废的例子)
i.金融线(主要两块,对买家的消费金融+对卖家的供应链金融,大多数早期平台没有,因为授信和风控难以控制,但是b2b供应链想对容易,因为证照齐全,交易真实性保障度高)
按照分线策略,在招人时需注意,应聘人员是否有符合该线要求的相关项目经验,过往工作内容是否与该产品线的要求相近,在工作经验上可适当放宽,主要看对某条线,比如对商品展示的了解程度,因为该线是模块化切分后做前后衔接,所以每条线上的人能力不用太全面。4.优劣对比:
优势:各线更为专注,各线间的关联性强,对各线的产品经理的能力要求相对较低,不需要过于全面,假设某条线的产品较弱,前后关联线可以通过协作,做很大程度的弥补,发挥整体优势。劣势:一旦某条线出问题,衔接上会很混乱,同时产品经理对其余每条相关产品线需要花很大精力去了解和熟悉,一旦消息不透明或闭塞,就容易产生盲区,造成设计上的前后不一致。
二、按业务板块分:
1.核心依据:以平台业务板块来切割和划分:
按品类:一般适用于全平类平台,不同品类之间差异化太大,会按品类来做区分。2.举例说明:按模式:一般适用于多种交易模式的平台,如b2b供应链大多会分三块:撮合、现货和金融。
用某化工b2b平台举例,分以下几条线(该线特点是出了移动线其余每条线对应到一个业务部门负责):
a.撮合交易线(询盘相关业务:从采供信息展示、搜索、下询盘到撮合交易到线下追踪等)b.现货商城线(类似一个小天猫,不展开赘述)
c.供应链金融线(类似p2p,不展开赘述)
d.用户体系线(用户管理与激励,招商和认证等等)
e.用户后台线(买家和卖家的管理后台,不赘述)
f.总后台线(整个平台的管理后台,对以上几条线形成管理和支撑,包含BI系统)
g.移动线(包含app和微信,将部分核心业务流程迁移到移动端)
3.人员要求:
相比上一种分法,这种方法人员数量和线对数量都会减少,但几乎每条线都会涵盖比较完整的一段流程,所以对每个产品经理的能力、经验要求会提高,需要每个产品经理都有较为全面的能力,同时对完整流程有足够的操作经验,招人的侧重除了不变的“项目经历契合”,改变的是“需要从专提升为全面”。4.优劣对比:
优势:每个业务板块延伸的产品线,相当于一个独立的项目,各线之间更为独立,不容易因为某线出问题或者延缓导致联动性问题发生,同时每条线因为独立对一个业务板块负责,需求会更有针对性,支撑会更有效,更可量化。劣势:任何一条线的人员要求都较高,否则就容易自坑,如上例,无论询盘线还是现货线,都需要独立完成用户的整个使用流程的产品设计,相比方法一,由于整个平台的在产品设计过程中被相对独立了,可能带来的问题就是容易过于沉浸,导致业务板块之间的协作和支撑缺失。在项目管理上,因为大家负责的实际设计会有很多类型上的重叠,比如询盘线和现货线,都要关注seo或者app或者微信,这种情况下,在需求到开发的过程中容易产生冲突和掐架。
三、按人力资源分:
1.核心依据:这种分法,对于小团队(三无创业公司)特别好用,说白了,早期业务不清晰、人员预算不充足时,这种类似游击战的打法未必漂亮,但是至少高效和高能!2.举例说明:
实际操作就是一拖多,大家读书时都知道先进带后进,帮困小组吧?3.人员要求:这个分法很简单,就是把现有人员按能力和经验高低分层,然后按金字塔形一层层排布:执行类往下推,决策类往上推;难度往上推,简单的往下推。
比如观主目前在的创业公司,就一个app,一个web,一个后台,三个产品,有2个产品助理+观主,就能解决了,产品助理主要做些非重要的设计工作和文档整理,观主主要做需求分析和产品功能制定等稍微需要烧脑的部分。
至少一名全栈产品经理或20%的中高级产品(二选一)+80%初级产品,不展开赘述。4.优劣对比:
优势:省钱,省人,设计出来的东西,中规中矩,高度统一,不容易出大乱子。劣势:但是一旦出大乱子,就是天大的乱子,因为决策层较少,点的错误容易瞬间扩散到面。
以上就是观主的一些拙见,与各位分享,举例中或有不详尽之处,敬请谅解,无论大公司、小公司,都可以按以上的方法来分,无非最终划分到的颗粒度有多细致而已,希望对大家有帮助,该篇不单适合产品团队管理者,同样的,产品经理想要有提升,必须对管理和规划有足够的理解!