研發産品經理的價值思考-上

一般來說，網際網路公司都是隻有一種産品經理，但是不同的套路來了，某電商巨頭所屬的物流公司的産品經理有兩個細分，一個叫業務産品經理，一個叫研發産品經理；

一直困惑産品分為業務産品（出brd）和研發産品(出prd)是出于什麼考量。作為研發的産品經理，在違和的微妙感持續飄來飄去之餘，夾在兩撥人之間的抱怨那是常态，這倆波職能分别是業務産品以及研發工程師（限前後端）；

困惑的背後其實是在思考職能拆分之後的研發産品經理的核心價值在哪裡。向左看：客戶資源掌握在業務産品手上，可以拿使用者需求+訂單壓brd&排期；向右看：生産力掌握在研發手裡，在需求排排站的情況下，不接需求的套路可以有千千萬（加之軟體開發的價值多為隐性知識，讓其顯性化是主要的溝通成本，在此之外，工程師是否願意将認知顯性化也是個前提，萬一還是個專利嘞？）；那麼問題來了？你夾在中間的研發産品是幹嘛的？

帶着疑問去觀察，随着工作任務的來臨，沖突也逐漸透露出來：

業務産品提出的需求通常有這麼幾類，有更偏向于一句話需求的，也就是期望大而全同時還有點那麼的模糊；也有雪花般零散的小需求，一會來一個，一會再來一個；規劃嗎，别問，問的話很可能是在探索中；（然後一去查招人要求，要能提供某行業全鍊路方案，也就是傳說中的面試造/設計火箭來了）；

單一業務産品描述的需求/方法論有問題麼？并沒有突出的問題，甚至不時還有些創新的驚喜，因為客戶/業務職能方确實也是會用相似的語言描述需求以及期待/相似的套路。

沖突：但是當多個業務需求提來類似産品功能需求的時候就會産生問題：因為不同人對相同的問題有不同的解決方案，加之對同一個産品會有不同的功能期待以及子產品劃分的設計；

這就好比每個人都懷着對耶路撒冷的美好想像去到那裡，結果看到的是一個興旺過，重建過，摧毀過多次的，不斷變化的耶路撒冷，進而産生失望；但同時每個人都保留着對中心耶路撒冷所理想樣子的權利，并且時不時冒出來争取落地；（筆者為了思考這個問題還特意去買了一本【耶路撒冷三千年】）

到了研發側，一方面是工程師對落地産品方案要求細緻+具體，用以判斷同研發能力是否比對，另一方面是大多數研發工程師隻負責自己那一部分，當跨的子產品多的時候則要麼要求産品經理之間協調，要麼依靠項目經理協調推進；

沖突：這中間産品落地方案不合适就會遭到研發同僚吐槽；除此之外做出來的東西還很有可能不是業務&使用者可以認可的，因為人家心中的耶路撒冷又變了；

打個比方，就好比有資源的老闆想開個新飯店，在還沒有規範的菜單的情況下，招聘了客戶經理（業務産品）去轉化客戶，進而獲得預約吃飯的訂單，再招你（研發産品）負責某幾個包廂/大廳，你從客戶經理那裡了解到客人說人家要海鮮，肉，素菜，水果；你就跑到廚房問各個現在或者未來一段時間将會空出時間來的大廚，問他們可以燒什麼，結合當時/近期有什麼食材，再回報給客戶經理推薦魚香肉絲，清真魚，水果拼盤；讓其同客人溝通，看看客人是否滿意，不滿意再重複推薦&後廚确認；如此反複；

這期間可能出現幾個包廂的預約客戶同時叫你推薦菜品，背景師傅&食材資源沖突，供貨的菜場今天沒蔥了，以及使用者來了以後要求改菜，一會鹽放多了使用者不滿意等等需要協調的問題，需要你協調；

問題到此結束了嘛？并麼有，客人可能取消預約，也可能因為等太久菜沒出來，走了；也有可能是使用者吃習慣了隔壁飯店的口味到你這就是吃不順；當然，即使使用者吃完了你也不好判斷使用者到底滿不滿意，隻能觀察使用者還來不來再吃；

随着時間的推移，順利的話，摸索出了幾個菜單，也摸出了不同使用者在包廂和大廳吃飯的不同偏好，然後就是考慮量産以及利潤的問題；再根據回報不斷疊代菜單；

另外處理以上問題的同時還需要兼顧了解隔壁飯店客流量，以及其有無新品問世受到客戶歡迎；

（我想了一下，有這能力咋不去印度街邊擺攤賣飛餅呢？）

這麼一想：至此職能上劃分業務産品和研發産品的主要原因出來了：

一方面是業務産品通常将精力放在滿足使用者需求的解決方案上，同時就沒有更多的精力通過對接到研發工程師的顆粒度上去推進産品開發落地，直接溝通很可能會出現一方以為一句話能說清楚的事情，另一方靈魂題問3k+，進而産生許多不必要摩擦；

另一方面是從解決方案可以非常的多樣化，到産品設計子產品化以及相對通用化還是需要一個轉化與沉澱；

也正因為關注點以及思維習慣&角度的不同，不經轉化的推進會産生兩邊的抱怨（客戶經理想的是這單能不能成，以及以後能不能重複的成，大廚還以為你是拿訂單來激将出人家祖傳秘方），才導緻了研發産品經理這個職能的誕生；如果業務産品或者研發工程師任何一方停止抱怨的話，研發産品經理也就失業了；

備注：随着時間的推移，逐漸根據觀察以及他人給予的回報，從身邊所接觸到的實操提煉出一個解決思路架構（也就說很可能推進的時候是無意識的，但是就是已經這麼發生了，而且經過觀察還是可以在一定時間内緩和業務需求以及研發節奏的方法）。

這個思路就是：拿前端換後端的時間，也就是可見不等于可得；

說人話就是：表裡一套，‘背’裡一套。

即表面的一套用于快速在前端給業務方一個交代：可感覺的輸入，輸出，以及操作/樣式，以及配置；

‘背’裡的一套使用者無感覺，用于同研發溝通實作産品處理邏輯，不同研發工程師的分工協作，以友善研發工程師進行技術方案設計以及技術選型疊代。（後續細聊）