在做G端产品的时候，产品经理或多或少会遇到一些其他类型产品遇不到的问题。作者以其所设计的产品为例，总结个人在设计治理监管类产品中的一些经验和要点，希望对你有所启发。
社区作者思睿在《G端业务产品介绍》一文中将G端产品分为以下三类：
（图片来源：《G端业务产品介绍》作者：思睿）
我个人比较赞同这个分类，并且想总结一下目前个人在设计治理监管类产品中的一些经验和要点，也希望能和有类似产品经历的同伴做个交流。
首先介绍一下，我们设计的产品是一个能耗双控及双碳监管平台，0-1，面向区县级政府客户，重点监管辖区内工业企业的耗能及碳排放。
做这个产品的时候，面临的难点主要有两个：
说一下我个人的解决方法：
一是了解大量相关的政策和行业标准。尤其是对这种监管类产品，地方实行或试行的考核办法、地方政府网站上每年披露的相关数据指标等等，都可能成为设计中的重点关注。
二是在功能/流程/目标方面，寻找相似产品进行迁移。例如我们要做一个政府给企业下发能耗指标和碳配额的功能，我参考了财务系统中的预算管理模块，最终我们设计了用能预算模块；例如我们政府能源监管平台找不到公开竞品，但是可以寻找一些企业及园区能源管理平台。
我觉得这个过程很有意思，透过现象看本质，抛去填充的血肉（内容），在骨骼结构上是相似的，也就是功能/流程/目标。
众所周知，G端产品用户分两类，一是决策人/购买者/领导，二是业务工作人员。前者一般关注可视化大屏，后者直接使用后台业务系统。因此两类用户两类产品的设计要点是不同的。
先说说可视化大屏。
首先，我们的大屏以宣传展示为主要定位。大家知道在这样的产品中讲故事是一种重要需求。我将故事的结构总结为以下三点，由此形成一个闭环。
以我们的能耗双控及双碳监管平台大屏为例：
在这个项目的设计初期，我犯的错误是只看到了“现在”（看了其他一些案例也有这个问题）。后来团队中经验更丰富的产品告诉我，业绩汇报中还有重要的一点，为了取得这些业绩“我”做出了多少努力（即我总结的“过去”）。
当然我们会发现，有时候“过去”与“现在”的边界是模糊的，比如新能源的建设本身也可以视为现在获得的政绩，不要扣字眼，只需要设计的时候有这个意识：想想过去做出的努力。
此外，我们的产品实际上聚焦于能碳大数据，我们的大老板及产研主管对此做出的指示是同样的：不能只做数据统计，一定要对数据进行分析，将数据转换为用户可用的结论、决策依据（即我总结的“未来”）。
可能在以前这种“未来”还偏向于画大饼讲故事，但是近年大环境不好，财政没钱，政府客户也越来越看重实际价值。这点对产品研发也提出了新的挑战，产品经理需要对G端业务有更深的理解，可能还需要数据分析和算法工程师等的介入。
这里顺便再和大家分享一点，以前我以为大屏的页数最多也就三四五页，多了就不叫大屏了。后来团队里另一位产品告诉我，他们之前做一个市级项目，大屏页数曾高达二十几页。如果是核心领导，往往关注前面的政绩和亮点展示，如果是具体的业务领导，会再往后看看监管和控制手段的体现。
大屏的取数一般在业务系统，由于某些需要，有时候一些自动生成或采集的数据也会留一个手动修改的口子，这里不再展开。
要和大家分享的是，在跟进开发的过程中，我发现由于开发们的务实思维，往往会觉得某些功能是不必要的，产品需要额外告知开发：政府向上级汇报、宣传展示业绩是有这种需求的，对G端产品来说，讲故事是一种优先级很高的需求。
业务工作人员一般使用后台业务系统。他们虽然在产品购买上往往没有决策权，但却是产品的直接使用者。
我们做G端的产品，尤其是面向区县级用户的，在功能交互上越简单越好。我之前在实习的时候有一次深刻的感悟，哪怕把所有的可选项都平铺开，也尽量不要放在下拉列表里通过点击一次后展开列表。
对于区县级用户，能让用户看见的信息就不要藏起来，能不让用户操作就不让他们操作。信息层级越少越好，最好只有一层。
其实就我们同事的经验反馈，G端用户对业务系统也会有“好看”的需求，当然这个需求往往来源于决策人/购买者/领导。团队里的设计曾说过他们之前做UI设计，客户领导就站在他们身后直接说怎么改。并且客户也会在审美上和设计师产生差异。
最后和大家分享一个小小的雷点，我们这个产品成功了吗？确实签订了几家区县级客户，但是在回款上遇到了比较大的阻碍。大环境不好，地方财政没钱，我们一个单子的合同金额又比较大。
或许就像我们大老板说的那样，对于G端产品来说，首要因素是资源，次要因素是政策，然后才轮得到产品本身。
我的本篇经验均来自于一个产品项目，可能不一定具有很强的普适性。大家还是要辩证地看待。
那么，下一篇再见啦。
本文由 @工凡 原创发布于人人都是产品经理。未经许可，禁止转载
题图来自Unsplash，基于CC0协议
该文观点仅代表作者本人，人人都是产品经理平台仅提供信息存储空间服务。
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。