本文主要是介绍产品之 2B、2C与2G，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！
文章目录
- TL;DR
- 1 相同之处
- 2 不同之处
- 3 G 端产品的特点
- 4 政府领导型客户频繁变更需求怎么办？三个步骤解决！
TL;DR
- B2B（business to business，企业对企业）、B2C（business to customer，企业对消费者）、B2H（business to home，企业直接针对社区家庭营销的一种模式）、B2G（business to government 企业对政府的电子商务模式）、C2C（customer to customer消费者对消费者）
- To C面向个人用户；To B面向企业；To G面向政府（使用用户可以为政府决策人员、普通大众、行业用户）
- To C使用场地是随时对地；ToB更多是内网；To G是内外网相结合（互联网+政务）
典型代表
- B2B典型的代表是：阿里巴巴
- B2C典型的代表是：戴尔
- B2H典型的代表是：OKe家、经桥购物网
- B2G：电子报税
- C2C典型的代表是：eBAY、淘宝
1 相同之处
都是为了解决人的需求，都需要去深入挖掘目标用户的需求，进行分析转化为功能，利用最低的成本去满足用户最迫切的需求。
都需要把产品做好，用户用得爽，才能实现盈利。
产品经理都需要具备核心能力（包括：需求分析、产品管理、项目管理、沟通能力、技术能力、业务能力、产品设计、学习能力、逻辑思维等）。
2 不同之处
（1）产品定位：
To C需从产品能给人们解决哪些问题的角度去考虑产品定位；
To B是结合商业公司内部使用需要的层面去考虑；B端产品一定要在企业的利润链上产生价值，对企业的利润产生贡献。对最终的利润正向贡献越大，产品的价值也就越大。
To G则是从国家政策、政府工作报告等体现要做什么样的产品（比如：通过“数字政府”营造粤港澳大湾区营商与政务环境）。产品定位决定了目前用户、场景、需求等一系列维度。
（2）用户定位：To C面向个人用户；To B面向企业；To G面向政府（使用用户可以为政府决策人员、普通大众、行业用户）。
（3）需求场景：To C使用场地是随时对地；ToB更多是内网；To G是内外网相结合（互联网+政务）。
（4）产品模式：商业模式或者市场路线。To C需要进行用户调研寻找细分用户，通过市场调研挖掘本职需求，需要更多地思考产品设计和用户体验层次的问题；To B和To G则需要对客户进行深度沟通，寻找MVP，而且需要一套能说服客户又能寻求利益最大化的定价策略。
（5）用户需求：To C要结合用户的“人性”需要，去挖掘大多数用户的可能性，需要做各种各样的竞品分析（包括同类产品功能层面和不同类产品解决方案）；To B也是找寻大多数企业的共性需求，除非是定制化需求；To G这种则是通过一个个项目形式去满足不同时期政策的需要和符合财政预算，这类需求需要通过政府客户获取。
（6）盈利模式：To C通过内容吸引用户，有了用户流，带动资金流、物流，每个用户都是盈利的来演；To B和To G走的都是项目合同制，可以分为一期、二期和n期，需要不断保持与客户的合作关系，进行迭代规划，才能实现产品的持续变现。
（7）MVP思路不同：
建设B端和C端产品时，大的原则是类似的，都是先做加法，即充分讨论、穷举所有需求和可能性;然后再做减法，选出最核心的需求点;最后设计具体方案并将其落地，用最短的时 间和最低的成本支持业务启动。
但是在选取最小功能集合(或最小可行产品)时，B端和C端产品的区别很大:
B端产品要支持业务整体运作，所以在选取最小功能集合时，即便再简化，也要保证一个核心业务流程的运转，因此B端MVP往往是一个具备一定复杂度的系统，不可能是一个或几个功能点。
C端产品需要解决用户的痛点，需要挑选一个核心痛点去打动用户，如果核心痛点定位错误，就会导致验证失败。所以在选取最小功能集合时，C端产品要聚焦用户的核心痛 点，C端MVP可能只包含一两个功能点。
（8）细节设计不同：
两类产品在细节设计上的关注点可谓完全不同。
B端产品面临复杂的业务场景和用户场景，因此进行细节设计时，必须关注建模、抽 象、角色、权限等问题。
C端产品面临的场景相对单一，并且使用者是相对独立的单个用户，因此不用关心角 色、权限管理，而要关注用户的体验，需要在交互设计上投入很大精力。
a、群体体验VS个体体验
众所周知，C端产品比较注重个体体验。特别是在使用App等C端产品时，我们会发现C端产品会非常偏向于迎合个人爱好，让用户用得更爽。
与之相反，B端产品非常注重群体体验。在使用过程中，B端产品会涉及到多个角色，甚至出现同个时间、同个空间内出现多人使用的现象。
b、用完就走VS流连忘返
绝大多数C端产品都希望用户能够在产品里流连忘返;B端的产品要真正地做到用完即走，是很重要的事情
c、行业规则VS个人喜好
C端产品通常会注重个人喜好，并进行个性化的定制，让我们可以把想用的东西摆上来，例如皮肤、头像都是个人喜好。
对B端产品来说，它会包含行业规则在里面。做某个行业的产品，就需要对行业规则有一定的认识。
（9）服务培训VS好看好用
B端产品的话，要考虑到即使不能去做长期的线下培训；也可以考虑线上的培训能力，比如说提供一些培训的视频操作指引，帮助员工更好地去使用产品。
（10）系统对接VS独立使用
B端产品会更多地关注系统的对接问题。一个企业去用新东西的时候，有时候不一定会直接放弃旧的东西，可能会存在一些并行的时间。
这里出现的问题就是——客户希望旧系统里面的内容是否可以同步到新系统里，减少使用成本与部门压力。
C端的产品因为是个人使用，会比较关注好看、好用，用得舒适。
但对B端产品而言，一个公司在工作场景中会用到很多系统。这些系统都是来自于不同公司的，你很难统一他们的UI层面；而且很多B端产品是相对比较专业的，背后需要一些复杂的设置。
3 G 端产品的特点
- 真正的使用者不一定是决策者，大部分是具体的执行人员在应用
B端产品一般在决定是否购买前都是高层在关注或者指派专人来对接，但对接的人大多数情况下不是真正的使用者，因为一般采购软件的一个部门的职责，实际应用的是另一部分人员。
这也是我们在做类似产品的前期调研时需要注意的问题，我们是否了解到了解使用者的需求，我们如何转化决策者和使用者之间需求上的差异，做到千人千面，这也是我们做产品经理的同学每天在苦苦思考的问题。
- 产品受国家政策影响较大，产品功能需要紧贴政策需求
我们在设计政府产品时，要时刻关注国家相关条文政策，设计提高政府办公效率的软件，必须围绕主轴核心业务来设计；
核心业务的依据参考就是相关政策法规，所以产品人员要根据政策来调整自己产品的流程功能。再好的业务功能也不能偏离国家政策。
- 做好主轴流程，严控最终输出结果
政府项目要把握好产品的主流程，所有功能围绕主流程来实现和延展。
虽然说B端产品的功能可以串联整个工作流程，各个应用之间串联并行，但作为政府项目来说，或许并不需要大而全，我们可能最终只会负责整体流程的一部分；
- 想好如何将数据转化为知识服务产品提升效率
我们在设计通用类产品的时候，大多数情况下我们更愿意把数据转化成内容来满足c端用户的衣食住行。
但在设计g端产品时我们必须更注重的是数据在系统中的流转、沉淀、在回传。要将数据形成知识，将知识转化成辅助工具，提升效率而不是占用时间。
所以在设计之初就要不断的在头脑中完善，如何将数据对应到业务需求，将业务如何转化成具体的功能，不断完善产品体系，在脑中形成基于业务的产品架构。
把握好自己产品所在场景的业务需求以及该场景下知识辅助可以解决哪些问题，数据沉淀客户帮助客户提升多少效率，这是产品经理要做的重点工作。
- 数据安全很重要，对做好数据的安全性要求更高
我们做政府系统因为其特殊性，对于数据安全的要求就非常高了。
产品设计阶段的数据涉密问题，再到产品之间的数据流转、存储、交换等都需要严格的安全保障。
在C端看似非常简单的数据更新云存储，在设计功能的时候就要考虑“线下”流转数据的情况，在没有公共云的情况下如何更新备份数据，是通过内网云来做更新，数据存储在哪里？如果通过线下拷贝数据，那么系统中的相应更新流程如何设计？这些都是摆在产品设计师面前需要仔细思考的。
- 产品的采购依据政府年度预算，具有极强的时效性和周期性
政府的产品采购都是通过年度预算的方式，所以在做产品时一定要考虑到周期性和实效性，当年的政策影响以及当下的重点事件都会是产品跟进的方向。
这时候就要迅速转化成功能到产品设计中来，落实政府需求，尽可能拿到更多的预算。
4 政府领导型客户频繁变更需求怎么办？三个步骤解决！
一、用户的本质需求到底变没变，先把自己的问题排除掉
遇到这样的问题，第一步要做的就是自我检讨，到底用户需求是不是真的变了？
这时我们最容易遇到的一个问题就是没能把握住用户最本质的需求，错把用户的表层需求或者解决方案当成了用户需求。
解决这个问题的最好办法就是why之剑，多问为什么，为什么用户提这个需求，多问几次就能追根溯源到用户最本质的需求，把握本质需求，加上采用高保真原型确认方案，才能尽量减少需求变更。
比如领导提了一个综合展示的需求，可以利用系统数据定期生成图表，展示几个关键业务指标。
领导可能还会要求某个指标应该用折线图或者饼图，这个需求的本质是要通过系统看关键业务指标，具体是用饼图还是柱图展示，是具体的呈现方案；所以应该把需求分析的重点工作放到指标分析上，确保领导提的业务指标都能统计，不能有遗漏。
二、和领导直接沟通需求、确认方案
我们如果有机会和领导直接对话，一定要抓住机会，避免空对空。
第一次沟通，即便我们只知道领导的一个大概想法，我们也应该准备一汇报的材料，把我们对需求的理解、大致的方案思路和待探讨的问题大概写一下，最好是一个PPT，这样沟通的效果会更好。
有了这个PPT的材料，和领导沟通需求就变成了汇报，通过汇报的方式确定需求，也避免了领导提需求过分发散，可以聚焦到PPT的框架内。
把握了领导的业务需求，下一步就是给出解决方案并和领导确认，我建议和领导确认方案最好采用高保真的系统原型。
现在高效的原型设计工具，做出高保真原型的成本很低，采用高保真原型和领导沟通效果会非常好，和领导汇报原型的关键点就是要讲明白你的设计方案，为什么原型要设计成这样？
三、遗留问题统一谈，及时止损
以上步骤都做了，用户的需求还是变来变去，上个星期谈好的需求上线了，下周就说这个功能不需要了，需要变方向，遇到这种领导只能自认倒霉了。
这个时候还有一招，就是要把销售抬出来了，让他找用户去谈，找一些变更费用，弥补一些损失，很多政府的项目每年都有一定费用的成本开支预算，争取一下可能还是会有的。
作者：四姑娘山的稻城
链接：https://www.jianshu.com/p/a0d61812dd7c
来源：简书
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。
这篇关于产品之 2B、2C与2G的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！
