初次接手傳說中的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協議
本文出自快速备案，转载时请注明出处及相应链接。
