產品核心功能沒問題但還有不少bug體驗較差，此時產品是否該上線？

取決于你這個產品的特點。

如果是要搶占市場，產品重點在功能或創新而不是體驗，那就可以先上線搶用戶，在后來的迭代中慢慢提升體驗，這種情況可以維護一批忠實的用戶，可以說是在“與用戶一起成長”，還可以造成一定的門檻。

如果要搶別人的市場，市場上已有此類可以替代的產品，產品重點在體驗或服務，那就不能上線，否則給一部分嘗鮮的用戶留下了不好的印象，就算以后體驗上來了，別人也不愿意重新下載給你一次改過的機會了。

要看是什么性質的bug

如果僅僅是不影響使用，但影響體驗的，我覺得還好

畢竟你的核心功能在那里呢

搶占市場也好，給公司或投資方交代也好，都是看產品是否能夠先行上線，有些bug是可以無視的

即使想騰旭阿里這樣的企業，QQ或淘寶剛上線的階段不也是體驗差的一塌糊涂嗎，當然，年代也不太相同了哈

核心功能一定不要太多BUG，哪怕功能簡單都好，就像微信最開始推出來只有搖一搖跟附近的人一樣。

我不清楚題主所說的體驗有多差，除非體驗差到流程無法走下去了。一般來說，只要不影響主業務的流程，是可以上線的。?

要明白一點就是，BUG是改不完的，只要按照“測試-上線-再測試-回饋bug修改上傳--更新---再測試”，都會有新的BUG出來，所以不要指望BUG能全部修復好。那么該怎么辦？

看看需求文檔，給bug定優先級嘛。

如果是主功能都跑得通，用戶能夠完整的走完業務的話，就說明系統是沒有大問題的。那么，這個時候就要根據有的bug，進行優先級的排序，將bug按照可能影響主流程分為0、1、2、3級，然后先把優先級靠前的先處理掉，其他相對不那么重要的可以適當延后。這里，測試人員的工作就至關重要了，有關兼容性問題，樣式沖突問題等等迭代的問題需要多測試幾次，做好記錄，并再從服務器上更新。

補充一點，用戶不關心你這個bug是怎樣的，怎么引起的，處理起來多復雜，是否處理好了會造成其他的沖突等等，他們只關心能不能用。所以，一切都以不會影響客戶的業務流程為基點。?

PS：當bug的問題已經不再影響使用的時候，產品經理最好要讓架構師和比較牛逼的開發們一起優化一下代碼，以免再發生同樣的事情。很多bug出現大多數是應為開發的時候編寫了一些不必要的代碼，或者部分代碼的書寫不規范才會導致很多bug的出現，所以優化代碼是十分必要的。 ? ?