G端产品看似不复杂实则是异常困难的项目,伴随着需求的频繁变动势必会导致大量的资源成本消耗,G端产品和其他类型的产品完完全全不同,所以想要做好G端产品往往不容易,以下内容希望能够帮助到正在做或者准备做G端产品的小伙伴,能够在迷茫中拨开哪怕一点点的云雾也好。
G端产品是什么,G指的是“Government”,是为G端、包括事业单位开发的产品。严格来讲,G端产品是B端产品(面向企业)的一个分支,他们有很多共性。虽然有很多共通之处,但也有一些特殊性和区别,实际上是无法将G端和B端归属为同一类产品,为了更好的设计出这两类产品,本篇文章会和大家一起“粗浅”的分析一下。
1.真正的使用者不一定是决策者,大部分是具体的执行人员在应用。
B端产品一般在决定是否购买前都是高层在关注或者指派专人来对接,但对接的人大多数情况下不是真正的使用者,因为一般采购软件的一个部门的职责,实际应用的是另一部分人员。
这也是我们在做类似产品的前期调研时需要注意的问题,我们是否了解到了解使用者的需求,我们如何转化决策者和使用者之间需求上的差异,做到千人千面,这也是我们做产品经理的同学每天在苦苦思考的问题。
2.产品主要服务于可以提升效率减少成本的环节中。
服务于G端或企业的软件,大部分要帮助其解决实际问题,对效率、利润产生贡献,通过智能化信息化帮助工作人员在具体的流程环节中提升效率从而达到节约成本和高效产出的目的。
3.注重业务流程和业务场景,做合理且专业的产品。
G端企业类的产品,如果产品经理或者设计师如果不了解实际业务,没能把业务流程梳理清楚,对实际工作场景掌握不足,就不可能产出让客户满意的产品。所以产品的设计者要思考产品需要解决哪些具体场景下的问题、理解整个工作流程、分析客户的需求,才可以做出专业并令客户满意的产品。
4.要兼顾用户体验和业务需求之间的平衡。
2B产品重业务,很多功能需求直接来源于实际业务,就有很多人会感觉用户体验并没有那么重要,实际上并不是这样,试想如此重视业务逻辑的产品如果没有一个可以让用户流畅操作的界面,那将是多么灾难的事情。所以我们要平衡好两者的关系,将细节打磨贯穿到整体产品的设计中,做到逻辑正确、清晰简明、操作顺畅。
以上的总结主要来源于我的工作经验和实际输出,针对代表性的共通点加以阐述,当然还有一些产品共性以及相同的方法论,比如“都是给人用的”这种大家都知道的内容就不详细赘述了。说完相同点,我们在看看他们之间的差异,首先我们从G端端产品说起。
1.产品受政策影响较大,产品功能需要紧贴政策需求。
我们在设计G端产品时,要时刻关注上层相关条文政策,设计提高G端办公效率的软件,必须围绕主轴核心业务来设计,核心业务的依据参考就是相关政策法规,所以产品人员要根据政策来调整自己产品的流程功能。再好的业务功能也不能偏离上层政策。
2.做好主轴流程,严控最终输出结果。
G端项目要把握好产品的主流程,所有功能围绕主流程来实现和延展。虽然说B端产品的功能可以串联整个工作流程,各个应用之间串联并行,但作为G端项目来说,或许并不需要大而全,我们可能最终只会负责整体流程的一部分,这部分相对对立和专注,我们要保证好完成这部分的最终输出,保证输出结果的专业性、规范性、正确性。同时也为数据的下一级流转提供强有力的支持。
3.想好如何将数据转化为知识服务产品提升效率。
我们在设计通用类产品的时候大多数情况下我们更愿意把数据转化成内容来满足c端用户的衣食住行。但在设计g端产品时我们必须更注重的是数据在系统中的流转、沉淀、在回传。要将数据形成知识,将知识转化成辅助工具,提升效率而不是占用时间。所以在设计之初就要不断的在头脑中完善,如何将数据对应到业务需求,将业务如何转化成具体的功能,不断完善产品体系,在脑中形成基于业务的产品架构。把握好自己产品所在场景的业务需求以及该场景下知识辅助可以解决哪些问题,数据沉淀客户帮助客户提升多少效率,这是产品经理要做的重点工作。
4.数据安全很重要,对做好数据的安全性要求更高。
我们做G端系统因为其特殊性,对于数据安全的要求就非常高了。产品设计阶段的数据涉密问题,再到产品之间的数据流转、存储、交换等都需要严格的安全保障。在C端看似非常简单的数据更新云存储,在设计功能的时候就要考虑“线下”流转数据的情况,在没有公共云的情况下如何更新备份数据,是通过内网云来做更新,数据存储在哪里?如果通过线下拷贝数据,那么系统中的相应更新流程如何设计?这些都是摆在产品设计师面前需要仔细思考的。
5.产品的采购依据G端年度预算,具有极强的时效性和周期性。
G端的产品采购都是通过年度预算的方式,所以在做产品时一定要考虑到周期性和实效性,当年的政策影响以及当下的重点事件都会是产品跟进的方向。这时候就要迅速转化成功能到产品设计中来,落实G端需求,尽可能拿到更多的预算。
6.对于驻地和现场的反馈要高度重视。
G端项目非常依赖于驻地的培训和服务,服务做的越好接下来的项目机会就越大,这个很好理解,大家都希望项目流程简单,对于经常在一起合作的厂商,G端一般不太愿意在更换其他厂商了,因为已经“知根知底”合作模式清晰了,这也是一种效率。基于这点作为产品人员对于驻地同事的相关需求和反馈一定要高度重视,他们反馈的大概率是客户真正的需求和反馈,这些建议如果可以及时得到响应,我相信会提高我们的产品在G端内的认可度。同时搜集这些一线反馈对于产品人员分析需求,构建人物模型,搜寻市场机会都有极大帮助。
以上总结并不是完整的方法论体系,可能无法支撑小伙伴全部的工作,希望能够为小伙伴们带来一小部分帮助,希望与小伙伴们共勉,共同进步。
—— 评论区 ——