IT行业最常见的玩笑之一就是产品和开发之间的相爱相杀了。在很多公司两者似乎成了“仇家”，从一定程度上也说明了产品和开发之间确实有不少矛盾。主要体现在如下几个方面：
工期问题
经常出现的是说产品突然某个时候出现，通知开发要在某个时间点之前完成某项Feature，然后开发就暴走了。在一个Scrum团队里面不会出现这种突然袭击的意外。团队关于在某个Sprint（冲刺）里面做什么，在Sprint plan meeting上已经充分沟通并确定了，这个内容在本次冲刺内是不能修改的。如果有新的东西要做，对不起你等下个冲刺再安排。
至于在一个Sprint里面做哪些，这也不是由产品来指定的。产品只负责按照优先级（从产品角度）从大到小列出一系列Features，每列一条Feature，都由开发对Feature进行分解并评估任务耗时。每个Sprint时间是固定的，人员也是固定的，那么可用的工时也是固定的。当工时用完，会议就停止。
关于工时的估计，实际上没有哪个公司能100%的使用。比如每个程序员每周工作时间是5*8=40小时，但实际上我们是按照12小时来计算，你每看错，是30%的生产率。实际上我们总结在这个生产率上，是可以保证时间和质量的。当然具体团队具体分析，生产率多少要经过几次尝试后才能确定。
需求变更问题
需求不可避免会发生变更，Scrum要求是拥抱变化。毕竟，首要目的是开发用户需要的东西，而不是遵循以前的计划开发一个用户不需要的东西。不过如果发生较大变更，产品需要接受某个冲刺任务不能完成的情况，不能发生了变化，计划还维持不变，这不科学。如果产品不能接受这点，Team是有权否决变更的。从产品角度，做出用户需要的东西，比按时完成计划更为重要。
开发出来的东西和产品要求大相径庭
在Scrum中，产品需要和开发坐在一起，经常探讨开发中的细节。没有人能在一开始就想好所有细节，产品也不能，开发不能指望产品丢过来一个完整的Spec然后按部就班地做。产品开发中充满谈判和讨论，大家目的都一样：做出用户需要的东西。在这个过程中，开发每完成一个Feature，产品就可以立即进行验收测试，如果有问题立即进行改动，保证做出来的东西，符合产品的期望。这样不会到了冲刺末期，产品突然跳出来说开发做的东西不是他想要的。