-
1 # 創一代方舟
-
2 # 王澤華Kino
作為有著推翻和被推翻經驗的產品經理,我簡單答一下這個問題。
其實推翻產品,有些時候不是針對前任產品,而是在於說,隨著業務的不斷髮展,無論是個人還是公司還是整個行業,都對於理想的產品形態有了更深和更加準確的認識。
由於歷史原因,老的設計總有一天會落伍,正如偉大如阿里的淘寶,光是關於產品類目的設計,就從一開始的只有前臺類目,到運營需求愈發強烈時終於將類目劃分成了前後臺的雙重類目。所以,當新任產品經理接任產品的時候,總是需要對整體的業務進行全流程的梳理,而這個過程其實就是一次覆盤和重新審視的過程;我們新任的產品經理,站在前人探索的基礎之上,會總結出一些更凝練、更友好或者具有擴建性的方案,而隨著一整個的梳理,這些一個個方案會或多或少發現與現有的架構存在著不相容甚至衝突的情況,而當這些改善足夠好的時候,很有可能,就是我們產品經理要重構產品的時候了。
-
3 # 胡顯峰yinker
然後解釋為什麼要重建?
有兩種情況,第一種,確實產品做的爛,需要整體的從使用者場景需求的角度重新盤點,也就是所謂的產品重構,做這類操作的重點是,找到客觀事實,不要主觀臆斷,任何人都不能代表使用者,另外,一個產品也不能滿足所有使用者,所以找到你產品服務的使用者,和你切入市場的點。
第二種,產品做的還行,非得重架構,只要一個新的產品給你說要重新最佳化下介面,UI太醜,這樣的產品就要不得,屬於不想為前人填坑,1不負責任,2又不懂產品。
產品經理不是代孕媽媽就是後媽,重點是好好養孩子。
再醜的孩子也是你生的,誰說醜孩子不能上清華?
-
4 # 雲產品之道
感覺像是研發提的問題,哈哈
做產品後經歷過幾次大的重構,應該能代表大多數的原因吧。
第一種,介面風格小推翻,一家創業公司,公司由原有的藍白色主調,變更為紅黑色,所以作為公司的一款子產品,需要跟著變更。
第二種,整個系統完全重構,大型傳統公司,公司發展迅速,整個系統還停留在二十年前的系統架構,系統雖然穩定,但是冗餘功能太多,流程老舊。
第三種,整個系統重做,中型公司,公司業務調整,原有系統是創業初期的外包產物,功能邏輯性差,程式碼難以維護,正趕上業務調整,原有架構很難支撐新的業務模式,就在原有系統並行的情況下,重新設計新系統,並逐漸切換到新系統上開展工作。
-
5 # 斷手恐龍哥
產品經理對市場必須高度認知及把控性,嗅到商業氣息就必須快速對市場反應做出評估及策劃方案,在方案實施前必須經過一系列理念推理及預估,在沒有進入市場考研下商品架構,進行多次稽核及修改,沒有終結產品方案,只有不斷創新及修改意見,而推翻整個專案重建,只能說產品經理沒有做好市場調查於分析,做出了一個廢功能產品,不得不重新規劃,看問題看根源
-
6 # SHENYUTING168
不只有產品經理喜歡推翻重建,架構師也喜歡推翻重建,程式設計師也喜歡推翻重寫程式碼等,其實百分之九十以上的原因是人的思維特性決定的,自己設計或者構思永遠比學習理解他人的結果來的簡單。
回覆列表
無論是新上任的產品經理面對上一任產品留下的舊產品,還是因為自己負責的產品出了問題。很多情況下,產品經理不會繼續沿襲上任和前段時間的想法,畢竟我們很想設計出有自己風格和能有海量使用者的產品。
每次推翻重建一個功能,就是對整個產品一次大開刀,PM做了這個艱難的決定,還需要向RD,UI等工種同學解釋清楚原因。所以,我們真心不想推翻產品,但是必須得改啊,哈哈。
根據我目前的工作內容,大體談一下我個人在什麼情況下會推翻重建產品!
產品初版上線後,進行灰度測試,雖然前期經歷了大量的使用者調研競品分析,但只有使用者用了才知道效果,所以進行灰度測試,在小範圍使用者裡看使用情況。如果使用者非常喜歡這個產品功能,並且使用時長相比同類功能更高,且不影響產品的其他功能,綜合考慮後我們就會正式釋出了。但如果我們通過後臺數據和使用者反饋發現,雖然我們對這個個產品這個功能很滿意,但是使用者不滿意,我們只能忍痛pass這個產品了。做產品要有自己的價值觀但是更要更加懂使用者更尊重使用者!
另一個原因,相信很多PM同學都經歷過,轉崗換工作後遇到上一任留下的爛攤子。你是要繼續理解學習這個前任留下的產品理念呢?還是按照自己的思路來呢?這就好比,別人寫了一篇的一半,剩下一半讓你寫。通常在這種情況,想要重建需要和老闆和同事深入交流和辯論,畢竟重建意味著重來,時間和金錢成本很大,最後很可能你想重建,但還是的拿著舊產品補窟窿。