外包產品經理,如何提升自己的綜合水平?

14 評論 11361 瀏覽 67 收藏 22 分鐘

在行業內,產品經理在公司分類中,又可分為常規產品經理跟外包產品經理,這兩者的區別是什么?在外包當產品經理與常規公司有什么區別?身處外包公司,如何能夠提升自己的綜合水平?相信很多互聯網從業者或多或少都會有這些疑問,本文作者從自身工作實踐出發,與大家談談外包公司產品經理如何華麗變身。

本文導圖框架:

一、外包公司產品經理的定位

在外包公司,產品經理(PM)往往更偏向于項目經理,由于在一定程度上缺失了部分用戶調研,需求分析的流程(下文會提到),更多的是直接的接觸真實需求(也不一定是真實用戶的需求,可能是甲方大大臆想出來的),從而在甲方大大的“要求”下,完成產品。

而在項目開發的流程當中,由于外包需要的是更多的項目,所以往往會有多個項目交替并行,這也就是說為什么外包產品經理更偏向于項目經理的原因。

“能夠接觸到N多的0-1,但1-N基本是很少能摸到的”

麥肯錫的咨詢師在從來沒有接觸過一個行業的前提下能夠快速了解這個行業然后提出解決方案一樣,外包產品經理包括但不限于用戶端產品經理也應該具備這樣的能力,哪怕沒有相應的行業經驗。

二、外包公司的項目流程

外包公司的項目流程銷售接單→產品經理對接客戶需求→將需求整合成PRD→客戶確認→設計稿階段→開發階段→測試階段→項目驗收上線

常規公司的項目流程項目立項→需求調研→需求評審(產品、設計、開發、測試)→將需求整合成PRD→客戶確認→設計稿階段→開發階段→測試階段→項目驗收上線→產品迭代

阿境整理了一張圖,可以直觀地看出,這兩者之間的差異點。

三、外包公司產品經理的優劣勢分析

1. 優勢

(1)多→接觸更多的項目

在外包公司里面,一個項目的生命周期大致為十幾二十天到數個月不等,平均在兩三個月內完成。

當然,不同的載體及項目難度也影響著項目工期,比如做APP耗時必然大于做小程序,做過H5、小程序、APP的朋友應該都能明白,這邊就不再舉例。

而外包公司的經濟來源大多在于項目收入,大大小小的項目穿插著,特點鮮明:產品周期短(省略了前期需求調研的部分),迭代周期短(往往甲方會找外包團隊做出1.0的版本,短期投入市場,若可行,大部分會組建自己的開發團隊進行后續迭代),部分甲方會選擇繼續跟外包團隊合作繼續2.0的迭代。

所以,在如此快節奏的項目開發下,在外包公司中,作為產品經理/項目經理,能夠接觸到更多的項目,了解更多的產品,大多是從0到1的產品,小部分迭代的產品。

(2)廣→探索更多的行業

在項目多的情況下,基數大的前提,造成了行業廣的結果。

在常規公司當中,若公司是電商行業,那么該產品經理接觸的,基本也是局限于電商行業,對于其他行業,平時若沒有機會的話,那么基礎的機會就會少很多(排除自身接私單的情況)。

通常外包公司本身會有幾個市面上比較熱火的行業案例,如當下熱門的電商行業、醫療行業、新零售行業等,由于市場的驅動,造成了部分行業的興起。

那么,在每一年,不出意外的話,都會有不同行業的項目。

(3)知→了解更多的業務

接觸的項目及行業多了,自然,業務模式也會更加的了解。

雖說萬物皆類象,但不同的行業造成其不同的業務模式,即使是相同的業務,不同的盈利模式也使得業務的方向有細小的差異。

而產品的規劃設計,其根本都是基于業務流程,分析不同的業務流程,也能夠加深對于不同行業不同業務的理解與認知。

那么,在規劃產品的時候,理解業務的前提下,也能夠更加地貼切。

(4)強→更強大溝通能力跟執行能力

在乙方公司,往往要跟甲方、甲方員工、銷售、設計、開發、測試等多個角色進行溝通。本身產品經理在一個產品的生命周期當中,就需要不斷地與團隊的人去溝通。

那作為乙方的產品經理,更是如此,不僅需要面對自身團隊內的人,還需要與甲方溝通(有時候甲方并不是一個人,而是甲方+甲方團隊),且中間需要與銷售同事做對接。

