2011年應該是互聯網井噴的一年，各大書店的暢銷排行榜，從各領域的人物傳記逐漸被互聯網、用戶體驗等字眼代替。相信很多人都看過蘇杰那本人人都是產品經理這本書，可能是這個”人人都是“讓后來產品經理一度成為了互聯網次代名詞。這個職位以無門檻、無專業限制、熱門行業、高薪等標簽，并能因自己改了小小的element就能直接影響億萬用戶的體驗，這種所謂的成就感，讓無數小白趨之若鶩。當然，我不否認，那時我也是。

不過應該慶幸的是，在14年我選擇了最熱門且最有爭議的一個行業—“互聯網+金融”；更慶幸的是，團隊是在一個成熟公司框架下的內部創業，意味著你有很優質的資源背景，且你是一個要具備多種螺絲型號的“螺絲刀” ，而不是一個螺絲釘；最慶幸的是，我有一個十分信任我的boss。這三點是直到目前最能說服我自己不后悔放棄原有專業知識，甘心選擇一切從零開始。

言歸正傳，目前負責的項目，是我接手的第一個產品，一個小型BI系統，目前已經迭代到第二版，用戶群就是身邊的產品、運營、渠道等相關的同事。最大的好處就是大家都在一個屋檐下，溝通成本比較低；但同樣的，項目啟動的時候我就已經做好了要隨時被批斗的準備。老大們對數據的關注和敏感性都特別高，在產品上線的最初期就籌劃建立了專門的數據團隊，但這個團隊都不是專業的數據分析出身，野路子注定了這不是一條平凡之路。作為最初數據團隊唯二的成員，從最開始的各種零散的數據需求，到現在的基本的BI體系，這期間踩過的坑和當初預想的一樣，多如牛毛；但同樣的，獲得的成長，也是。

tob的pm，除了需要必備的專業技能外，在實際中更多要關注是業務體系，高端一點講是Business Sense；通俗一點呢，就是一句話—“你要比你的用戶還要清楚他們真正想要的是什么” ，這句話是在設計產品的每一環節都要問自己的。這意味著你要深入到各個業務模塊，了解他們最日常的工作，抽絲剝繭出最真實、最高頻、對業務最有有指導性的需求。 我想這就是做tob產品的好處：你會發現很多業務表層之下的東西，知道每一個業務模塊運轉起來的核心要素，找到最能解釋并驅動業務發展的衡量指標。如果真的可以做到上述，應該會比業務人員還要更了解業務的核心。但這就需要極大的快速學習能力、高效的溝通能力、換位思考能力、抽象邏輯能力、洞察力、敏感度、還有持久的耐心。 我想這應該不比toc的產品容易到哪里去。

還是說我自己吧，在項目最初期，了解了目前市場上對app數據監測的比較常用的網站，【友盟_專業的移動開發者服務平臺、 TalkingData-AppAnalytics 、百度統計——最大的中文網站分析平臺 、「我要啦」網站流量統計 、Google Analytics（分析）官方網站 等】 做了一份很詳細的各平臺的分析，熟悉了移動應用大概的數據關注方向，基于app的應用設計我結合了很多上述平臺的指標內容，一是認為這些平臺已經有很成熟化的指標體系，有很強的通用性，也是各app都在關注的；二是我們也接了一些平臺的SDK，自己再做也可以核查第三方統計的數據統計的準確性。但在業務上，考慮到數據的保密性，很少有開源的系統平臺可以直接參考。而且不同的商業模式下業務體系也不盡相同，沒有一個放之四海而皆準的標準可以一概之，所以在業務層面上就需要依據自身定制化。 而且還要再明確一點，BI系統也不是CMS、CRM系統，它沒有那么強的操作性，它更像是一個展示數據清洗、數據歸類、數據提取再到數據可視化的一個結果，平臺上提供更多的是已經加工處理過，可以驅動決策的各種可視化圖表。那么問題來了，不可能把所有的數據展示在上面，到底要放哪些指標，要用怎么樣的計算邏輯、要展示什么內容？

“要全面了解業務邏輯” 到“感知用戶需求" 這都不是拿個小本本坐下來找業務人員聊聊天喝喝茶就能知道的。這個時候"多型號螺絲刀"的優勢就體現出來了，因為人員有限，在著手設計平臺的業務系統的同時，我也是個分析報告產出機。“運營活動的參與度分享率是多少？哪些因素導致的？ 渠道上哪些數據是有水分的，從哪些角度發現的？交易為什么會在某個時間段集中爆發，背后的用戶心理動機是什么？..... ” 每天都會收到很多涉及多個端口的需求。然后要從海量的數據中整合、歸納、找出原因，反饋到相關的同事，幫助他們優化或解決項目上遇到的困難。慢慢的我也就知道各業務方最常問的問題有哪些，哪些指標對他們是最有價值的，到后來就基本明確了產品方、運營方、渠道方都是怎么流轉的、怎么看數據的。這對我后來設計內容上給予了很大的幫助。

內容有了，但不能胡亂往系統里面塞，信息架構_百度百科【information architecture】在這個時候就是一門極具魔力的學問，我特別佩服那些可以從亂麻一樣的事情中，找到可以摸索的邏輯脈絡，最后把事物深層次的邏輯串聯起來，讓人一目了然的人。相對toc的產品，tob的產品更要挖掘理解深層的本質，這是業務邏輯上最最重要的一項技能。這一點我也在不斷的學習中。在設計過程中，我自己認為這個東西做出來是回答這樣三個狀態的問題 “以前發生了什么和為什么會發生？ 現在正在發生什么和為什么會發生、未來可能發生什么和我們如何應對？” 秉承著這一邏輯我做了幾個版本的組織架構已供選擇。

這個項目1.0版已經很早就實現了，但隨著產品從初創期到成長期，目標和模式也在不斷優化和調整，業務方關注的也在不斷變化，最初版本很多地方已經不能滿足現有需求，作為數據支持方也要“與時俱進，開拓創新”。現在2.0版也具雛形，3月底準備正式上線。 因為是對內產品且要最大化利用資源，項目只有一個pm+一個半開發，實在不忍心讓自己的產品長得太丑... 在做原型的時候我順便也做了產品的UI/UE， “螺絲刀”在不斷解鎖新技能。

總結下來，其實不用太過擔心做tob的產品會丟失一些pm的專業敏感性，每一件事都會有AB面，每一件事情也是不斷的在發生變化，可能因為剛開始工作或者在體系很龐大的組織里，我們沒有太多可以選擇工作內容的機會，“別人安排你做什么你決定不了，但你還能夠做什么，你決定得了。” 我相信題主的產品也是需要不斷推新，需要不斷適應業務的發展軌跡，很多時候當業務發生改變的時候，可以業務人員一起參與討論，去不斷發現新的需求，探尋新的形勢，即便是甲乙方的關系，在不違反相關規則下，也可以給予相關的意見和建議。我想有的時候我們的方向“轉換”是從tob換到toc，其實還有一種“轉換” 是跟著一個項目在不同業務發展階段，不斷發現和定位新的問題，去見證、適應他的革新，這樣真實的了解一個產品的從零開始的生命軌跡，對以后做其他類型的產品的也是有很大的參考價值。