昨天
我们在产品研发中，都会面临需求不停的变换问题，不仅对产品经理、对研发团队也是痛苦的。例如尤其是需求来自老板，需求可能就得马上做优先级最高。并且是all in，能多快就多快，而产品经理要做的是尽快的把需求整理成产品方案，并与开发人员一起协同完成方案完成的时间点，并推动准时上线
当需求面临涉及用户体验端的时候，还需要与UED部门沟通，完成设计时间的沟通与洽谈。
一个产品朋友曾经与我聊过他的案例，他说：“因为所在的项目是处于从0到1的阶段。因此规划中不免是2-3个月的时间。因为是app，甚至是IOS涉及到发版后的审核、账户申请问题，时间可能会更长。”
但当规划落地后，开始进入研发流程如下图，我们开始进行资源的规划。结果老板的优先级最高的需求临时插进来，导致不得不得重新调整规划，将资源focus在新插入的需求中
好一点的情况是我们可以选择复用这样的代码结构，尽可能的仅仅修改前端即可。坏的情况是我们可能全部重新自己写一套是最快的，但我相信常见的是第二种坏情况
最终团队又进入从0到1的阶段，技术团队再次思考评审中、产品再次进入需求调研与产品规划中。如此反复的循环，最终却没有产出，用户量没有增长导致我们不得不反思自己来这家公司是为了梦想，还是为了每个月的工资？
企业在成长中，一定会有一个主核心盈利项目。企业的部门也一样，也有一个主要负责人业务方向。但仅仅是靠某一个业务方向是没办法支撑越来越大的市场需求，所以尝试一些转型甚至是跨界的业务，不同的新业务成了企业不断推进的方向
上面所说的情况就是典型的一些创新性项目、独角兽企业、创业性企业中出现的案例。但你会发现，真正能够在竞争与商业探索流程下来的企业一定是有自己的门槛与技术壁垒。
可能是行业的资源壁垒、也可能是技术壁垒，但只是没有找到一个变现的方式而已。
如果你正在这样的企业，我建议你可以继续尝试，不断与企业成长试错，不仅是可以学到更多的0到1方向，而且是可以知道更多案例与产品策划边界。
当我们正式从1步入到100的时候，我们就开始受到产品在运营侧甚至是合作伙伴下的业务需求。业务需求可以拆解为
需求拆解后，继续做产品策划。但我们怎么去平衡业务的需求优先级呢？我们开发的团队人数可能就只有10个人，还有2个测试。
一次性吃个胖子是肯定不可能的，所以我们才会有一个流程：需求优先级排列
按上面的流程，我们可以快速的归纳需求的重要性、紧急性。当然业务需求关联的业务自身利益，可能是资源问题、也可能是人力。
优先级的评级我之前也分享过一篇
后台产品难点，需求<em>优</em><em>先</em><em>级</em>清理
优先级完成分级后，产品经理进行产品策划后我们即可开始准备开发时间准备、设计时间准备，最终的上线时间。
这个场景是与另外一位产品经理聊的：“我们的老板对用户体验追求很极致，所以才要非常注意前端的体验”
当听到这个话，我首先想难道是老板对前端UE的把握十分主观吗？
比如一个弹窗，如下。我们认为该弹窗可能用红色好一些，但老板认为是黄色好一些。
这样的“老板需求”的确会让产品经理十分抓狂，完全无法独当一面，但这样的解决办法也很简单上线前都和老板check一次。
但当我的产品朋友给的例子是下面，我发现其实这不是老板的主观问题：
领取按钮还应该再大一些，那我认为这样的需求是可观的。是产品经理与设计人员缺乏经验与认知导致的。
这类的老板需求其实不是“不放权”给产品经理，反而是没有认真对待用户路径与主界面设计。