如此艱辛的環境,也使得乙方產品經理不得不磨礪好自身的溝通能力,外能抵御甲方的神仙需求和奪命連環call,內能應對設計MM開發GG的雙重夾擊,可謂是夾縫中生存,沒有強大的溝通能力,是沒有辦法在這種環境下“存活”下來的。

而執行能力亦同,外包公司的節奏快,項目很多且穿插著來,那么,執行力也是必要的,每天的任務都滿滿當當,一個小細節沒做好,那么后續可能導致的項目延期返工等,都是有可能的。長此以往,執行力自然不在話下。

2. 劣勢

(1)淺→項目的研發深度淺

在研發當中,乙方完成的角色通常是0-1的項目,那么,自然會有部分產品是采用MVP方式的產品。

甲方會嘗試用簡單的軟件,快速投入市場進行試錯,若是可行,那么可能就會將項目接回去自己做;若是不可行,那么可能不了了之。

甲方會找外包的原因在于:

  • 低成本快速試錯,驗證項目市場可行性。
  • 內部無研發團隊,需外包團隊配合協助。
  • 已探尋項目的市場可行性,內部研發缺乏經驗,需要外包協助。

那么,不管從哪個角度上來看,項目的研發深度相對來說都是淺顯的,那么,作為乙方產品經理,接觸到的,都是冰山一角,往往在冰山底部的更多的奧秘,都是沒辦法去體驗及鉆研的。這就需要身處外包的產品同學私下自身不斷去做功課,挖掘冰山下的產品知識點。

(2)少→對用戶了解少

在甲方尋找到外包之前,就已經做好了“需求調研”及“產品定位”(也可能是甲方大大自身的想法)

作為一個產品人都明白,一款好的產品,往往在其方案誕生之前,前面的需求調研,分析,篩選,確定MVP方案,需求優先級,迭代計劃等等都缺失參與,而這些前期準備也可能是決定產品是否能獲得成功的決定性因素。

而在甲方見到你之前,就已經完成了這部分,那么,沒辦法接觸到真實的用戶,自然而言,對用戶的了解也就少。

而我們知道,對于C端產品,最重要的便是用戶;對于B端產品,則真實的使用者也是重要的一個角色。

(3)差→對數據分析能力差

作為乙方產品經理,產品是從0-1居多,從1-N的極少(MVP產品若是成功,那么基本大部分客戶會拿回去自己組建團隊開發)。

那么,能夠接觸到的用戶數據,產品數據并不多,對于數據分析的能力,自然也是相對來說差了一些。

(4)弱→創新能力較弱

當一個人習慣了不用去探索用戶需求,就能夠接觸到真實的項目需求的時候,自然就會產生惰性。

長此以往,對于產品的Sense自然會變得弱一些。

用“溫水煮青蛙”來形容,再貼切不過。

習慣了循規蹈矩,對于甲方需求的提出全盤接收,那么,互聯網時代的變化瞬息萬變,在創新方面,也沒辦法時刻的跟進最新產品的動態,若沒有自身調整,因環境而影響,創新能力也會變得較弱。

四、如何在外包公司獲得常規公司同等歷練

1. 進行需求分析→多問為什么

甲方大大拿著功能清單過來,指著某軟件,“照著這個給我做一個?!?/p>

那么,有的PM很“乖”地照做,項目最終也能如期交差,還很開心,又完成了一個項目。

殊不知,已然喪失了原本PM這個崗位的核心。

同時,甲方大大拿過來的功能清單,往往功能冗雜,且摻雜一些在1.0時期不必要的功能。由于部分客觀原因(公司項目指標要求、甲方個人意愿等),勸說甲方更改功能的可能性微乎其微。

那么,在這個階段,作為PM,我們能夠做什么呢?

深入地走入甲方的需求中心,了解清楚為什么做這個項目,滿足的用戶群體是誰,核心的需求及后續資源如何調配,1.0版本出來了想要如何運營,是否有版本迭代的概念及相應的規劃……

因為即使照著功能清單里的功能來做,不透徹了解需求的情況下,作為PM也只會是照搬照抄,“沒有理解,抄不到精髓”

在很多時候,甲方大大自己帶來的功能清單,十有八九摻雜著不合理的需求或者是不必要的需求;

根據KANO模型(如下圖)來分析,往往很多甲方提出的都是無差異需求,期望型需求相對來說較少,同時,在不了解產品規劃的情況下,偶爾也會提出一些反向需求(如上述的例子)。

那么,這個時候,作為一名合格的PM,并不是一昧地迎合甲方,而是應該通過自身的履歷及經驗,來做合適的引導及分析,深刻挖掘客戶的每一個需求的來源。

