初次接手傳說中的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項目的產品設計要點。
互勉！
本文由 @DHAllison 原創發佈於人人都是產品經理。未經許可，禁止轉載。
題圖來自 Unsplash，基於CC0協議
