初次接手传说中的to G项目，当时的我天真的以为，toG项目只是toB项目的一种特殊情况，做起来必定得心应手，然而事实却给我浇了一盆冷水。那么To G项目到底是怎么一回事呢？
一、转型
2018年开始，随着工作内容重心转移，我开始从C端产品经理逐步转向B端产品经理，商业战略思维，流程化设计思维曾一度让我“头秃”，转型的过程是痛苦的，也是收益匪浅的。
有一句话叫位置决定想法！在我从C端转向B端的时候，我深深的感受到了这句话的深层意义。
当我是一个C端产品经理时，很多思维都很容易被C端思维局限住，焦点都在用户增长，用户体验和用户交互上，而当我开始成为一个B端产品经理，我渐渐发现：
好看的数据饼图，比起能让财务能够直观看到数字的表格，根本不值一提；
HR宁愿自己手动收集每个月的绩效Excel文件，也不使用OA或钉钉，因为系统中死板的表格无法支持老板多变的考核要求。
对于B端用户来说，降本提效是永恒的主题，想让B端用户花钱，先看到效果！
在我之前的产品生涯中，我没有想过会有一天接触To G的项目。而在2020年的开端，我接手公司对外合作的政府项目，也是传说中的to G项目，当时的我天真的以为，toG项目只是toB项目的一种特殊情况，做起来必定得心应手，然而事实却给我浇了一盆冷水。
二、To G项目的特点
1. 用户基数极大
数字化时代的到来，推动着政府部门也不断进行改革创新，也许因为预算或考核工作的考虑，你很少会看见一个县区进行互联网工具招标，所以To G产品面向的用户人群一般都是市，甚至是省以上的人员基数。
根据2018年的人口普查数据：有16个地市的人口超过了1000万人；287个地市的人口超过了100万。
当然仅从人口基数的角度上来看产品的用户量并不准确，毕竟还存在着无法使用网络的人群，但是随着城市建设，使用人数的上涨是必然的。
也许你会说，自己的产品被越多的人使用，越能感受到成就感，可你想过当一条通知下发，20万，甚至是200万人同时上线操作，你的系统是否能够支撑住呢？
高并发造成内存溢出/数据库死锁，这种情况在接手项目不到两个星期我就遇到了，当时的经历可谓之惊险万分。
不要说这是技术考虑的范畴，这是你作为产品经理在产品设计中需要考虑的问题。
2. 用户画像不明确
无论是做To C业务，还是To B业务，精细化运营都是在产品成熟期要做好的关键事情。会使用你的产品的人都一定带有某种特点，你可以通过他提供多样化的服务来进行满足他的需求。
即使是重流程化设计的toB项目，通过公司类型或者使用者的职务特点，也能够以增值服务的方式成为精细化运营的突破口。例如：为人事部门提供招聘效果可视化数据/满意度调研/绩效考核工具等等。
而to G项目，一般是政府行政工作的线上化，系统的重点在于正确完成行政工作的全流程。看起来和to B项目很像，但toG项目的用户是谁？市民？基层工作人员？管理人员？领导？
我会告诉你，都是。
而且与B端的设计不同，To G项目无法进行精确的用户画像的构建，同时由于项目的特殊性，To B项目的灵药——增值服务形式并不能在To G项目中实现。
何曾见过在“某市政务服务中心网站”提供“办理证件买一送一”？（开个玩笑了～）
3. 务必100%
这里的100%可不是用户覆盖100%。
我最近在和业务方开会的时候深刻体会到这个问题，在进行产品功能评审的时候，针对用户唯一的问题，业务方和我们有了歧义：
从互联网产品设计的角度，登录注册采用极简的方式进行处理，采用手机号码作为用户唯一性的判断标准。而业务方却不这么认为，手机号会有换号，丢失等等情况，并不能作为用户唯一的标示，必须结合身份证进行验证，同时，不支持X日内免登录。即通过舍弃用户体验的方式，保证业务数据的准确性。
根据目前的项目经历我整理出了4个100%：
业务流程正确率100%；
数据准确率100%；
数据安全性100%；
业务支撑能力100%。
如果后续有增加，我也会继续总结。
4. 需求有着大量不确定性
通常来讲，To G项目不会直接接触到基层的使用人员，更多的会是上一级的管理人员，由于隔了一层传递，产品经理能够获取到消息就会出现偏差，常常需要从多种方式去获取正确的需求内容，而不是偏听偏信，否则容易在实现时考虑不足，从而出现新的问题。
总结
以上是目前接手To G项目以来整理总结的一些情况，随着项目逐渐上手，下一期可以和大家讲讲To G项目的产品设计要点。
互勉！
题图来自 Unsplash，基于CC0协议