按照需求的作用大小來分類,阿境將甲方需求歸納為四種

  1. 真實型需求。通過團隊內,實踐得來或真實調研來的需求,只缺開發團隊完成即可。
  2. 抄襲型需求。某競品有這個功能,那么我也照著來一套(實際上可能并不符合自身項目)。
  3. 臆想型需求。憑空想象,無任何依據,也不管實現起來對自身是否有利,主觀性強。
  4. 無用型需求。對于目前階段并無任何作用,卻堅持在這一版中實現。

既然沒辦法接觸到真正的用戶,那么,也可將能面對的甲方當成一個“用戶群”的集合,

能夠挖掘的需求就進行合理的分析并排期,不能夠挖掘的需求,通過其余途徑(論壇發帖,真實用戶訪談等)來進行探索。

雖然在快節奏的項目規劃當中,會費點時間,但是有思考有深究的一個項目,遠比得上四五個無腦式的方案,至此,也不至于淪為“作圖小弟”。

很多甲方也希望自身的項目能夠被規劃被建議(畢竟大部分人還是相信專業的人士),而一般PM提出的問題,也是基于項目能夠合理的規劃設計來提出的。

基本上都能夠得到合適的回答,關鍵在于,PM愿不愿意花這么點時間來邁出這一步。

(1)為什么要做這個項目?

每個項目的最終需求是獲利,那么,在這當中還有很長的一段路要走。

產品的核心,在于滿足____用戶的____需求,以此為基點,再通過產品本身的定位,闡述做這款產品的目的。……

(2)產品盈利點是什么?

“不談盈利的產品都是耍流氓”

產品的功能,都是為以后的盈利點服務,通過____的途徑,幫助公司實現_____,可大可小。

了解清楚產品的盈利點,也能夠更加的明確,該如何規劃設計才能夠抓住用戶的痛點,而不是一昧地堆砌功能。

(3)公司架構及主要業務流程是什么?是否有足夠的能資源及能力來保持產品的后續支持?

往往在不了解公司架構的時候,直接設計,那么相應的業務流程看似走得通,但實際運營起來,處處碰壁,這邊走不通,那邊缺漏,返工在所難免。

而了解對方的公司架構,則能夠保證軟件在后續的實際運營當中,能夠實現資源利用最大化,為產品的后續運營考慮,也是作為一個PM的重要職責。

舉個例子,規劃商品分類這么一個小功能,甲方想要做三級分類,一問為什么,回答是市面上都是三級。然而了解公司產品情況,并非有那么多的資源及渠道,這個時候如果還是設計成三級,無疑是增加用戶的點擊成本。

諸如此類的例子在實際的規劃當中多如牛毛,用戶體驗差的結果最終只會導致用戶流失,甚至可能鑄就了這個產品的失敗。

2. 增強數據分析能力→多回訪,獲取項目數據

通常在乙方公司,產品上線了之后,基本運營都在于甲方手中,那么,除了多次迭代的情況,不然PM是接觸不到產品的運營數據的。

這個時候,可通過向甲方提出要一些數據來對自己產品的分析,包括用戶人數、付費量、訂單量、頁面轉化率、日PV、UV等,因為產品當初是自己規劃的,那么在哪些部分做了數據埋點,自身自然也清楚。

一些敏感數據(例如銷售金額,訂單毛利等)可能暫時沒辦法接觸得到,但是通過對于用戶體量、平臺日活及平臺盈利點的結合分析,也大概能夠知曉一二。

獲取途徑的方式也很多:H5可通過第三方統計(百度統計)來獲取頁面的數據,小程序可通過小程序數據助手來獲取,APP可根據數據埋點來進行抓取想要的數據。

這些都是PM觸手可及的,同時,根據數據的分析,為甲方提供后續迭代的建議,甲方大大們也是樂意的,畢竟,誰會拒絕來自產品規劃者對于后續產品如何發展的分析及建議呢?

3. 不斷復盤→總結項目的成功/失敗原因

在乙方的PM接觸那么多項目,成功的項目例子存在,失敗的項目也不少,那么,最重要的,便是進行復盤分析。

一個項目成功與否的因素很多,在于市場需求是否足夠了解,在于產品規劃是否得當,在于前期獲客是否精準,在于運營方案是否合理……

成功的原因千奇百怪,失敗的原因卻往往大同小異。

