產品經理精進之體系思維
最近看了不少歷史紀錄片和電視劇，講訴各個王朝的改朝換代的故事。看著王公將相，個個長袖善舞，頗有種特別的思緒。眼見他高樓起，眼見他宴賓客，眼見他樓塌了，如果把我們產品經理帶入進去，會是一個什麼樣的職位呢？
和大家分享一個平日裡的故事。業務部門給我提了一個需求，希望能早日實現，可是身為產品經理必然會仔細考慮一番，發現這其中有很多不完善的地方，也就是我們常常感覺的，業務方提的什麼鬼需求，怎麼實現？
因此呢，我就給人家再次確定，並給了其他的實現方案。然而，業務方多次強調，這是個老闆／使用者提到的需求，就是這樣子的，叫我千萬不要更改。總而言之一句話，你照著做就好了。
可笑的事情來了。當我出完方案，拉著業務方、老闆過的時候，發現了這根本不是老闆想要的東西，也就是老闆傳達給業務方，在傳達給我的過程中，出現了很大的偏差，所以老闆再次強調了關鍵點，這我才知道怎麼做。
更可笑的事情又來了。當這個需求，以及所制定的規則和方案，落地到技術實現的時候，發現老闆和業務方想要一個更大的框架，當前的方案根本無法滿足。
最終，我陷入兩難的地步。滿足當前需求和制定產品體系框架。
那麼今天，我就來和大家說說這個問題。
產品體系框架是產品經理心裡的一杆秤
不管你是負責業務線，還是僅僅的一個小功能，你都得清楚，在這裡你可以做什麼。因為你不能瞎幹、蠻幹，否則最終能走向哪裡，你肯定是不清楚的。
舉個例子：一個月前，領導要我負責CRM系統和BI資料系統兩項業務體系的建立。可是對於我來說，一點也不懂。於是乎，我將當前所有相關的需求整理起來，然後分類，規劃了4個版本的功能迭代，以此來滿足當前各個業務方的需求。
可是，最後在和領導討論的時候，被BOSS一頓批，核心問題就是，找我來的目的不僅是讓功能迭代，而是從根源上講，要降低企業的開發成本，否則每次都是要推到重做，我需要做的是一套完整的產品體系框架，這個框架是要和延展性的，這樣在做功能的時候，才能把對應的業務，加入到對應的模組當中，然後排期實現。
CRM大神“楊堃”整理的體系架構圖
從那天起，我忽然間明白了產品體系框架的意義所在。我也忽然清楚了為什麼當時產品總監一定要寫產品體系框架的PPT，因為這不是白寫的，戰略意義重大，當你清楚了框架，你就能安排人手去實現。每個業務或是功能做到什麼地步，就由下面的人來處理，抓住幾個核心的業務，就能保證產品的良性發展。
所以說，產品的框架思維不是一蹴而就的，也不是朝令夕改的。是經過了縝密思維，多次討論確定的一條線，當全部都完成的時候，那就是業務結束的時候。新的業務是否要在此基礎上進行，那就是另一回事了。
這就是產品經理精進的業務化思維，當你負責的產品越大，上面的圖就會越大，你的責任也就更加重，這時產品經理前進的必修課。
功能需求是框架體系的一個模組
當我們心中有了明確的產品體系框架時，不管什麼業務需求或是功能迭代的需求，我們都可以從容不迫的來看待，加在什麼地方，怎麼實現，具體的樣式如何，這些我們都可以找到特定的位置，然後加以實現。
做了兩年的產品，忽然間發現這個理論體系挺值得思考的。最開始野路子，走到哪算到哪，只要把當前的事情做好就可以了，這是我一直堅信不疑的提高方式，所以不斷的強化自己的執行力，也不斷的思考怎麼才能做好，並帶動整個團隊做的更好。所以，最後在團隊管理上、專案管理上、產品執行上投入了自己大量的時間，也獲得了相應的提高。
可是，問題來了，自己產品的技能增長的很慢，和產品總監相比，我也不知道缺少了什麼。因為每個版本就是從需求池中挑選幾個優先順序較高的需求，拿出來實現，總覺得少了點什麼。
直到最近想清楚的產品體系框架，是我之前更多的拘泥於功能需求，然後是模組，最後是體系，是自下而上的方式。而實際的過程中，更多的要自上而下。
總之就是，自上而下規劃，自下而上檢查。
好了，今天的分享結束了，歡迎大家前來和我聊天，我願意給大家無償解決產品日常問題，請註明來源哦，3q！