3年产品工作总结(上篇):从9个方面深度思考 To B 与 To C

25 评论 33601 浏览 378 收藏 22 分钟

这是一份3万字十足干货的工作总结,主要是作者对自己从事产品这份工作的回顾概述,其中包含对行业的理解,对产品工作的新认知,对技术上的认知等。此文为上篇,主要是从9个方面深度思考 To B 与 To C 。enjoy~

从上一篇文章到现在,已经半年没有输出过东西了,真不是懒,实在是太忙了,自从加入这家公司以后每天基本都是很充实,很有挑战的,很高兴能经历了一团乱麻,到现在渐渐捋顺走出困境的经历,我想这是对职业上一段不错的成长经历。

一直想写一篇对这份工作的总结,其中包含对行业的理解,对产品工作的新认知,对技术上的认知等,但是每每想要落笔,居然发现脑子空了。不知从何开始说起,也发现这个题材实在太大,经历实在太多,学到的实在太多,想要剥离出,回忆起来,整合成完整的体系,真不是随随便便就能完成的。

从筹划,到落笔,再到成文,无数次修改和优化穿插其中,毕竟工作年限还是有限,不能和见多识广的大牛们同日而语。

文章结构:

  1. 基本情况
  2. To B 与 To C 的深度思考
  3. 公司行业模式分析
  4. 产品技术架构描述
  5. 行业细分创意类分析
  6. 行业细分编辑类分析
  7. 未来计划内的产品规划
  8. 开些脑洞不能内部落地的产品规划
  9. 一些做人做事的思考和技巧
  10. 展望个人

以上几段,将逐一分列进行思考后输出成文,可交流,可指正,可相互学习,多多包涵。

一、基本情况

所为基本情况,分两种:一为人,二为企业。现逐一介绍:

人,在北京,之前做过社交,做过教育,对整个产品行业有过自己一些输出和理解,可以翻看过往的文章记录,年龄不大,粗算一下,正式步入产品行业工作,就是从15年的1月至今,仅仅3年,还是个小学生。

再说说企业,目前我所在的企业是视觉中国(后文均简称为视觉),一家上市公司,主要做图片授权交易的平台。如果你的企业有UI设计师或者是内容型公司,一定会知道我们。近两年,国家开始重视知识产权这块,所以我们的整体增长率都是不错的。

视觉整体是To B的,不对个人,这也造成了我们近两年以来对商业模式、对客户群体的摸索和探索。

在图片细分行业,我们是属于国内第一把交椅,占有约50%左右的市场份额,也是世界第二大图片公司Getty images的中国独家代理,独一无二的内容,造就了不可逾越的内容壁垒,造成了“不来我这,你就没得选”的袭断地位。

具体的行业模式,在第三段中能讲的都详细讲给大家,这里也就不多说了。

加入这家公司,也算是机缘巧合。公司高管在网络上看到我撰写的文章,我也恰好留了联系方式,就找到了我,吃吃喝喝之后直接敲定让我加入。

讲实话,当时的状态是科研状态,每天都在探索市场上的新玩意,结合自己过往的经验和理解尽可能地输出总结,正在梳理阶段是不太想进企业工作的,因为知道一旦进入,势必要放弃这种状态。果不其然,中断许久,也算是鱼和熊掌不可兼得吧。

我在公司内的职位是web产品经理,也就是唯一门户的掌控者。我加入的时候,恰逢十年一遇的底层架构重构,前端也无法幸免,一并在重构。重构的原因是当时我们的数据量增长实在过快,核心内容也就是图片,已经逼近2亿张。这是一个很恐怖的数据量级,十年前的技术架构已经无法支撑这种量级,并且也无法迎合当下的公司发展。所以,高层大笔一挥,决定整个架构重构,这真的是一个十足的工程,加班加到吐血。

另外一个重要原因是视觉最初实际是两家公司合并构成的,一家是华盖创意,一家是cfp,合并之后变成完整的视觉,但是由于是两家公司,底层数据一直是割裂的,仅仅在呈现上是一套网站而已,这次重构对于内部人的一个重大意义是数据整合,将两家公司的底层数据进行合并和整合,完全推翻过去,拥抱未来。

整体的完整上线,是在17年的4月份。不夸张地说,现在还在填补那时候的有些窟窿,这也导致了一些前端产品的遗憾。因为前端产品的核心价值不是补窟窿的,实际是在挖掘需求、产品体验、增长、转化等一系列环节发挥作用的。

在系统稳定后,我个人发起二次重构并获批。理由是一次重构时,人员不成熟,架构有缺陷,并且人员陆续离职,没有留下一丝一毫的开发文档,这也就导致了前端的可维护性极差,性能、稳定性也会有很大问题,出于各种考虑,从其它项目组中抽调精兵良将外带外招,形成了一个4人的敏捷开发项目组,开始二次重构。

