IT行業最常見的玩笑之一就是產品和開發之間的相愛相殺了。在很多公司兩者似乎成了“仇家”，從一定程度上也說明了產品和開發之間確實有不少矛盾。主要體現在如下幾個方面：
工期問題
經常出現的是說產品突然某個時候出現，通知開發要在某個時間點之前完成某項Feature，然後開發就暴走了。在一個Scrum團隊裏面不會出現這種突然襲擊的意外。團隊關於在某個Sprint（衝刺）裏面做什麼，在Sprint plan meeting上已經充分溝通並確定了，這個內容在本次衝刺內是不能修改的。如果有新的東西要做，對不起你等下個衝刺再安排。
至於在一個Sprint裏面做哪些，這也不是由產品來指定的。產品只負責按照優先級（從產品角度）從大到小列出一系列Features，每列一條Feature，都由開發對Feature進行分解並評估任務耗時。每個Sprint時間是固定的，人員也是固定的，那麼可用的工時也是固定的。當工時用完，會議就停止。
關於工時的估計，實際上沒有哪個公司能100%的使用。比如每個程序員每週工作時間是5*8=40小時，但實際上我們是按照12小時來計算，你每看錯，是30%的生產率。實際上我們總結在這個生產率上，是可以保證時間和質量的。當然具體團隊具體分析，生產率多少要經過幾次嘗試後才能確定。
需求變更問題
需求不可避免會發生變更，Scrum要求是擁抱變化。畢竟，首要目的是開發用戶需要的東西，而不是遵循以前的計劃開發一個用戶不需要的東西。不過如果發生較大變更，產品需要接受某個衝刺任務不能完成的情況，不能發生了變化，計劃還維持不變，這不科學。如果產品不能接受這點，Team是有權否決變更的。從產品角度，做出用戶需要的東西，比按時完成計劃更爲重要。
開發出來的東西和產品要求大相徑庭
在Scrum中，產品需要和開發坐在一起，經常探討開發中的細節。沒有人能在一開始就想好所有細節，產品也不能，開發不能指望產品丟過來一個完整的Spec然後按部就班地做。產品開發中充滿談判和討論，大家目的都一樣：做出用戶需要的東西。在這個過程中，開發每完成一個Feature，產品就可以立即進行驗收測試，如果有問題立即進行改動，保證做出來的東西，符合產品的期望。這樣不會到了衝刺末期，產品突然跳出來說開發做的東西不是他想要的。