像是多年来做企业内部系统的软件开发，最常遇到几个现象就是

交付日期的不稳定性
项目或是软件开发的领域不断切换
项目的复杂度高、异动需求高
以为可以回头重构，但往往没这个命
认为这些需求是需要被验证，但对方认为这就是正式启用
一个Sprint内不会只做一种领域的需求与功能要开发
…
当然还不止以上这些状况，如果对于先求有再求好，这件事情是没有底线的情况，就很容易发现几个状况

产生非常多的技术债
单一系统后期维运成本已经大于能开发新需求(系统)的能量
系统可靠度下降
异动程式的人力与时间成本增加，但价值没有增加
认为是被验证的需求，但却是正式上线的功能，且就这样了…
会造成这种现象，最大一点在于企业内部开发的系统，往往与MVP的软件开发这两者存在一个显著的差异点，那就是MVP的需求与功能开发，是源自于团队内部的发想与创新，然后透过市场进行验证的比例是较高。 (只有少数比例是从外部的需求刺激让团队照本宣科开发)，而企业内部开发大多数是需要依照使用者(用户或是商业行为)提出的需求进行开发(只有少数比例是团队要做创新促使企业转型)。后者其实已经不存在该功能是需要被验证的需求，但是这样是否还是需要做到先求有再求好吗?其实是有需要的，只是这个求有的程度是要有到那个程度。但是可以知道的是绝非像MVP的做法那样。通常透过那样的作法后，后果大概就是有所谓有，但没有后续的好了。或许有人认为是个人或是组织上问题，但现实状况下，往往一个企业内部的软件开发团队，要负责系统(这边是指彼此独立的系统)往往就达到10~20个，且还不一定是相同的领域。