可以说,这次的重构比之前的坑还大,因为这次是实打实的真正重构。之前是属于半路加入,有些东西是不用动的,现在不行,每个细节都要考虑到,缺一都会导致产品上线后不成熟的回滚,压力可想而知。

同时,还要兼顾老版本的更新、维护和迭代,还要兼顾新入职的研发的培训工作,真的是分身乏术。不过,实属感谢leader,给了充分的弹性时间也给了充分的信任和空间,前期基本没有任何干预,算是十分幸运且值得珍惜的一次机会,堪比于内部创业。

在当下,分模块的重构和迭代还在进行中,也终于可以专注于真正的产品经理的工作了。

还有一个成就,是推动搭建视觉数据化规范,制定核心的量化指标。不再是“瞎子过河,摸黑前进”,逐步将数据化运营,数据决定产品的思路,植入高层,不再是我是老板,说怎样就怎样,是用户说怎样才怎样。

这就是本人的基本历程和经历,接下来将以此为主线进行详尽的梳理和深度的思考。

二、To B 与 To C 的深度思考

视觉实属于To B 性质的公司,而且是To B 里非常特殊的,行业很窄,竞争壁垒很高,外部一时间无法了解清楚的行业。

之前一直专注于To C,一下转向To B,我想最大的收获和思考,就是在于这两种截然不同模式的体会。在2年前,我被面试,被问及To B 与To C 的区别。那时我还傻傻地说,交互不一样,To B 可以粗糙一些,但是功能逻辑必须明确;To C 是前端体验重要,要美观合理。没错,这确实是不同,但是现在回忆起来想想,实在太过于浅显。

实际上,To B 更多的是讲究对企业提供服务和价值传递,To C 更多的是讲究对终端消费者提供服务和价值传递,这是最大的不同,所以两类产品和目标完全是不同的。这也是基础,诞生之初也就是决定了两类产品该怎么做。

1. 产品 VS 服务

To C 的产品我提供了这个产品,直接拿到终端用户上,就可以产生价值收益。

To B 的产品的价值传递链和决策链是比较长的,同时 To B 产品不仅仅卖的只是这款产品,卖的还是服务支持,有可能产品只是整个服务环节中的一部分,是其中的一个因素。

所以对于To B的产品经理(也就是我)来说,要做好这个工作,不能把时间和经历都聚焦在产品本身上,还要有更宽的视野,结合更多的因素去考量。

To B 的产品,不仅仅是在做产品,其实也是在做一款服务。这个是相对比较大的一个基点,若运用得好和使用得当,必然是一把封喉利器。

2. 免费 VS 收费

To C 的大多数产品都是免费的,不谈精品的收费个例。隐含意思是,To C 产品的替换成本是非常低的,今天觉得这款产品不好,那我随时可以无痛地替换掉。

大多数是不需要深度考虑怎么收费,可能商业模式都比较简单:流量、商品,无非就是羊毛出在哪只羊身上。

To B 的产品大多数都是收费的,为什么?因为提供To B产品的企业,不仅仅是提供一个产品,刚刚说了,更主要的是服务,产品成本是相对固定的,而服务的价值或服务所承载的成本是不可估量的。所以对于大多数ToB企业来说,是付出了很大成本的,也就希望在售卖的时候,客户来承担这个成本。

也就引申出另一个问题,既然要收费,那如何来定价(ps:视觉不存在这个问题,有专门的销售团队,且策略无需产品方干涉)?其实也是重点工作之一,如何去界定产品价值,同时定的价格是你的客户愿意付出的成本,这里面有大量工作可做。难度在于是没有明确的量化指标,是卖1块钱还是卖2块钱?这里面也就有许多的因素在里面需要综合考量。

如今现在随着技术发展,越来越多的To B 产品采用SaaS服务,是替代传统的软件厂商往本地去部署、实施的一个技术,它的成本可以大幅下降,还是有相应的付费空间。

一般的企业云端部署即可满足,而保密度较高的企业,可能会有私有化本地部署的需求,这也就决定了团队在做这款产品之初是否要考虑这些。在前期的决定,实际决定了今后团队要付出的成本,你要储备的人才不同,你要使用的技术框架的不同,开发的成本和周期也都完全不同,最终也导致了你的定价不同。

比如,你的产品是支持本地化部署的,那你肯定还要有本地化部署的技术人员,可以每天去跑企业的来给进行部署,你的人员需要去驻场,需要帮助客户企业来梳理他的业务,需要把业务转化为团队能实现的需求,从需求再变成研发的功能,从功能,再到上线,从上线再到给客户的升级版本,还要同步给客户的培训和教学,整个过程的成本都是你来付出了的,流程也非常的漫长。而云端部署就省去了这些成本,只需要出个公告通知更新什么,有相应的知识库,也无需专人驻场,针对不同需求开发不同功能,一视同仁即可。

