作為高級產品經理,我們到底該做些什么

3 評論 8158 瀏覽 38 收藏 13 分鐘

對于產品經理而言,如何成長為高級產品經理是很多人都會有的疑惑。而本文也針對這一點給出了三點建議,詳情來看正文吧。

產品經理,作為互聯網行業不可或缺的崗位,已經成為企業發展中過程最為重要的角色。對于產品經理來說,從產品助理,到產品經理,再到高級產品經理,這樣的職業路徑已經是眾所周知的了。每一級別的突破都代表了自身的成長。

我們來大體描述一下這幾個級別產品崗位的職責:

  • 產品助理:協助配合產品經理完成一些產品相關零散工作,熟悉工作流程,掌握基本的產品技能。
  • 產品經理:能獨立負責某一產品或項目,有一定的產品經驗和產品專業能力,負責需求分析、產品設計、需求評審、項目跟進、上線跟蹤等工作。

對于這兩個崗位的職責定義,相信大家都不會有太大的異議。但對于高級產品經理則比較模糊了,相信有很多頂著高級產品經理title的產品人都沒有太過清晰的概念。因為原本就沒有教科書式的定義。

最直接的理解,就是高級產品經理工作年限更長,經驗更加豐富,可以負責更為復雜的項目。這點來說并沒有錯,但十分含糊和抽象,經驗怎么算豐富?項目要多復雜?

同樣作為已是多年高級產品經理的我,也經歷過以上的困惑,直到這一年多來深入到更為復雜的項目中去的之后,才感悟到作為高級產品經理所應承擔的職責,以及所需要掌握的能力。

01

確定各系統職責和邊界,規劃可適用于未來業務發展的產品藍圖

在一些中小型公司,產品業務會比較單一,因此在做產品規劃時,更多的是考慮業務產品未來的發展方向,然后排定計劃進行實施。從這個角度來看,產品的規劃是緊跟著業務規劃進行的。

但對于業務多元化,系統繁多且復雜的公司而言,產品本身更需要有獨立性的規劃。

因為在公司的這個發展階段,產品不僅是需要滿足當下的業務需求,更多的是需要滿足未來業務發展的需要。

而產品隨著業務需求的迭代,會變得越來越復雜,甚至是臃腫、混亂。而這樣發展下去,產品的迭代必須會跟不上業務的發展,在這種情況下,產品不但不能助力業務,更多的可能是成為業務發展的阻礙。

而對這樣的問題,則需要在頂層設計上著手。面對眾多的業務、系統,我們需要在整體上梳理業務的定位,業務間的關系以及未來走向。然后對應著系統進行梳理,將我們用于支撐業務發展的C端APP、小程序、中后臺系統等產品進行分層分域,劃定各產品的職責和邊界。通過拆分、整合、調整等方式來優化現有的產品結構。

在這一系列的動作中,可能還需要引入新的產品角色來一同構建我們的產品矩陣。

例如,因系統眾多所產生的數據孤島問題,當前端產品需要調用后端數據進行信息展示時,則需要對后端系統的數據進行整合,當數據量大時則變得非常困難。

在這種情況下,我們可能就需要考慮引入“業務數據中心”這樣的系統,專門用于后端系統的數據整合歸攏,便于前端系統的統一調用。

經過這樣的思考,以解決現有及未來可能出現的問題為著力點,通過拆分、整合、調整、引入等動作一步步地實現產品矩陣的合理化、有效化,最終實現最大化的助力業務的快速發展。

在這樣一個過程中,是由高級產品經理更或者是資深產品經理來扮演著這樣的核心角色,通過對業務發展趨勢的把握、對系統產品的梳理、對系統技術架構的審視,并與技術架構師或技術負責人深入討論后共同完成的,即形成最終的產品藍圖。

確定了最終的產品藍圖后,后續的產品迭代都依據著產品藍圖中各產品的角色定位去做需求承接。在產品發展過程中,我們還需要持續地復盤檢驗這個產品矩陣的合理性和有效性,并作定期討論和調整。以便不斷地適應業務的發展變化,持續優化我們的產品藍圖。

02

熟悉技術實現原理,與架構師/技術負責人討論確定產品方案,確保系統的高可擴展、低耦合

在承接業務需求的時候,很多時候會不可避免地涉及到多個系統的交互,不同的系統還可能是由不同的技術團隊負責,在這種情況下就需要考慮一個合理的對接方案。

作為高級產品經理則需要把控這個過程,提出合理的產品方案繼而推動技術實現。

如何把控?首先需要了解大體的技術實現原理。通過對系統職責的判定確定系統邊界,從而確立需求分割后的各系統歸屬,讓各系統都做著自己的“份內事”,盡量避免越俎代庖。使得后續需求擴展迭代時能合理地推動實施。

在確定各系統所負責的工作后,則需要進一步確定系統的交互及流程。系統間交互盡量做到簡單,盡量避免相互依賴。能用現有接口實現的就不要增加接口交互,能用通用基礎接口實現交互的就盡量使用通用基礎接口。接口字段的交互也要考慮到通用性,避免需求擴展時造成接口的改動。

