一年级的PM们关注点主要集中在交互+新功能，偏前端，喜酷炫。这是入门必经的阶段。
更高级别的PM关注信息元素、信息架构和产品功能流程，还有，技术架构。
这里的技术架构并不是指产品经理要了解后端用什么语言和框架？代码稳健性如何？而是指——
考虑产品功能时，资深的产品能预见功能如何进化，从而反推当前的技术架构要有怎样的延展性从而cover产品的演进。
对于晋级中的产品经理来说，总得备几副良药，今天我们要说说这里面的大招之一，不要写死。
踩过坑的人都知道，不要写死，是解救线上BUG的大招，更是配置动态化的良药。
至于为什么不要写死，是因为：
第一，没有不会改的功能，迭代是永恒的话题。
第二，没有无bug的产品，哪怕测试100%通过，也不能保证线上不会引入新bug。bug是永恒存在的。
配置动态化，也是移动开发中的重要议题。尤其对于大型的APP，写死的代价是坑爹的，坑到产品都填不满。
我们来看一下常见的配置化大致有哪些类型。
第一，文字的动态配置。
道理很简单，你总不能为了改几个文字等到下一次发版吧？
第二，颜色的个性定制。
和文字异曲同工，配合运营和业务的需求，颜色灵活配置，想怎么换就怎么换好了。
第三，模块的灵活调整。
模块怎么定义，要看你负责的产品或者频道或者功能如何划分层次，如果频道以楼层为组织形式，你需要将楼层顺序做成配置化，方便产品验证怎么放置楼层的效果最好，诸如此类。这里要看具体的情况。
想象你的产品是乐高积木，乐高的哲学就是，统一最小模块的自由组合。
第四，功能的开闭自如。
这可是关键时刻能救命的设置。永远不要觉得测试没有测出bug线上就会运行自如了，要留一手。尤其是对于新增的有待检验的功能，在服务端做成开关。
第五，内容的无缝更新。
比较合理的服务端和客户端的分工是，客户端负责搭建架构，服务端负责数据\内容的下发和控制，客户端的架构是产品的框架，框架相对是稳定的，除非产品经理本身对产品的把握还不准，后端负责的是填充这个框架的所有元素，所有内容。 内容和元素是随时可变的，尤其是要考虑到能否平滑上线无缝更新或者修复。
以上是基于实际的产品经验总结的不要写死的几个层面。不具有任何权威性，切忌生搬硬造，具体的场景和产品要具体的分拆。
想了解更多关于配置动态化的技术细节，推荐移动开发的这篇文章http://mp.weixin.qq.com/s/S1qlT2_8HxDtIUDuUqYBtQ，偏技术。