所以,本地化和云端部署两者之间如何去做差异化,两者之间如何去协同,如何通过云端产品来吸引住轻粘度用户群,培养用户需求,转化为重粘度,从而转化为私有化彻底离不开你的产品,从而开始收割期,这也是产品经理需要考虑的。

3. 体验 VS 效率

To C 的产品,往往是体验为王,这款产品的体验很好,那用户也就愿意多多使用。

To B 的产品,就不一定是这样了,往往是效率为王。哪怕这些系统没有那么流畅、好用、好看、炫酷,你也要去忍受着来使用,比如erp系统,他可以直击本质的解决企业管理的问题,可以让企业资产调动起来,可以让企业成本降低,可以管控员工,本质来说,其实就是在解决企业的效率问题(让他们高效地赚到钱,才能有钱给你啊^_^)。

4. 渠道 VS 资源

To C 的产品,活的好不好,用户量高不高,活跃度高不高,一方面是因产品本身而决定,还有大部分是渠道决定的。我是不是去百度买关键词去买流量?我是不是和某手机做软件预装合作?我是不是做地推……渠道决定了大部分 To C 产品的生死。

To B的产品,铺了大量的广告,实际带来的转化是非常少的,甚至是不成正比的。为什么?因为To B的产品不是说做好企业的宣传和推广,就能直接带来营收的。To B 类的产品决策链条非常的长,不是你一个人说了算的,你觉得这个好用,可以申请提案,但不是由你一个人拍脑袋就决策了的。leader还要去价值评估:我是不是真的需要这个产品?这个产品性价比如何?如果体量比较大,很可能还会发布市场招标,同时来几家公司投标看看性价比,需求满足程度,服务态度等等,很可能就会给最初始的这家给驳回,给别人做了嫁衣也就无法转化为营收了。

所以,To B的产品是否要组建营销团队,增加公司内的成本?能否变为组建代理商团队,向下一级一级分销制,节约成本?这些手段若是能合理运用,最终才决定了你的产品的用户量级,当然也不是绝对,袭断企业完全不在讨论中。

5. 通用 VS 垂直

To C 的产品,大多数都是考虑通用性问题,能覆盖多少用户,能兼容多少用户,从而不断地完善打磨细节,也就足够了。

但是To B的,在通用性的前提下,也要兼顾考虑垂直深度的问题。垂直化也是一直以来一直在说的,也就是当你的产品无限四垂直下去,也就能尽可能地满足用户的需求,可事实呢?不一定。可能在一些领域,做的越垂直,越深入,得到的回报,收益会越高,但是在某些领域就不一定了。

比容内容行业,你的产品通用性一流,体验一流,但是无核心内容资产,你的客户也是不会用的;比如数据统计平台,市面上大大小小十几家,只不过每家的侧重点不同而已,所以这时候就要打出自己的垂直特色:我家是帮客户免费深度分析;我家是个性化自定义产品等等,这也就能决定你所框到的用户群了。

通用和垂直是相互结合的,通用决定了我们产品的广度,可以覆盖多少客户群;垂直深度决定了我们产品的价值度,也就是值多少钱。

6. 角色 VS 决策

To C 的产品面向的群体非常单一,就是一个一个的个体用户,角色即决策:用户用的爽了,就能决定一直使用你;用户用不爽了,那就可以随时卸载你。

To B的产品就需要区分,谁是决策者。但是这个决策者最终,未必是最终使用你产品的人。所以这时候,就决定了,如何突破决策者,如何做好客情关系,进而还需要提高产品的体验,让产品最终使用者满意。你面临的问题和情况会更加的复杂,所以要处理的问题也会更加的多。

7. 业务 VS 数据

To C 的产品大多数会停留在业务层面,产生的数据是用来辅助优化你的产品,而不是决定性的因素。当然,如果变为决定性因素的话,证明是不可行,非痛点的产品,那就意味着原有的一切都会被推翻。

To B 的产品做业务时候相对比较容易,找准行业和切入点,开干。但是随着发展,数据才是未来决定的关键,你的数据量越多,你的数据链越长越完整,你未来可挖掘出的价值就越大。所以,很多的To B 产品不断地从数据往业务的方向来移动和倾斜。

8. 移动端 VS PC端

To C 的产品,现如今如果只有一个PC端,都不好意思出来打个招呼,PC+移动+H5+小程序已经几乎成了一家有点规模的企业的入门标配。

To B 的产品,90%都只有PC端(钉钉、教育行业那种的除外),毕竟场景是不同的。不过随着时代的变迁,有一些也必然向着移动端来转型,但是转型之路会非常的坎坷。因为最开始起家的时候就是在做传统软件,那样的技术架构和庞杂的功能,是很难转变为移动化的平台。