所有這些約束,都是為了實現系統間的低耦合和高可擴展性。做到這些后,所有的收益都會在后續的需求擴展中得到體現和回報。

在這個過程中,如果這個需求本身由普通產品經理來負責,則高級產品經理需要介入和協助普通產品經理做好這個工作,與架構師或技術負責人一同溝通討論最優的產品方案。把控好產品向更為合理的方向發展,這是高級產品經理的職責所在。

當然,可能有人會覺得這個工作不應該是由技術Leader來負責嗎?其實如果有這樣的一個技術角色來負責這個工作當然更好,但高級產品經理同樣需要參與這個過程,確保與業務需求間的匹配性。但這種場景是理想化的,更為普遍的情況還是只能由高級產品經理來主導和把控這個過程。

03

親自參與1.0的系統的需求工作,搭建準確無誤的產品框架

當我們需要搭建一個新的系統或者進行系統重構時,同樣需要高級產品經理來把控。

因為全新的系統或重構的系統,在1.0的階段,都是在搭建一個合理的產品框架。其產品思路和功能設計則非常關鍵,合理優秀的產品設計,對后續產品的發展和業務需求的支撐會產生積極影響。

例如,對需求的不斷擴張都能得到良好的支持,在技術層面都不需要通過硬編碼或大量的if else來實現業務邏輯。這種情況下,不管是產品迭代還是代碼維護都能實現良好的延續。

有了良好的產品框架,后續的需求迭代工作轉交給其它產品經理時,即便是普通產品經理都能沿著既有的產品設計思路實施功能擴展。使得后續的產品需求工作變得簡單,每一次的版本的迭代都是對產品功能本身的增強而不是重構,最終讓系統研發的成本大大降低。

但如果一開始沒有考慮到后續需求的擴展問題,或者沒有考慮到因外部系統需求擴展所產生的需求對接問題,則在產品設計階段就不會有前瞻性的思考。1.0的產品如果沒有較強的普適性和可擴展性,那對于后續的產品迭代基本上是災難性的,很可能短時間內就需要進行重構。這樣的結果無疑是表明最初的產品設計是失敗的。

對于這樣的項目,經驗較少的普通產品經理基本上是很難做好這項工作的,所以不太可能對他們提出這樣的要求。因此,高級產品經理則需要承擔起這項工作,親自參與產品方案討論、產品設計、需求編寫等一系列的工作。只有這樣才能保證最終的交付物是準確可用的。

一旦完成1.0產品框架的搭建,后續產品的完善性迭代則可以轉交給普通產品經理來負責。因為有了固定的產品框架,后續的版本發展基本上不會脫離這個框架,只要按照既有的設計路徑就可以保證產品整體上的合理性和健壯性。

以上這些便于對于中后臺高級產品經理所要掌握能力和承擔的職責。而對于C端如APP類產品,其所要承擔工作內容會大不一樣,如更為關注用戶增長,用戶數據挖掘等,但最終的邏輯是一樣的,就是承擔難度更高、更為重要的工作職責。

作為產品經理,當我們身處一個小企業,業務單一,業務較為簡單時,很可能涉及不到其中的這些過程。但對于長業務鏈條、系統繁多的企業時(如互聯網金融),一定能深切地感受到這以上的種種場景。

對于擁有復雜業務邏輯及多系統交互的項目,是迫切需要擁有以上技能的高級產品經理來掌控整個項目的走勢的。如果沒有,項目混亂不可避免,即便最后能完成項目上線,但對于后續的業務發展下的需求擴展支持,則會變得非常艱難。在不久的將來,系統重構項目便會被列入計劃。這對于一個業務快速發展的企業而言,這意味的是資源的消耗、高企的成本以及巨大的風險。

這便于高級產品經理的職責,也是高級產品經理的價值。

#專欄作家#

星思維,微信公眾號:成長星思維,人人都是產品經理專欄作家?;钴S于互聯網金融行業的資深產品經理。喜歡思考,總結,輸出。

本文原創發布于人人都是產品經理。未經許可,禁止轉載

題圖來自 Unsplash,基于 CC0 協議

更多精彩內容,請關注人人都是產品經理微信公眾號或下載App
評論
評論請登錄
  1. 想跟著BAT大咖老師學習更多系統高階產品知識嗎?
    在【產品總監修煉之道】,四位來自騰訊、百度的資深總監級導師,將和你面對面分享高階產品必備的系統知識,幫你掌握更加全面的產品專業知識和團隊管理思路……

    想了解更多詳情?立即戳>>http://996.pm/z4bLB
    也快可以聯系KK進行咨詢哦~微信/TEL:13043462422

    PS:除了咨詢問題,還能領取【產品總監課程學習筆記】! ??

    來自廣東 回復
  2. 很好的文章,希望作者能多寫點,學習了

    來自廣東 回復
  3. 對于確認系統邊界和職責,想請教下樓主有沒有什么好的方法或設計原則。

    來自北京 回復