上一篇说完需求后，感觉有点反常识，和一些理论或者历史经验都不太符合，但事实上最领先的那些产品，基本上需求都是这么来的，虽然反常识，但又不得不承认。今天继续说下第三个很简单的道理，但是还是大多数都做不好的事。

P059：先做产品结构，之后才是功能细节

反过来做的产品经理很多很多，特别是在已有产品上做迭代的时候，我观察基本上90%以上的人都会犯这个错误，我感觉这个错误简直不可理解。当一个成熟产品放在那里的时候，很容易就会用上一篇说到的错误方法收集到许多要迭代的需求，然后大家把它放到一个表里，定时采用所谓的敏捷迭代的方式，去消化掉一批，再兴冲冲地去跟老板们说，看这周我们又解决了很多痛点，表一拉出来很好看，但往细了看，全是功能细节的堆叠。

 

这段文字读起来貌似没有问题，当然是有问题解决问题了，但这个过程中有一个巨大的bug，就是没有做过产品结构这个过程，初代产品设计如果这个人有点专业精神，他即使在做很少的快节奏功能基础上，也能把产品结构规划打造的特别合理。有些结构下可能只有一个功能点，但仍然在那个合理的结构下，从而方便后面的无限拓展。而后面的迭代，如果没有做产品结构这个过程，很容易在一个错误的结构中，不断的更新，导致这个模块结构越来越难以承受之重，最后就是每过个二年来一次产品推翻重构。对，每过2年来次产品重构这事简直也经历过太多了。

 

我想了一个实际产品过程中的例子，我当年做一个产品分支中有一个模块是toB的会员体系，因为当时并不笃定这个方向能否长得很大，所以规划了一个会员体系，但并没有往深了做，只留了一个孤孤单单的人员管理，目的是试产品方向。后来因为各种原因就没在管这条线，等到大概半年后我再看这个产品，发现会员模块和业务模块是深度结合的，甚至是一个模块。于是又不得不重新去做抽离，因为不抽离的话，很难实现一个会员体系多业务应用，也会制约业务模块的拓展。

 

所以我每次看到别人不停的收集市场需求，然后列成一个一个功能点依次实现就很着急，只有把骨架理清楚了，至于上面长的枝枝叶叶，怎么长就显得不重要了，这个道理我觉得是产品入门第一课，也的确许多产品都知道这个道理，但我从来没见他们把它做的很好。我就这么问，做功能点之前看了整个产品架构图了吗？如果没有架构图，你画了架构图了吗？知道各个功能点都应该在哪个模块中长吗？推演过这个模块的拓展空间吗？

P060：功能模块之间是有机联系的关系

单做产品结构，做功能模块还不够，如果这些模块或者这些功能点之间没有联系，就会变的很危险，危险是因为没办法互相促进和协同成长。但很多人又会走极端，会把模块功能点之间做的纵横交叉，导致要更新其中一个东西，往往带出了另外一堆东西，功能怎么也更新不动，更有甚者，达到不太敢动的地步，因为中间的地雷太多，就是所谓的牵一发而动全身，许多人宁愿做一个新的，也不愿改老的东西。

 

如何平衡功能模块之间的有机联系，又不至于太紧密导致互相过度依赖，这是个很有艺术性的产品问题，需要不停地琢磨和推演，不停地把桥梁放上拿下，拿下放上，看看能不能找到中间的那个合理的平衡点。

 

上面说的这两个都是很简单的入门级产品知识，可是实践中全给忘了，只记得挂在自己头上的KPI，实在很难考虑这么多，大不了二年后换家公司，留下一地鸡毛。我隔壁两个友商公司每年裁一波人，然后新一波上位推倒重来，这事我看了三年，第年都发生一次，因为我在这公司就三年，但我觉得以后还会再有，会不停。

 

反倒是这公司五年前的那波产品经理留下了一个极其合理的产品架构，我每次看的时候，都从内心惊叹，这波人怎么会做出这么牛逼的东西，后来一打听，当初是一帮google，腾讯，阿里的高阶产品做的底子，但很不幸地被一帮管理者的自负舍弃了。于是我一边看着二千多人的公司骂着这个东西不行，要重新做一套，一边默认地使用了这套底子二年。重新做的那套，第二年他们又推翻重来，第三年又推翻，而原来那套底子我用了二年后还是因为公司间的切割重组，而不得不新做一套，当然新做的时候，我基本上还是那套模式，只修改了不到三分之一的模块。

 

我举这个例子只是想强调，一个合理的功能模块结构，和有机的联系是多么重要，基本上是以后产品发展的压仓石。

如若不信：我最近去休了个假，然后发现重结构和重细节，很难在一个人身上都具备，一个是要抽离，一个是要沉下去。都具备的话要求有点高，大部分人还是会侧重某一方面，这个要求确实有点高。

如若不信，扫码关注！