最近看了不少历史纪录片和电视剧，讲诉各个王朝的改朝换代的故事。看着王公将相，个个长袖善舞，颇有种特别的思绪。眼见他高楼起，眼见他宴宾客，眼见他楼塌了，如果把我们产品经理带入进去，会是一个什么样的职位呢？
和大家分享一个平日里的故事。业务部门给我提了一个需求，希望能早日实现，可是身为产品经理必然会仔细考虑一番，发现这其中有很多不完善的地方，也就是我们常常感觉的，业务方提的什么鬼需求，怎么实现？
因此呢，我就给人家再次确定，并给了其他的实现方案。然而，业务方多次强调，这是个老板／用户提到的需求，就是这样子的，叫我千万不要更改。总而言之一句话，你照着做就好了。
可笑的事情来了。当我出完方案，拉着业务方、老板过的时候，发现了这根本不是老板想要的东西，也就是老板传达给业务方，在传达给我的过程中，出现了很大的偏差，所以老板再次强调了关键点，这我才知道怎么做。
更可笑的事情又来了。当这个需求，以及所制定的规则和方案，落地到技术实现的时候，发现老板和业务方想要一个更大的框架，当前的方案根本无法满足。
最终，我陷入两难的地步。满足当前需求和制定产品体系框架。
那么今天，我就来和大家说说这个问题。
产品体系框架是产品经理心里的一杆秤
不管你是负责业务线，还是仅仅的一个小功能，你都得清楚，在这里你可以做什么。因为你不能瞎干、蛮干，否则最终能走向哪里，你肯定是不清楚的。
举个例子：一个月前，领导要我负责CRM系统和BI数据系统两项业务体系的建立。可是对于我来说，一点也不懂。于是乎，我将当前所有相关的需求整理起来，然后分类，规划了4个版本的功能迭代，以此来满足当前各个业务方的需求。
可是，最后在和领导讨论的时候，被BOSS一顿批，核心问题就是，找我来的目的不仅是让功能迭代，而是从根源上讲，要降低企业的开发成本，否则每次都是要推到重做，我需要做的是一套完整的产品体系框架，这个框架是要和延展性的，这样在做功能的时候，才能把对应的业务，加入到对应的模块当中，然后排期实现。
CRM大神“杨堃”整理的体系架构图
从那天起，我忽然间明白了产品体系框架的意义所在。我也忽然清楚了为什么当时产品总监一定要写产品体系框架的PPT，因为这不是白写的，战略意义重大，当你清楚了框架，你就能安排人手去实现。每个业务或是功能做到什么地步，就由下面的人来处理，抓住几个核心的业务，就能保证产品的良性发展。
所以说，产品的框架思维不是一蹴而就的，也不是朝令夕改的。是经过了缜密思维，多次讨论确定的一条线，当全部都完成的时候，那就是业务结束的时候。新的业务是否要在此基础上进行，那就是另一回事了。
这就是产品经理精进的业务化思维，当你负责的产品越大，上面的图就会越大，你的责任也就更加重，这时产品经理前进的必修课。
功能需求是框架体系的一个模块
当我们心中有了明确的产品体系框架时，不管什么业务需求或是功能迭代的需求，我们都可以从容不迫的来看待，加在什么地方，怎么实现，具体的样式如何，这些我们都可以找到特定的位置，然后加以实现。
做了两年的产品，忽然间发现这个理论体系挺值得思考的。最开始野路子，走到哪算到哪，只要把当前的事情做好就可以了，这是我一直坚信不疑的提高方式，所以不断的强化自己的执行力，也不断的思考怎么才能做好，并带动整个团队做的更好。所以，最后在团队管理上、项目管理上、产品执行上投入了自己大量的时间，也获得了相应的提高。
可是，问题来了，自己产品的技能增长的很慢，和产品总监相比，我也不知道缺少了什么。因为每个版本就是从需求池中挑选几个优先级较高的需求，拿出来实现，总觉得少了点什么。
直到最近想清楚的产品体系框架，是我之前更多的拘泥于功能需求，然后是模块，最后是体系，是自下而上的方式。而实际的过程中，更多的要自上而下。
总之就是，自上而下规划，自下而上检查。
好了，今天的分享结束了，欢迎大家前来和我聊天，我愿意给大家无偿解决产品日常问题，请注明来源哦，3q！
