G端产品方法论

题记：已然在G端产品线工作了1年多时间，趁着周日夜晚文思泉涌，系统梳理一下近1年的体会感悟。文章架构参考微信背后的产品观。注：只是一家之言，只当做参考。切不可教条主义拿去就用，脱离了语境去谈方法论难免有些教条主义。

1.用户篇

从用户模型看 G端用户包含：政府经办、公司老板、市民用户。

三者的优先级是：直接汇报者（政府经办/公司老板）>  市民用户。

三者的核心诉求分别是政绩、商业化变现、简单好用对自己有价值。

2.需求篇

1）需求来源：政策、公司领导、用户反馈，在回复响应上优先级依次从高到底，实际做产品时需重新划分优先级。

2）大众反馈需求不如挖取用户动机：只有足够的用户动机才会驱动用户行为。此处可参考心理学和经济学（研究稀缺资源配置）。

3.系统篇

1）安全第一。为了足够安全甚至可以放弃用户体验。安全性和用户体验的平衡取决于领导侧的保守程度。eg.电子医保卡展示二维码时无需输入密码，它的前置条件是用户已处于安全环境之下。

2）领导需求都满足，并超出预期。能实现的立刻排期，不能实现的给出预估时间。

3）数据统计要精确且及时。

4.设计篇

1）勿忘产品空状态：文案、图片。

2）不要让用户思考。eg.市管理员在后台管理端使用筛选项，如默认筛选项为市，用户不会筛选到省。

3）字段长度需声明：最大长度、异常折行情况等等。

4）模拟真实数据：低保真原型尽量用真实数据，保障下游UI稿、测试数据尽量偏向真实数据。否则就需要经常拿UI稿或实际界面来P图。注：此处拿到UI原型稿会有利于后期整理界面。

5.沟通篇

1）向上协作：文件审阅不催时间，一般提示请审阅即可。

2）跨部门沟通：注意沟通方式，通过共同利益去驱动。无法达成一致时向上借力，切莫自己苦哈哈。

不要越级、不要越级、不要越级：从效率上来说越级沟通效率最快，但容易损伤同级之间的信任感。正确做法是先同级沟通，无法达成一致时再向上借力。

3）和开发的bug沟通：先检测外部合作商（技术往往层次不齐），再检测内部问题。

4）跨公司沟通：首先声明合作可能为对方带来的价值、然后才是合作的具体事项，最后是下一步各方要做的事（目标、路径、完成时间）

5）其它

线上会议：提前5分钟进会；

系统有问题时的话术：您好，我们这边系统网络出现一些问题，正在排查处理中。请晚些再试。【不要直接就说 网络挂了 类似的话】

会议记录：参会人里行政单位人员排序很重要。

6）讲故事的能力

逐字稿、逐字稿、逐字稿。