A couple of years ago, I built an online marketplace for musicians. It went so great, it wouldn’t even cover my server costs. Awesomesauce. If I had to do a post-mortem of the now-defunct service, there were several red flags, where an older me would’ve said, “hey, you need to fix X, Y and Z if you want this to take off.”

Perhaps, the easiest starting point and the biggest red flag is that I had trouble explaining exactly what it did. A common trait I’ve noticed with other developers/designers is that, once we put on our hats, we get really technical and granular about things. So when a guy once asked me what the service did, I replied, “well, musicians can upload, sell and buy their stems, or they can upload, sell and buy full tracks.” Terrible. Just terrible. I’d then try to explain what stems are in relation to tracks, which are just synonyms for songs. The whole marketplace just took too much explaining, which is partly to blame for the verbiage I used as well as the many things I tried the service to be capable of handling (ie. stem management, track management, musician catalog, split payments, virtual downloads, online payments, etc.).

Chael Sonnen said it best in one of his podcasts: “If you’re explaining, you’re losing”. With every time that I tried to explain what my service did, I took too many words. Having been part of the Wonderful World that is Product Design, simple is almost always better. With every other project that I’ve built, I start backwards now by creating a simple statement — X helps Y by doing Z. That’s the litmus test. If the project cannot translate into those simple terms, it is too complex and vulnerable to failure.