在产品设计上要注重逻辑的合理性，我曾经做过一个产品，有个功能是分类筛

选，我们根据内容类型把不同的内容进行归类，运营人员可以根据不同的分类筛

选内容，也只能分类查看。这样一来在后续的运营过程中运营人员无法统筹查看

全部的内容，如果想看一下最近更新的内容或者内容总数，只能各个分类查看后 

才知道，很麻烦，还挺考验人的记忆力的。

再举一个例子，我曾经看过一个产品有个业务逻辑，两个管理模块A和B，A模块是

B模块的内容源且有信息的第一管理权。A模块的信息被下架后，B模块也同时下

架，但是后台使用者却可以手动把B模块的信息再上架。这样就不合理了，内容源

中已经没有该信息了，但是B模块却依然显示着。两者有时关联，有时不关联。

其实从技术上来讲，怎么做都可以，完成由人定义。但是如果逻辑上不合理的

话，不仅开发过程中难以沟通，而且运营人员在使用过程中也会觉得很乱。

我之前讲后端产品受使用者干预性比较大，因为本身就是供他们使用的，所以我

们在设计功能的时候也会收集运营人员的需求。在这个过程中有时候运营人员的

需求是合理的，有必要的，但有时候也不合理，纯属那种拍脑门的决定。

这种拍脑门的后果就是对需求的定义随心所欲，造成的结果是功能很多，加大了

开发量，某些比较小的功能即便运营人员让加了，但实际过程中基本不会使用。

所以在这个过程中，产品经理就要控制运营人员的欲望。

逻辑上的合理性，也可以成为产品经理评判某个需求的标准。

之所以要做到灵活性，主要原因有两个，一个是对于运营需求的满足，另一个是

某些功能需求的不确定性。

先说第一点，我原来做个功能当时我们想把游戏官网的设计模块化，这样可以提

高游戏官网上线的速度。虽然从功能的角度来讲可以这么做，但是从设计的角度

来讲并不合适，出于营销的目的官网还需要展现游戏的个性化。所以当时我们做

了样式替换的功能，运营人员如果不想使用模板，可以依靠替换CSS文件来做到官

网的个性化。

有些功能的需求是不确定的。比如说一个电台节目的简介最大字数该限制多少，

说实话有时候我也不知道，运营人员也说不准。如果一旦限制的字符比较短，那

在以后的使用中发现不够用，还得修改。要不就设置的非常长，比如说十万字，

我们能够预想到肯定够用了。但这样就没太大意义。这种时候我觉得可以不做限

制，完全由人为定义就好。

做技术的人流行一种说法，不要写死。保持灵活性，也是为了避免某些地方写死

而给自己造成一些麻烦。

给大家一个建议，因为大家的上班时间是固定的，周一到周五每天八个小时，某

些功能如定时器很大程度上是为了让方便大家在非工作时间管理内容。判定某个

功能如果完全可以在工作时间控制，而且即便发生错误影响也不大，那么就可以

考虑保持其灵活性。

产品经理都会追求好的用户体验，用户体验的优秀很大程度上体验在细节上，可

要知道在追求用户体验这条路上是没有尽头的。其实不仅是前端产品，做后端产

品也要控制自己的欲望。如果对细节要求的太多，磨的太细，恐怕你的产品就永

远不要上线了。

我曾经就经历过这种情况，部门中的一个项目，开发测试完成，由于服务器的原

因耽误了上线时间。在这个过程中产品经理就在逐渐优化细节，按理说也没问

题，但是技术人员对代码的每次改动都意味着增加了一次风险，说不定会引起别

的问题。

除了用户体验外，功能也是如此。有些需求其实运营人员也没有考虑清楚，即便

是提出来了，也是一时兴起，缺乏说服力。如果是这样，在满足基础需求的前提

下，我们不妨暂且把新功能放一放。等最终考虑清楚了再开发，免得做无用功。

相比较前端产品，特别是APP，后端产品有个优势就是技术上的改动随时可以生

效。而不需要用户更新版本，这对产品经理来说是好事，如果出错了补救的成本

小一些。

拿我之前做过一个排序功能来说，如果想调整某个内容的顺序，可以手动输入序

号，序号越大排序越靠前。虽然这样能满足需求，但是随着使用的时间久了，积

累的数据越来越多，出现了一个问题。运营人员在使用过程中并不规范，他们输

入的序号数值很随意，往往会把新增加的信息序号数值设置的很大。一共90条数

据，但序号数值可能已经到了200。序号并没有连着，时间长了列表中的序号就会

非常乱。

所以说功能设计的好坏也跟数据的规模有关，有些功能在数据少的情况下使用没

问题，但是随着数据量增大就会暴露出功能设计上的缺陷。

之前行业内有一种议论说，有些产品经理非常不愿意做后端产品，我在工作经历

也发现，确实存在这种现象，有的产品经理在接后台产品时就是抱着一种应付的

态度。