本人最初在深圳从事toB SaaS领域的产品工作5年有余，回到成都后阴差阳错的干了3年的toG产品经理，你们知道这3年我是怎么过的吗？这篇文章，我们来看看B端与G端的差异。
首先让我感到变化很大的是“身份变化”，从产品主导者变为需求翻译者。
在toB企业中我们有着自己的主打产品，所以我的职责是把控现有需求、优化历史遗留问题以及对产品未来的发展进行规划，以便于为用户呈现一个完美的产品。同时B端用户反馈的需求/建议往往仅供参考，不一定会进行处理。
在toG企业中都是项目化的，甲方就是亲爹，他们的需求往往是不可抗拒的，即使这个需求不合理，大概率也得照做。因此我的职责转化为了只需要考虑如何最简化、最快速的完成当前需求即可（即不求最好，但求最快），所以在很长一段时间内我很难受。
B端产品的产品生命周期普遍是很长的，这个过程是需要产品经理全程的精心呵护；而G端项目的项目周期通常很短，在项目结束之后基本上不会再进行优化迭代，也就是做完就完了，这对于B端产品经理来说是会有失落感的。
其次是“项目节奏”的变化，在做B端产品时，我们为了某个功能往往会叫上技术负责人、客服代表、销售代表等人员一起开一次或多次会议甚至还需要跟多家客户做需求调研才会进入研发阶段，然后再是测试上线。
而在做G端项目时，需求来的比较突然且时间很紧，往往是今天告诉你需求大概内容，几天后甚至明天就需要功能上线，几乎没有足够的前期产品思考时间和后期功能测试时间。这也是现在市面上大多数G端系统用户体验差的主要原因之一。
对待不确定需求的处理方式也是大大不同，在做B端产品时，我们总会大胆构想小心求证，会小心翼翼的做各种需求验证，如问卷调查、拜访客户、市场分析等，总之会想方设法的在进入研发阶段前就把需求搞明确。
而做G端项目遇到需求不明确时，常规的操作是“先上一版再说”。欸，也就是否管对不对，咱先开发出来再说，不行再改，然后就进入一个恶性循环……
最后还有G端企业的项目组成员较B端企业来说是很不稳定的，项目成员流动过于频繁，导致产研默契难培养；以及在G端企业中不同项目组之间各自为阵很少有沟通，经常会重复造轮子等。
其实作为产品经理无论是从事toB还是toG领域，都是直接对产品和用户负责的人。既然都是产品经理，那么一定会有相同之处，在经过思考之后，我总结了以下3点：
首先是对产品经理的各项能力要求都一致，如产品经理对事物的洞察力和思考能力。
无论是toB还是toG，客户需求往往都是一句话，因此我们需要对客户需求进行深度的剖析，思考客户提出这个需求的目的究竟是需要解决什么样的问题，以及提供对应的最佳解决方案；
还有沟通能力，无论是toB还是toG，产品经理都需要具备良好的沟通能力，因为在我们的日常工作中都是前要对接客户，后要对接研发测试，上要对接各级领导，中间还要对接各职能部门等；
然后还有都需要扎实的产品基本功，如：画原型能力、文档能力、产品规划能力等。
其次无论是toB还是toG，当我们做出来的产品不好用时，用户一样的会骂娘，由此可见在产品设计阶段用户体验是多么重要。
最后是很现实和很直白的一点，都是拿钱做事。同样的拿钱，同样的做事，也许用100%精力和用80%精力做出来的产品/项目都能交付，但我相信用100%精力的人在每月领同样的钱的情况下，一定比用80%精力的人收获更多。因此，我们在对待产品工作时需要更加认真和全心投入，只有这样才是对产品、对用户以及对自己负责。
功能流程和原型设计完成后找甲方进行一次确认，无论是线上还是线下都必须进行一次确认（线下最好打印出流程图及方案文档。如果可以的话，最好让甲方在方案上签个字）。
这个操作的好处有，首先可以让甲方看看整个功能设计方案是否有需要调整之处，以避免功能开发完成后再进行反复调整，所以在时间充裕的情况下，尽可能的提供高保真原型图或UI图，告知甲方你现在看到的内容就是最终开发完成的内容。
通常情况下，在这个环节就可以完善很多功能细节；其次是可以留痕，以避免后期功能上线后引发的扯皮，尤其是当项目存在与第三方角色合作情况下。
都说产品经理是背锅侠，但是不该背的锅该丢就丢。
尤其是当项目的用户群体是面向C端用户时，则在功能更新上线前请尽可能的充分测试，以避免功能出现BUG等导致甲方被投诉。其次，请保证用户体验和UI好看，这是作为产品经理的基础能力，同时也可以改变G端产品页面又丑又难用的刻板印象。
G端项目的需求变动频率往往较大，为了能更好的解决此问题可以从2个维度进行发力。一是产品经理首先需要确保每次的需求变更都能与整体战略相契合，即核心方向不能偏离；二是如果公司有能力的话，可以自建低代码平台来搭建项目（或采购第三方的PaaS平台），只有低代码平台，才能更灵活和更快速的响应需求。
如果不是纯国企，请保持企业健康的现金流。G端项目虽然说不缺钱，但是往往回款周期较长以及回款难等。因此这就需要公司能有一个健康的现金流，否则做着做着就没了。这点虽然和产品经理没什么关系，但也是我在toG公司的一种亲身经历吧……
创造增值服务，促进循环收费。通常情况下，G端都是项目制，即做完项目之后一次性付费。我们可以大胆考虑加入一些增值服务（按年付费之类的）这样就可以促进循环收费。
项目产品化，打全国市场。通常情况下，一个地方政府单位定制研发的系统项目，在其他城市的同一个政府单位往往也是能适用的（除特殊地区外）。政府单位的公务人员每年也会往各个城市去调研学习先进经验，这时如果我们项目产品化，那么就有机会往其他城市推广。其次项目产品化之后可以由纯toG向toB发展，如给审计局研发的与审计相关的业务系统，则在各大国企或集团都能适用（因为底层需求基本相同）；尤其是当B端企业有通过线上渠道向G端部门申报的业务需求时，则更容易通过G端这条线往B端业务进行延伸了。
自上而下的统一归口。原来由各级地方政府自己各做各的业务系统，即同样业务的系统区县级一套，市级一套，省级一套等模式，将转化为由上级统一建设平台为下级单位提供账号或接口的模式（至少从市级开始统筹）。统筹规划的好处有很多，比如，一是更加便民，就像全国住房公积金服务一样；二是避免重复建设浪费资源，同时也响应了为基层减负的号召，避免让基层在多个业务系统中来回录数据；三是搭建城市数据基座，只有业务归口统一，数据才能更加标准化，数据才能得到更好的利用。
数字化转型完成，AI时代开启。从1999年“政府上网年”开始，中国数字政府建设已走过了20多年的发展历程，现已建设的相对完善。但随着如今AI技术的崛起，我相信AI也必将会在G端领域中发挥重大作用。
toB与toG从大环境上来说是存在较大差异的，因为toG是项目制，快速交付为第一优先级，只有快速交付，成本才低，才有可能快速回款；而toB是产品制，产品实用为第一优先级，产品实用包含：满足用户业务、用户体验良好、功能操作简易等，因为只要产品不实用，就不会有用户为之买单。但从产品经理的工作范畴上来说又是大抵相同的，都需要具备扎实的产品基本功、沟通能力、事物洞察力、产品规划能力、学习能力等。
最后，无论是从事toB还是toG或其他领域，唯有热爱产品，方可享受乐趣，唯有热爱行业，方可全心投入，愿与诸位产品人共勉。
本文由 @易小勇 原创发布于人人都是产品经理，未经许可，禁止转载。
题图来自Unsplash，基于 CC0 协议
该文观点仅代表作者本人，人人都是产品经理平台仅提供信息存储空间服务。
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。