从上一篇文章到现在，已经半年没有输出过东西了，真不是懒，实在是太忙了，自从加入这家公司以后每天基本都是很充实，很有挑战的，很高兴能经历了一团乱麻，到现在渐渐捋顺走出困境的经历，我想这是对职业上一段不错的成长经历。
一直想写一篇对这份工作的总结，其中包含对行业的理解，对产品工作的新认知，对技术上的认知等，但是每每想要落笔，居然发现脑子空了。不知从何开始说起，也发现这个题材实在太大，经历实在太多，学到的实在太多，想要剥离出，回忆起来，整合成完整的体系，真不是随随便便就能完成的。
从筹划，到落笔，再到成文，无数次修改和优化穿插其中，毕竟工作年限还是有限，不能和见多识广的大牛们同日而语。
文章结构：
基本情况
To B 与 To C 的深度思考
公司行业模式分析
产品技术架构描述
行业细分创意类分析
行业细分编辑类分析
未来计划内的产品规划
开些脑洞不能内部落地的产品规划
一些做人做事的思考和技巧
展望个人
以上几段，将逐一分列进行思考后输出成文，可交流，可指正，可相互学习，多多包涵。
所为基本情况，分两种：一为人，二为企业。现逐一介绍：
人，在北京，之前做过社交，做过教育，对整个产品行业有过自己一些输出和理解，可以翻看过往的文章记录，年龄不大，粗算一下，正式步入产品行业工作，就是从15年的1月至今，仅仅3年，还是个小学生。
再说说企业，目前我所在的企业是视觉中国（后文均简称为视觉），一家上市公司，主要做图片授权交易的平台。如果你的企业有UI设计师或者是内容型公司，一定会知道我们。近两年，国家开始重视知识产权这块，所以我们的整体增长率都是不错的。
视觉整体是To B的，不对个人，这也造成了我们近两年以来对商业模式、对客户群体的摸索和探索。
在图片细分行业，我们是属于国内第一把交椅，占有约50%左右的市场份额，也是世界第二大图片公司Getty images的中国独家代理，独一无二的内容，造就了不可逾越的内容壁垒，造成了“不来我这，你就没得选”的袭断地位。
具体的行业模式，在第三段中能讲的都详细讲给大家，这里也就不多说了。
加入这家公司，也算是机缘巧合。公司高管在网络上看到我撰写的文章，我也恰好留了联系方式，就找到了我，吃吃喝喝之后直接敲定让我加入。
讲实话，当时的状态是科研状态，每天都在探索市场上的新玩意，结合自己过往的经验和理解尽可能地输出总结，正在梳理阶段是不太想进企业工作的，因为知道一旦进入，势必要放弃这种状态。果不其然，中断许久，也算是鱼和熊掌不可兼得吧。
我在公司内的职位是web产品经理，也就是唯一门户的掌控者。我加入的时候，恰逢十年一遇的底层架构重构，前端也无法幸免，一并在重构。重构的原因是当时我们的数据量增长实在过快，核心内容也就是图片，已经逼近2亿张。这是一个很恐怖的数据量级，十年前的技术架构已经无法支撑这种量级，并且也无法迎合当下的公司发展。所以，高层大笔一挥，决定整个架构重构，这真的是一个十足的工程，加班加到吐血。
整体的完整上线，是在17年的4月份。不夸张地说，现在还在填补那时候的有些窟窿，这也导致了一些前端产品的遗憾。因为前端产品的核心价值不是补窟窿的，实际是在挖掘需求、产品体验、增长、转化等一系列环节发挥作用的。
我个人发起二次重构并获批，理由是一次重构时，人员不成熟，架构有缺陷，并且人员陆续离职，没有留下一丝一毫的开发文档，这也就导致了前端的可维护性极差，性能也会有很大问题，出于各种考虑，从其它项目组中抽调精兵良将外带外招，形成了一个4人的敏捷开发项目组，开始二次重构。
可以说，这次的重构比之前的坑还大，因为这次是实打实的真正重构。之前是属于半路加入，有些东西是不用动的，现在不行，每个细节都要考虑到，缺一都会导致产品上线后不成熟的回滚，压力可想而知。
同时，还要兼顾老版本的更新、维护和迭代，还要兼顾新入职的研发的培训工作，真的是分身乏术。不过，实属感谢leader，给了充分的弹性时间也给了充分的信任和空间，前期基本没有任何干预，算是十分幸运且值得珍惜的一次机会，堪比于内部创业。
在当下，分模块的重构和迭代还在进行中，也终于可以专注于真正的产品经理的工作了。
还有一个成就，是推动搭建视觉数据化规范，制定核心的量化指标。不再是“瞎子过河，摸黑前进”，逐步将数据化运营，数据决定产品的思路，植入高层，不再是我是老板，说怎样就怎样，是用户说怎样才怎样。
这就是本人的基本历程和经历，接下来将以此为主线进行详尽的梳理和深度的思考。
视觉实属于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企业来说，是付出了很大成本的，也就希望在售卖的时候，客户来承担这个成本。
也就引申出另一个问题，既然要收费，那如何来定价（发散，视觉不存在这个问题，有专门的销售团队，且策略无需产品方干涉）？其实也是重点工作之一，如何去界定产品价值，同时定的价格是你的客户愿意付出的成本，这里面有大量工作可做。难度在于是没有明确的量化指标，是卖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 的产品，99%都只有PC端（钉钉那种的除外），毕竟场景是不同的。不过随着时代的变迁，有一些也必然向着移动端来转型，但是转型之路会非常的坎坷。因为最开始起家的时候就是在做传统软件，那样的技术架构和庞杂的功能，是很难转变为移动化的平台。
▌9. 平台 VS ISV
To C 的产品，可能更偏重于平台，不需要考虑太多ISV（独立软件开发商）的问题，考虑把产品做好，做好之后就会做大，做大之后我其实就变成平台，就可以提供给第三方或者吸纳第三方数据入住。
To B 的产品，最开始就要考虑是不是要做一个ISV的模式，还是要做一个平台级的服务商。如果是做一个平台级的服务商，是否有能力去接入和提供相应的行业标准来让别人接入；若是做ISV的话，应该找准哪个方向的市场来切入，能让公司能够活下去。
分享到这里，也就差不多了，这次是从本质结合这些时间工作进行的思考和梳理，表象的比如交互、页面布局、设计，我也就没怎么去叙述，好多文章都在赘述这些。
上述是近一年多来对业务间核心碰撞出来的思考吧，有说错的地方多多包涵，不懂的地方多多交流。
