起點課堂會員權益
職業體系課特權
線下行業大會特權
個人IP打造特權
30+門專項技能課
1300+專題課程
12場職場軟技能直播
12場求職輔導直播
12場專業技能直播
會員專屬社群
榮耀標識To B 產品經理必備能力：斷、舍、離
我剛開始從技術崗位轉向產品崗位的時候，看到產品需求，第一個想法是怎樣做到“高內聚，低耦合”，而不是這個需求到底合不合理，我們這一期的迭代和更新是否需要排期等等。隨著在產品崗位的發展，才逐漸學會怎樣去成為一個合格的產品經理。
前言
我現在服務于一家從事 To B 產品的公司，公司的伙伴在對待客戶的產品需求的時候，存在著比較大的三個問題：
- 一是盲目的聽從客戶的需求，客戶說什么就是什么；
- 二是只注重當前階段的產品設計，而忽略后期的規劃和迭代；
- 三是數據思維不足。
上個月，我參加了一個小型的產品論壇，有一個伙伴提了一個問題，他們是從事一個法律服務的SAAS產品，怎樣去做一個結合上下游產品的標準化產品，又能滿足用戶的各種需求呢，但是當時的會議嘉賓老師的回答，我其實是不太滿意的。所以就有了這篇文章。
一、斷
我先說一下什么是斷，就是判斷、決斷。
這是從產品助理到產品經理轉變必須要的一個能力。我們在接到產品需求的，第一時間應該做什么？這個需求產生的原因是什么，據此我們去判斷這個需求是不是合理的，其次再是我們是不是需要接受這個需求，然后才是去排期和規劃。
舉個例子，我們服務的某個企業，需要在他的微信端 H5 頁面上加一個手機號的輸入功能。我們接到這個需求的時候，第一時間是去找技術部門的伙伴排期？還是這個手機號輸入框該放在那個頁面，手機號是不是要去判斷是不是符合某種驗證規則？我們應該第一時間明白這個客戶為什么要加這樣的功能。
比如：是為了用手機號來保證用戶的唯一性，還是說僅僅只是為了獲取用戶的手機號？
至于具體的解決方法，我們要視實際的情況而定。確定了原因之后，就是發揮我們產品經理能力和職業素養的時候了，我們不僅要去判斷這個需求是否實現，而且要去引導客戶怎樣提供一個好的方案解決他的需求。
我們怎么去判斷一個需求是否合理？
- 第一，這個需求是否在我的產品規劃當中；
- 第二，這個需求是否屬于公司的業務范圍之內；
- 第三，這個需求是否屬于產品缺陷，或者遺漏的產品設計功能點；
- 第四，這個需求對應的產品和功能，基于現有的技術條件能否實現；
- 第五，我有沒有更好的解決方法。
基于上述幾點，我們去判斷這個需求是否合理。
二、舍
“萬物舍此而求生。”——《老子》
我的理解是，在產品需求階段要做一定的取舍，特別是 To B 產品。如果我們不做一個的取舍，不聚焦與產品的核心功能，那么不僅是產品伙伴和技術伙伴，公司整個的業務線都會疲于奔命。
同樣舉個例子，之前我們的伙伴在給一個客戶，設計產品的時候，按照客戶的要求，提供了一個功能場景——用戶掃描二維碼，發起一個提貨的請求操作，當客戶和請求方都確認了操作后，這個流程才算完成。
我當時有一個產品涉及到這樣的場景，我就問這個伙伴，你發起這樣的流程操作，操作雙方是需要面對面么？如果我發起了一個這樣的請求，同時也有這樣的請求達到客戶怎么辦？如果客戶一直沒有同意怎么辦？
我們遇到實際的需求的時候，多想一些場景，多問一些為什么，就能避免產品設計的反復修改，我們才能從容的面對客戶不斷變化的需求、
回到剛剛的例子，實際我跟他溝通之后，我發現，客戶的需求只是需要有一個方便用戶申請和他自己查詢申請，并且自己能夠及時收到申請而已。這里的服務是基于微信端的，大家可以想象我們遇到這樣的場景需要怎樣來解決問題。
同樣回到剛剛產品開始的問題，在做SAAS產品的時候，我們怎樣來提供產品的標準化。
首先，我們要明確一點，我們提供的標準化產品不可能滿足所有的場景、所有的需求，而我們盡量做的就是參考帕累托法則說的，滿足80%場景下的功能，并且在產品初期階段，我們要聚焦一個產品的核心功能上，圍繞核銷點打磨產品。并不是說要完全的舍棄剩下的20%，而是，必要的需求可以后期排期和迭代去實現。
當然，在實際工作中，也有就是我們不得不做的時候，這個大家就都心照不宣。
三、離
這里的離并不是說要離開，很多時候我的朋友說什么《Java從入門到放棄》，并不是這個意思。而是“載離寒暑”中，所表達的經歷的意思。我表達的經歷，一種是自己的體驗，一種是學習。
作為 To B 的產品經理，自己要去多體驗一些競品或者其他行業優秀的作品，增加自己的儲備。我身邊有做App的伙伴，他們公司的產品崗位，入職前2周要求新同事每天至少體驗10款以上的App。
還有就是學習的經歷，我們要去不斷學習。我對身邊的產品崗位和技術崗位的朋友說，對于新技術我們不說要去處在前沿的位置，只是不能在落后于大趨勢。
從機器學習和深度學習開始成為業內的熱點之后，我也去學了些關于機器學習的常用算法，比如keras框架，TensorFlow框架，關于SVM，一級CART等。
當然作為產品不要求我們能夠寫一手漂亮的代碼，而是基于當前的技術，我們能夠給我們的客戶提供怎樣的服務，并且后期我們的產品規劃和設計應該有一個怎樣的方向去發展。
今天的這篇文章，文字部分比較多，后期的文章會結合產品的實例和代碼的具體實現上，與大家分享。如果大家有問題，可以在下方評論區留言，部分問題我會在下篇文章中解答。
本文由 @John_Ren 原創發布于人人都是產品經理。未經許可，禁止轉載
題圖來自 Unsplash ，基于 CC0 協議
從19年開始準備個人進一步學習的事情，所以停筆了很久，預計從6月開始繼續開始寫作了。
可以的，歡迎轉載和交流。
圍繞核心去加肉
這次給自己挖了一個坑。后續的文章會集中在一個點上去做闡述的。
形象
你說的這些還僅僅是產品基礎實現層面的，要從更高層面上理解斷舍離，是從整個商業模式上，然后才是產品模型。
謝謝