9. 平台 VS ISV

To C 的产品,可能更偏重于平台,不需要考虑太多ISV(独立软件开发商)的问题,考虑把产品做好,做好之后就会做大,做大之后我其实就变成平台,就可以提供给第三方或者吸纳第三方数据入住。

To B 的产品,最开始就要考虑是不是要做一个ISV的模式,还是要做一个平台级的服务商。如果是做一个平台级的服务商,是否有能力去接入和提供相应的行业标准来让别人接入;若是做ISV的话,应该找准哪个方向的市场来切入,能让公司能够活下去。

分享到这里,也就差不多了,这次是从本质结合这些时间工作进行的思考和梳理,表象的比如交互、页面布局、设计,我也就没怎么去叙述,好多文章都在赘述这些。

上述是近一年多来对业务间核心碰撞出来的思考吧,有说错的地方多多包涵,不懂的地方多多交流。

相关阅读

3年产品工作总结(中篇):以视觉中国为例,从产品角度分析图片行业

3年产品工作总结(下篇):开些脑洞不能内部落地的产品规划

#专栏作家#

吴邢一夫(微信号mystic326531548),人人都是产品经理专栏作家。3年产品经理工作经验,需求、用户、数据有深入研究。欢迎交流想法,拒绝无意义添加好友。

本文独家发布于人人都是产品经理。未经本站许可,禁止转载。谢谢合作。

题图来自 Unsplash,基于 CC0 协议

更多精彩内容,请关注人人都是产品经理微信公众号或下载App
评论
评论请登录
  1. toB的产品,特别是聚焦B端用户内部管理的产品,在产品发展的初期,产品经理不仅仅是一个产品经理,还必须是一个业务专家才可能做出好的产品。

    回复
    1. 表示认同 B端要非常熟悉业务流程。

      来自安徽 回复
  2. TO B 把产品作为部件,融入到客户的造钱机器中,让机器更有效率的工作。如果一部原厂车代表B端客户,有价值的改装是在不降低原有平衡基础上的性能点提升。

    来自北京 回复
  3. 写的不错。在产品言产品,垄断行业toB产品能精益求精确实NB,毕竟其他的不这样干,哈哈😄

    回复
  4. 很不错😊

    回复
  5. 视觉也就是偏TOB,不能完全屏蔽To C 的影响。还有你在To C 上认知浅薄,写的一些区分只是为了突出ToB的重要性,而相对贬低了To C 的产品路线和产品需求!

    来自江苏 回复
  6. 深度好文,值得赞赏。

    toB和toC产品本质区别在于:前者是为业务服务,后者为用户服务

    回复
  7. 有道理有道理,不过还是有更多的场景值得挖掘

    来自广东 回复
  8. 受教了

    回复
  9. 我也是做TO B的产品,确实TO B不仅仅是做产品,还需要做服务;而且TO B在决策的过程中时间较长

    来自广东 回复
  10. 感觉都是表面的,没深度

    来自四川 回复
  11. 对于我这个小白来说,在其中汲取到了一些想要了解的层面!

    回复
  12. To B 的产品,不仅仅是在做产品,其实也是在做一款服务。很多思路值得借鉴,GET

    来自上海 回复
  13. 能拜师吗,逢年过节请吃饭

    回复
  14. 受教了

    回复
  15. 文章总体讲解的挺好的,针对下面一句话我想评论一下:“To B 的产品,99%都只有PC端(钉钉那种的除外),毕竟场景是不同的。”由于个人是教育产品的产品经理,在教育的to B 产品中,移动端的产品还是比较普遍的,比如说教师/员工办公使用的APP等。

    来自北京 回复
  16. 我也是ToB类的产品同行,这我所理解的To B 与 To C 的思维区别,To C必须精通消化运营的逻辑和问题并给出解决方案,To B必须精通客户涉及产品的逻辑和痛点。

    来自北京 回复
  17. 看到了B端的深入思考,但是也不用拿C端做炮灰做铺垫和对比和打压和一刀切

    来自上海 回复
  18. GET,蟹蟹

    来自浙江 回复
  19. 受教了!2B和2C的产品决策链完全不一样,就像作者说的,2C的产品,决策的人往往不是使用者,所以把这其中的关系理清楚,才能做好2B的产品

    来自江苏 回复
  20. 确实很精辟

    来自重庆 回复
  21. 其实根本就不存在,纯To C或者纯To B的企业或是产品。

    来自北京 回复
    1. 赞同你的观点

      回复
  22. 我做过OtO,BtBtC,BtC。关于体验 v效率那块,总结的很精辟

    来自上海 回复
  23. GET

    来自江苏 回复