In the rush to ship your piece of software there is no shortage of opportunities to polish, refine, and smooth over rough edges. And yet, at some point, we must ship. How do we decide which problems to fix and which to save for later?

Here’s how it works: When you’re trying to launch your new software experience, you need to stay focused on your core scenario. Your core scenario is either something entirely new that nobody’s ever done in software (unlikely and scary), or more likely it’s an improvement on a scenario that competitors are already delivering on (badly in your opinion). Their crappy experience is your inspiration. Cool. You carve out a straight line for your users where they can accomplish what they want with beauty and grace using your new product. Love it!

But invariably you will start to invent new problems. You didn’t copy the competition or clone them. You followed your own path. And whether it’s some rough text, a confusing layout, or just a concept that’s misunderstood, you will find new things that need polishing in your experience. Some will jump out immediately as you use the product. But many, in fact — most — will be speculative. You won’t have run into them personally (and by now you’re too close to the product to have great perspective on this anyway), but someone on your team will start a sentence with the words “I worry that…”. Identifying potential problems is certainly a fine discussion to have.

The problem is that there is no shortage of thoughts like that on the part of team members. And just about every issue brought up may in fact be a problem. But it also might not be. And most reliable and efficient way to find out is to ship the product and see what your customers actually have a problem with. You simply can’t know out of the list of 99 problems that you can come up with, which five are the ones customers will actually have issues with. And it’s only once they have issues that you should address the problems. The rest should most likely be ignored (or certainly prioritized “low”).

Is inflicting a product with some unintuitive and difficult points in the experience a “nice” thing to do to your customers? Hmmm… not really. But is never shipping a product because you’re too busy fixing 94 problems that they won’t have an issue with a “nice” thing to do? No. In fact, it’s suicide. Punting an issue you suspect may be a problem for customers on the list of things you’ll address in the next version of your product is scary. The problem sounds real. It sounds like it could be a real issue. And here you are ignoring it! In fact, what you’re doing is sending the list of potential issues to the “jury” — your customer base. Believe me, they’ll let you know, in a hurry, where they’re having issues. And then in that next release you can move quickly to solve those issues.

There are many reasons why 94 of the 99 problems won’t be reported by customers, or detected by analytics. Your speculation was wrong. Or customers use the product differently than you thought. Or some other problem stops them from even getting to that point. Or that part of the product was ill conceived and needs to be scrapped entirely. Whatever the reason, be thankful you didn’t waste time fixing problems that customers didn’t have issues with.

Strangely, customers form impressions of a company not based so much on their first impressions, but on their ongoing interactions with the company and its product. And customers that see a product constantly evolving to address their actual top concerns are customers that fall in love with a product and the company behind it.