产品核心功能没问题但还有不少bug体验较差，此时产品是否该上线？

取决于你这个产品的特点。

如果是要抢占市场，产品重点在功能或创新而不是体验，那就可以先上线抢用户，在后来的迭代中慢慢提升体验，这种情况可以维护一批忠实的用户，可以说是在“与用户一起成长”，还可以造成一定的门槛。

如果要抢别人的市场，市场上已有此类可以替代的产品，产品重点在体验或服务，那就不能上线，否则给一部分尝鲜的用户留下了不好的印象，就算以后体验上来了，别人也不愿意重新下载给你一次改过的机会了。

要看是什么性质的bug

如果仅仅是不影响使用，但影响体验的，我觉得还好

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

抢占市场也好，给公司或投资方交代也好，都是看产品是否能够先行上线，有些bug是可以无视的

即使想腾旭阿里这样的企业，QQ或淘宝刚上线的阶段不也是体验差的一塌糊涂吗，当然，年代也不太相同了哈

核心功能一定不要太多BUG，哪怕功能简单都好，就像微信最开始推出来只有摇一摇跟附近的人一样。

我不清楚题主所说的体验有多差，除非体验差到流程无法走下去了。一般来说，只要不影响主业务的流程，是可以上线的。 

要明白一点就是，BUG是改不完的，只要按照“测试-上线-再测试-回馈bug修改上传--更新---再测试”，都会有新的BUG出来，所以不要指望BUG能全部修复好。那么该怎么办？

看看需求文档，给bug定优先级嘛。

如果是主功能都跑得通，用户能够完整的走完业务的话，就说明系统是没有大问题的。那么，这个时候就要根据有的bug，进行优先级的排序，将bug按照可能影响主流程分为0、1、2、3级，然后先把优先级靠前的先处理掉，其他相对不那么重要的可以适当延后。这里，测试人员的工作就至关重要了，有关兼容性问题，样式冲突问题等等迭代的问题需要多测试几次，做好记录，并再从服务器上更新。

补充一点，用户不关心你这个bug是怎样的，怎么引起的，处理起来多复杂，是否处理好了会造成其他的冲突等等，他们只关心能不能用。所以，一切都以不会影响客户的业务流程为基点。 

PS：当bug的问题已经不再影响使用的时候，产品经理最好要让架构师和比较牛逼的开发们一起优化一下代码，以免再发生同样的事情。很多bug出现大多数是应为开发的时候编写了一些不必要的代码，或者部分代码的书写不规范才会导致很多bug的出现，所以优化代码是十分必要的。