在行業內，產品經理在公司分類中，又可分為常規產品經理跟外包產品經理，這兩者的區別是什麼？在外包當產品經理與常規公司有什麼區別？身處外包公司，如何能夠提升自己的綜合水平？
相信很多互聯網從業者或多或少都會有這些疑問，這邊阿境近期與幾個外包小夥伴深入溝通了下，於是乎，便想來談談外包公司產品經理如何華麗變身。
如有不足，望各位大佬批評斧正。
另：附上本文導圖框架，節約時間。若您感興趣，可繼續深入閱讀；若不感興趣，感謝光臨。
一、外包公司產品經理的定位
在外包公司，產品經理（PM）往往更偏向於項目經理，由於在一定程度上缺失了部分用戶調研，需求分析的流程（下文會提到），更多的是直接的接觸真實需求（也不一定是真實用戶的需求，可能是甲方大大臆想出來的），從而在甲方大大的“要求”下，完成產品。
而在項目開發的流程當中，由於外包需要的是更多的項目，所以往往會有多個項目交替並行，這也就是說為什麼外包產品經理更偏向於項目經理的原因。
“能夠接觸到N多的0-1，但1-N基本是很少能摸到的”
麥肯錫的諮詢師在從來沒有接觸過一個行業的前提下能夠快速瞭解這個行業然後提出解決方案一樣，外包產品經理包括但不限於用戶端產品經理也應該具備這樣的能力，哪怕沒有相應的行業經驗。
二、外包公司的項目流程
外包公司的項目流程
銷售接單→產品經理對接客戶需求→將需求整合成PRD→客戶確認→設計稿階段→開發階段→測試階段→項目驗收上線
常規公司的項目流程
項目立項→需求調研→需求評審（產品、設計、開發、測試）→將需求整合成PRD→客戶確認→設計稿階段→開發階段→測試階段→項目驗收上線→產品迭代
阿境整理了一張圖，可以直觀地看出，這兩者之間的差異點。
三、外包公司產品經理的優劣勢分析
（一）優勢
1、多→接觸更多的項目
在外包公司裡面，一個項目的生命週期大致為十幾二十天到數個月不等，平均在兩三個月內完成。
當然，不同的載體及項目難度也影響著項目工期，比如做APP耗時必然大於做小程序，做過H5、小程序、APP的朋友應該都能明白，這邊就不再舉例。
而外包公司的經濟來源大多在於項目收入，大大小小的項目穿插著，特點鮮明：產品週期短（省略了前期需求調研的部分），迭代週期短（往往甲方會找外包團隊做出1.0的版本，短期投入市場，若可行，大部分會組建自己的開發團隊進行後續迭代），部分甲方會選擇繼續跟外包團隊合作繼續2.0的迭代。
所以，在如此快節奏的項目開發下，在外包公司中，作為產品經理/項目經理，能夠接觸到更多的項目，瞭解更多的產品，大多是從0到1的產品，小部分迭代的產品。
2、廣→探索更多的行業
在項目多的情況下，基數大的前提，造成了行業廣的結果。
在常規公司當中，若公司是電商行業，那麼該產品經理接觸的，基本也是侷限於電商行業，對於其他行業，平時若沒有機會的話，那麼基礎的機會就會少很多（排除自身接私單的情況）。
通常外包公司本身會有幾個市面上比較熱火的行業案例，如當下熱門的電商行業、醫療行業、新零售行業等，由於市場的驅動，造成了部分行業的興起。
那麼，在每一年，不出意外的話，都會有不同行業的項目。
3、知→瞭解更多的業務
接觸的項目及行業多了，自然，業務模式也會更加的瞭解。
雖說萬物皆類象，但不同的行業造成其不同的業務模式，即使是相同的業務，不同的盈利模式也使得業務的方向有細小的差異。
而產品的規劃設計，其根本都是基於業務流程，分析不同的業務流程，也能夠加深對於不同行業不同業務的理解與認知。
那麼，在規劃產品的時候，理解業務的前提下，也能夠更加地貼切。
4、強→更強大溝通能力跟執行能力
在乙方公司，往往要跟甲方、甲方員工、銷售、設計、開發、測試等多個角色進行溝通。本身產品經理在一個產品的生命週期當中，就需要不斷地與團隊的人去溝通。
那作為乙方的產品經理，更是如此，不僅需要面對自身團隊內的人，還需要與甲方溝通（有時候甲方並不是一個人，而是甲方+甲方團隊），且中間需要與銷售同事做對接。
如此艱辛的環境，也使得乙方產品經理不得不磨礪好自身的溝通能力，外能抵禦甲方的神仙需求和奪命連環call，內能應對設計MM開發GG的雙重夾擊，可謂是夾縫中生存，沒有強大的溝通能力，是沒有辦法在這種環境下“存活”下來的。
而執行能力亦同，外包公司的節奏快，項目很多且穿插著來，那麼，執行力也是必要的，每天的任務都滿滿當當，一個小細節沒做好，那麼後續可能導致的項目延期返工等，都是有可能的。長此以往，執行力自然不在話下。
（二）劣勢
1、淺→項目的研發深度淺
在研發當中，乙方完成的角色通常是0-1的項目，那麼，自然會有部分產品是採用MVP方式的產品。
甲方會嘗試用簡單的軟件，快速投入市場進行試錯，若是可行，那麼可能就會將項目接回去自己做；若是不可行，那麼可能不了了之。
甲方會找外包的原因在於：
低成本快速試錯，驗證項目市場可行性。
內部無研發團隊，需外包團隊配合協助。
已探尋項目的市場可行性，內部研發缺乏經驗，需要外包協助。
那麼，不管從哪個角度上來看，項目的研發深度相對來說都是淺顯的，那麼，作為乙方產品經理，接觸到的，都是冰山一角，往往在冰山底部的更多的奧秘，都是沒辦法去體驗及鑽研的。這就需要身處外包的產品同學私下自身不斷去做功課，挖掘冰山下的產品知識點。
2、少→對用戶瞭解少
在甲方尋找到外包之前，就已經做好了“需求調研”及“產品定位”（也可能是甲方大大自身的想法）
作為一個產品人都明白，一款好的產品，往往在其方案誕生之前，前面的需求調研，分析，篩選，確定MVP方案，需求優先級，迭代計劃等等都缺失參與，而這些前期準備也可能是決定產品是否能獲得成功的決定性因素。
而在甲方見到你之前，就已經完成了這部分，那麼，沒辦法接觸到真實的用戶，自然而言，對用戶的瞭解也就少。
而我們知道，對於C端產品，最重要的便是用戶；對於B端產品，則真實的使用者也是重要的一個角色。
3、差→對數據分析能力差
作為乙方產品經理，產品是從0-1居多，從1-N的極少（MVP產品若是成功，那麼基本大部分客戶會拿回去自己組建團隊開發）。
那麼，能夠接觸到的用戶數據，產品數據並不多，對於數據分析的能力，自然也是相對來說差了一些。
4、弱→創新能力較弱
當一個人習慣了不用去探索用戶需求，就能夠接觸到真實的項目需求的時候，自然就會產生惰性。
長此以往，對於產品的Sense自然會變得弱一些。
用“溫水煮青蛙”來形容，再貼切不過。
習慣了循規蹈矩，對於甲方需求的提出全盤接收，那麼，互聯網時代的變化瞬息萬變，在創新方面，也沒辦法時刻的跟進最新產品的動態，若沒有自身調整，因環境而影響，創新能力也會變得較弱。
四、如何在外包公司獲得常規公司同等歷練
（一）進行需求分析→多問為什麼
甲方大大拿著功能清單過來，指著某軟件，“照著這個給我做一個。”
那麼，有的PM很“乖”地照做，項目最終也能如期交差，還很開心，又完成了一個項目。
殊不知，已然喪失了原本PM這個崗位的核心。
同時，甲方大大拿過來的功能清單，往往功能冗雜，且摻雜一些在1.0時期不必要的功能。由於部分客觀原因（公司項目指標要求、甲方個人意願等），勸說甲方更改功能的可能性微乎其微。
那麼，在這個階段，作為PM，我們能夠做什麼呢？
深入地走入甲方的需求中心，瞭解清楚為什麼做這個項目，滿足的用戶群體是誰，核心的需求及後續資源如何調配，1.0版本出來了想要如何運營，是否有版本迭代的概念及相應的規劃......
因為即使照著功能清單裡的功能來做，不透徹瞭解需求的情況下，作為PM也只會是照搬照抄，“沒有理解，抄不到精髓”。
在很多時候，甲方大大自己帶來的功能清單，十有八九摻雜著不合理的需求或者是不必要的需求；
根據KANO模型（如下圖）來分析，往往很多甲方提出的都是無差異需求，期望型需求相對來說較少，同時，在不瞭解產品規劃的情況下，偶爾也會提出一些反向需求（如上述的例子）。
那麼，這個時候，作為一名合格的PM，並不是一昧地迎合甲方，而是應該通過自身的履歷及經驗，來做合適的引導及分析，深刻挖掘客戶的每一個需求的來源。
按照需求的作用大小來分類，阿境將甲方需求歸納為四種
真實型需求
通過團隊內，實踐得來或真實調研來的需求，只缺開發團隊完成即可。
抄襲型需求
某競品有這個功能，那麼我也照著來一套（實際上可能並不符合自身項目）。
臆想型需求
憑空想象，無任何依據，也不管實現起來對自身是否有利，主觀性強。
無用型需求
對於目前階段並無任何作用，卻堅持在這一版中實現。
既然沒辦法接觸到真正的用戶，那麼，也可將能面對的甲方當成一個“用戶群”的集合，
能夠挖掘的需求就進行合理的分析並排期，不能夠挖掘的需求，通過其餘途徑（論壇發帖，真實用戶訪談等）來進行探索。
雖然在快節奏的項目規劃當中，會費點時間，但是有思考有深究的一個項目，遠比得上四五個無腦式的方案，至此，也不至於淪為“作圖小弟”。
很多甲方也希望自身的項目能夠被規劃被建議（畢竟大部分人還是相信專業的人士），而一般PM提出的問題，也是基於項目能夠合理的規劃設計來提出的。
基本上都能夠得到合適的回答，關鍵在於，PM願不願意花這麼點時間來邁出這一步。
1、為什麼要做這個項目？
每個項目的最終需求是獲利，那麼，在這當中還有很長的一段路要走。
產品的核心，在於滿足____用戶的____需求，以此為基點，再通過產品本身的定位，闡述做這款產品的目的。......
2、產品盈利點是什麼？
“不談盈利的產品都是耍流氓”
產品的功能，都是為以後的盈利點服務，通過____的途徑，幫助公司實現_____，可大可小。
瞭解清楚產品的盈利點，也能夠更加的明確，該如何規劃設計才能夠抓住用戶的痛點，而不是一昧地堆砌功能。
3、公司架構及主要業務流程是什麼？是否有足夠的能資源及能力來保持產品的後續支持？
往往在不瞭解公司架構的時候，直接設計，那麼相應的業務流程看似走得通，但實際運營起來，處處碰壁，這邊走不通，那邊缺漏，返工在所難免。
而瞭解對方的公司架構，則能夠保證軟件在後續的實際運營當中，能夠實現資源利用最大化，為產品的後續運營考慮，也是作為一個PM的重要職責。
舉個例子，規劃商品分類這麼一個小功能，甲方想要做三級分類，一問為什麼，回答是市面上都是三級。然而瞭解公司產品情況，並非有那麼多的資源及渠道，這個時候如果還是設計成三級，無疑是增加用戶的點擊成本。
諸如此類的例子在實際的規劃當中多如牛毛，用戶體驗差的結果最終只會導致用戶流失，甚至可能鑄就了這個產品的失敗。
（二）增強數據分析能力→多回訪，獲取項目數據
通常在乙方公司，產品上線了之後，基本運營都在於甲方手中，那麼，除了多次迭代的情況，不然PM是接觸不到產品的運營數據的。
這個時候，可通過向甲方提出要一些數據來對自己產品的分析，包括用戶人數、付費量、訂單量、頁面轉化率、日PV、UV等，因為產品當初是自己規劃的，那麼在哪些部分做了數據埋點，自身自然也清楚。
一些敏感數據（例如銷售金額，訂單毛利等）可能暫時沒辦法接觸得到，但是通過對於用戶體量、平臺日活及平臺盈利點的結合分析，也大概能夠知曉一二。
獲取途徑的方式也很多：H5可通過第三方統計（百度統計）來獲取頁面的數據，小程序可通過小程序數據助手來獲取，APP可根據數據埋點來進行抓取想要的數據。
這些都是PM觸手可及的，同時，根據數據的分析，為甲方提供後續迭代的建議，甲方大大們也是樂意的，畢竟，誰會拒絕來自產品規劃者對於後續產品如何發展的分析及建議呢？
（三）不斷覆盤→總結項目的成功/失敗原因
在乙方的PM接觸那麼多項目，成功的項目例子存在，失敗的項目也不少，那麼，最重要的，便是進行復盤分析。
一個項目成功與否的因素很多，在於市場需求是否足夠了解，在於產品規劃是否得當，在於前期獲客是否精準，在於運營方案是否合理......
成功的原因千奇百怪，失敗的原因卻往往大同小異。
因素很多，雖然產品規劃只是項目的其中一個點，但是，我們仍然可以保持我們的“發問精神”，活動推廣不好，是否是相關功能的頁面層級過深？轉化率過低，是規劃過重還是運營不當？等等。
能夠經歷更多的項目，見證更多項目的成功與失敗，也是乙方PM的優勢之一，再通過自身對於各行業的思考探索，也能獲得更多的經驗。
（四）提升個人行業認知→跳出舒適圈
乙方PM接觸的項目來自各行各業，各種類型的都有，且應該都是當前較為火熱的項目（不火熱，也沒人會投資開發）。
例如前幾年的電商行業，近兩年的K12教育行業及短視頻行業等，都贏得眾多甲方的青睞（什麼火做什麼，什麼可能賺錢做什麼）。
那麼，這與處於單一行業的PM經歷不同，處於單一行業的PM，可能兩三年內都在研究自身行業的產品，會更加了解及精通。
那麼，對於乙方PM來說，只能在有限的項目時間內，多花幾倍的時間，去鑽研這個行業的性質及瞭解業務流程，產品才能夠被合理的規劃出來。
這也要求乙方的PM，若想提升自身對於不同行業的認知，那麼，跳出舒適圈（僅僅“把項目當成項目來做，而不是產品”的想法）很重要，儘管並不那麼的容易。
寫在文末
在現在的互聯網行業當中，大家對於外包產品經理褒貶不一。但身處產品崗，也應以客觀的態度去看待問題，其優劣各半，阿境亦接觸過不少外包的產品小夥伴，抱怨項目多，機會少，缺失部分產品環節等問題。
然而，不管是在外包公司還是在常規公司，做的順不順暢，從來都不是公司性質的問題，將目標聚焦於自身的問題才是根本。
在外包公司抓住了機會，找準了方向，同樣是能夠使得自己得到鍛鍊，通過上述分析，換個角度思考並努力（缺少了行動的思考毫無意義），同樣能夠獲得更好的產品體驗也能夠使得崗位上的缺點在一定程度上也能轉變為優點。
“打不倒你的，往往能夠使你變得更強”，外包公司的產品經理，經歷了越多，應該是越挫越勇，在荊棘當中，突出重圍。（朋友們，隨阿境喝下這碗雞湯哈哈哈哈）
Tomorrow will be ok，you will be strong.
作者：阿境，公眾號：夢想家阿境
本文在PMCAFF社區發佈，轉載請註明作者及出處。