因素很多,雖然產品規劃只是項目的其中一個點,但是,我們仍然可以保持我們的“發問精神”,活動推廣不好,是否是相關功能的頁面層級過深?轉化率過低,是規劃過重還是運營不當?等等。

能夠經歷更多的項目,見證更多項目的成功與失敗,也是乙方PM的優勢之一,再通過自身對于各行業的思考探索,也能獲得更多的經驗。

4. 提升個人行業認知→跳出舒適圈

乙方PM接觸的項目來自各行各業,各種類型的都有,且應該都是當前較為火熱的項目(不火熱,也沒人會投資開發)。

例如前幾年的電商行業,近兩年的K12教育行業及短視頻行業等,都贏得眾多甲方的青睞(什么火做什么,什么可能賺錢做什么)。

那么,這與處于單一行業的PM經歷不同,處于單一行業的PM,可能兩三年內都在研究自身行業的產品,會更加了解及精通。

那么,對于乙方PM來說,只能在有限的項目時間內,多花幾倍的時間,去鉆研這個行業的性質及了解業務流程,產品才能夠被合理的規劃出來。

這也要求乙方的PM,若想提升自身對于不同行業的認知,那么,跳出舒適圈(僅僅“把項目當成項目來做,而不是產品”的想法)很重要,盡管并不那么的容易。

寫在文末

在現在的互聯網行業當中,大家對于外包產品經理褒貶不一。但身處產品崗,也應以客觀的態度去看待問題,其優劣各半,阿境亦接觸過不少外包的產品小伙伴,抱怨項目多,機會少,缺失部分產品環節等問題。

然而,不管是在外包公司還是在常規公司,做的順不順暢,從來都不是公司性質的問題,將目標聚焦于自身的問題才是根本。

在外包公司抓住了機會,找準了方向,同樣是能夠使得自己得到鍛煉,通過上述分析,換個角度思考并努力(缺少了行動的思考毫無意義),同樣能夠獲得更好的產品體驗也能夠使得崗位上的缺點在一定程度上也能轉變為優點。

“打不倒你的,往往能夠使你變得更強”,外包公司的產品經理,經歷了越多,應該是越挫越勇,在荊棘當中,突出重圍。(朋友們,隨阿境喝下這碗雞湯哈哈哈哈)

Tomorrow will be ok,you will be strong.

 

作者:阿境,熱愛產品的凡夫俗子。野蠻生長,產品汪一枚,做過電商、醫療、教育行業項目,有百萬級流水產品經驗。公眾號:夢想家阿境

本文由@阿境 原創發布于人人都是產品經理,未經作者許可,禁止轉載。

題圖來自Unsplash,基于CC0協議

更多精彩內容,請關注人人都是產品經理微信公眾號或下載App
評論
評論請登錄
  1. 感同身受哈哈,做了14個月外包PM,馬上就走人了。兒太多,話語權沒有還要擔責任,不伺候咯~

    來自香港 回復
  2. 分析得很到位,在外包和非外包公司都做過,深有體會!

    回復
  3. 對于博主來說,這種外包型產品經理崗位可做嗎?目前在找工作有點迷

    來自福建 回復
    1. 短期可以,但是長期發展來看,不大合適。
      可以關注公眾號,有部分文章有分析

      來自福建 回復
  4. 想要學習K12方面的產品流程和業務邏輯~不知道您公眾號有沒有這方面的資訊呢

    來自廣東 回復
  5. 做了三年外包pm,文章有內味兒了哈哈哈。需求調研、產品定位、數據分析這些太短板了。

    來自四川 回復
  6. 為什么我看不到文章里的字???

    回復
  7. 目前在外包做產助,受益良多

    回復
    1. 有需要可以多交流哈

      來自福建 回復
  8. 好文章

    回復
    1. 感謝認可 ??

      來自福建 回復
  9. 常規公司的項目流程項目立項→需求調研→需求評審(產品、設計、開發、測試)→將需求整合成PRD→客戶確認→設計稿階段→開發階段→測試階段→項目驗收上線→產品迭代
    —— 這個流程似乎有點歧義吧?有設計開發測試參與的評審應該是到了“怎么做”的環節了,但是這個流程“需求評審”似乎是在討論“是否要做”,或許是每個公司不一樣?

    來自廣東 回復
    1. 這邊的話其實還漏掉了一個,在PRD之后二次需求評審。
      這二者其實都可以,評審前置跟評審后置,具體依公司流程來定哈。

      感謝指正~

      來自福建 回復
  10. 公眾號:夢想家阿境

    來自福建 回復