静待风雨后

如果你不够小心的话，发布时也可能会遭遇新的问题。功能发布会衍生出新的功能需求。用户可能会说：「嗯，这个不错，但是我们反馈了很久的其他需求呢？」此外，所有人都会被新功能吸引注意，也就意味着会有突发的 bug 以及改进建议涌入。

如果你提供的功能改变了当前的工作流程，反馈可能会格外强烈。甚至纯粹的视觉调整有时也可能会带来激烈的反馈。一部分用户甚至可能怒斥：「你毁了它，把它改回来。」

面对这种情况，保持冷静并克制住潜意识的反应是至关重要的。我们应当给它几天时间，让它慢慢消失。你务必要坚定立场，铭记你做出这个调整的初衷以及这个调整的目标群体。

无债一身轻

当大量反馈涌入时，要克制自己不去做出改变是很难的，但是你要记住：这些反馈只是一些原始的想法。对它们最好的处理方式是一个委婉的「不」。「不」并不会阻止你继续思考它们背后的场景，甚至在以后将它们加入到塑造阶段。但是说「好的」则会限制你的开发自由，就像欠债一样。

一定要记住，你刚刚发布的内容源于一个价值六周的赌注。如果产品的这部分内容需要投入更多时间，那么就需要重新下注。让这些需求、 bug 同赌局中的其他内容进行竞争来确保它们具有足够的战略价值。

完成了发布后的我们又回到了原点。刚从用户反馈中得到的原始想法还不能着手实施。它们还需要进行塑造。它们也正是我们在塑造的第一步「设定界限」中提到的的原始输入。

如果一个需求确实很重要，你可以将它设定为下个周期的塑造轨道中最高优先级事项。但是在准备塑造想法的这段时间中，先给开发组下注一些其他内容去做。然后，当这个循环周期结束后，你可以将其加入到赌局中进行竞争，并为其定制出成功率最高的塑造版本。