在討論軟體開發時，有一種尷尬的情況是「在聚焦需求時開始討論實作細節」、「該討論如何實作時卻發現需求還沒釐清完」。前者會讓非技術背景的夥伴被晾在一邊不知如何是好，後者會導致討論中斷、或是可能就會有自認為需求是什麼擅自決定的情況。

身為程式設計師的職業病就在於討論需求時，很容易不小心和其他程式設計師一起討論起如何實作以及實作細節，然後導致某項需求花了太多時間，拖長整個釐清需求的時程。而在討論需求時，通常會有其他非技術背景的夥伴參與，若是他們遇到這類情境，通常會導致他們覺得參與這項討論或會議是浪費自己的時間，因為裡面有很大比例時間中展開的對話是他們聽不懂的。

在討論需求時，應該著重在釐清需求、可行性與準確但不用太精準的成本估算。這部分可以把標準放在當有夥伴聽不懂當前對話時，就是討論太過細節的情況，這時候身為技術人員就要有意識的切回正題。需求的討論應該著重在之前所講的〈暸解目的去實作，而不是暸解要去實作什麼〉、〈確認好要驗收的項目與規格的滿足條件〉。

如果專案管理工具是可以在項目中設置子項目的，例如 Asana 的 Subtask，也會建議在原本的項目裡專注在需求的討論，並把要做的事情或是技術相關的細節討論另外開子項目去討論，方便聚焦；或是透過項目之間的相依關係去管理，讓需求項目相依於實作項目。例如我們可以在原本的項目裡專注討論、確認驗收需求，以及目前這個需求進度如何，然後是否可以驗收了。然後在子項目裡建立要做的事情，或是希望討論的實作細節等等。形式上可能還有其他做法，但是把兩者的討論空間分離出來是有助於聚焦的。