There’s a strong tendency in product management and user experience circles to want to ensure that the product you ship is “perfect” and that it touches every corner case and every single use case that your customers may need elegantly, efficiently, and with no learning curve.

This is an entirely unrealistic expectation.

The fact is, you’re going to miss some things, no matter how hard you try or how much time you take “ensuring” that your product is perfect.  That’s because, even if you involve customers in the development process, even if you iterate repeatedly, and even if you’re the most user-centered team in the world, there’s going to be something you miss, because you’re always operating on incomplete information.

The trick, then, is knowing what risks you’re willing to accept and which you’re not…

Know Your Unknowns

I’ve mentioned this before, but one of the most important things that you can do in order to ensure that you’re avoiding the impossible pursuit of perfection is to understand the things that you don’t know (and likely won’t know) so that you can decide whether you need more research or whether you can accept the risk.  This includes technical limitations or concerns, market pressures, user needs, and pretty much everything that’s subject to a lack of understanding.  Once you have that list, use it like you do your product backlog — prioritize the things that you really do need to know, create a cut line, and abandon all the unknowns that fall below that line.  You have to accept some risk in order to ship product, and the sooner you ship product, the faster you’ll get feedback to understand what you actually did miss — especially the things you didn’t know that you didn’t know.

Accept the Unknown Unknowns

Speaking of those things — don’t waste too much time outside of the things that you know that you don’t know, seeking for new unknowns.  There are things out there that you’ll never find out until your product gets into the hands of real, actual users — corner and edge cases that never come through with testing data, scalability issues related to the most obscure data points, or even full-on use cases that nobody was able to uncover due to a lack of insight or missing a customer segment during development.  This is valuable feedback that you take and iterate on — and these things will never come up through your normal due diligence.  If they did, you’d already have solved for them.  But they didn’t, and they won’t, so budget your research time for finding new unknowns appropriately — and minimally.

Have a “Default Ship” Mentality

Another thing touched on previously, perfection is usually a result of a “don’t ship” default mentality, rather than a “default ship” mentality.  You can always find some reason not to ship your product — there’s a risk of technical failure, there’s a risk of user dissatisfaction, there’s a risk that you’ll be viewed as copying a competitor…ad nauseum.  If you’re looking for these reasons, you’ll find them…I can guarantee it.  And the result will be that your product will linger in the market, in whatever current state it’s in, until you decide that you’ve met your impossible standard of “perfection”.  If you shift your mental model to one where getting product out is just another iteration, another experiment, and that your goal is to gain more knowledge than you had before and to apply that knowledge to the next iteration, you’ll wind up in a far better position in the long run.  Maybe you need to set up a “beta” offering, maybe you need to test your code with a few select (and friendly) customers, or maybe you just need to push it out there in an A/B or opt-out manner.  But get it out there, or your product will absolutely lose its market momentum and be fodder for the next start-up targeting your established beachhead.