初次接手传说中的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项目中实现。
何曾见过在“某市政务服务中心网站”提供“办理证件买一送一”?(开个玩笑了~)
2. 务必100%
这里的100%可不是用户覆盖100%。
我最近在和业务方开会的时候深刻体会到这个问题,在进行产品功能评审的时候,针对用户唯一的问题,业务方和我们有了歧义:
从互联网产品设计的角度,登录注册采用极简的方式进行处理,采用手机号码作为用户唯一性的判断标准。而业务方却不这么认为,手机号会有换号,丢失等等情况,并不能作为用户唯一的标示,必须结合身份证进行验证,同时,不支持X日内免登录。即通过舍弃用户体验的方式,保证业务数据的准确性。
根据目前的项目经历我整理出了4个100%:
- 业务流程正确率100%;
- 数据准确率100%;
- 数据安全性100%;
- 业务支撑能力100%。
如果后续有增加,我也会继续总结。
3. 需求有着大量不确定性
通常来讲,To G项目不会直接接触到基层的使用人员,更多的会是上一级的管理人员,由于隔了一层传递,产品经理能够获取到消息就会出现偏差,常常需要从多种方式去获取正确的需求内容,而不是偏听偏信,否则容易在实现时考虑不足,从而出现新的问题。
总结
以上是目前接手To G项目以来整理总结的一些情况,随着项目逐渐上手,下一期可以和大家讲讲To G项目的产品设计要点。