当MIUI每天有十多万用户都在论坛提交需求时，如何排序这些海量需求的优先级?

　　我们内部面对产品需求有长期、中期和短期的定义。长期开发方向雷总每1~2个月会和团队沟通约定，中期和短期基本就是在和用户互动中，碎片化产生，这个过程也会反过来修正我们设定的长期目标。

　　处理碎片化的需求，我们的方法有三个：

　　1.先处理浮出水面的需求。

　　在论坛做恰当的帖子辅助功能，主要帮助用户尽量格式化提交需求，另外在碰到同样需求的时候，能直接跟着表达“我也需要这个功能”。这样，每周下来，你会发现紧急的功能开发需求自然会按热度排到帖子前面。

　　2.第一时间公示需求改进计划。

　　“橙色星期五”的每周更新，论坛会有完整的更新公告帖，列清楚更新了哪些功能，哪些是推荐的。另外对于闪单点的需求讨论，讨论结果往往是投票结果，都会公示在论坛;团队也会定期把未来一个月的更新计划做个说明。

　　3.让团队结构也“碎片化”。

　　就是说2~3人组成一个小组，长期改进一个功能模块。给他们自主权，在和用户交流中，有30%的模块自己就定义开发了。过去也确实出现过，有用户天天围着某个工程师，后来开发了看起来并不是很急需的功能。但我们整个项目都是每周更新，迭代很快，出错了的方案也不要紧，过两周就改对了。

　　做产品，我和团队举例说：就好比一辆车在路上，只要大方向选清楚了，哪怕偶尔偏离路线或偶尔减速都不怕，其实最怕就是经常180度调头并且反复，或者停下来不动了。

　　有些项目不适合立刻对外发布测试，如何找需求反馈?

　　创业起步阶段，怎么有效就怎么来，那就动员内部来测试。小米加步枪干革命，说一个我们“大卖部”的小故事。

　　2010年7月，我们决定自己做电商，4个工程师仅用1个月就开发出电商后台的第一个版本。为了测试，我们在电商平台做了面对内部员工的“1折卖可乐”，这就是我们的“大卖部”。真正的订单，真正的收费，真正的配送签收(我们的工程师都跑去“送货”)，每天进货，每天盘点，这样就提前发现并解决了电商系统的很多问题。等到8月29日系统真正上线时，一切都很顺利。