If people really understood what true excellence is then they’d spend less time doing shit that really doesn’t matter.
I have to eat my own words here as I’m subject to the same temptation to feel like I have to do it all (and then some) so that excellence can be achieved.
But this stems from my misguided belief (and bad education and poor experience) that more is actually better, especially when it comes to developing great products.
I have to fight this temptation every single step of the way. You’re probably guilty of it yourself. Really, let’s just be honest. I was right here in this perfect example. I did too much and wasn’t working toward true excellence.
An all-too-common pitch that I hear (or that I’ve said myself):
Bro… I’m building this innovative new web application that will provide a seamless and comprehensive bridge between A and B while creating an ground-breaking new ecosystem C. It’ll even flush your toilet while you brush your teeth all-the-while reading you (in your own choice of British, American, or Asian accents) your RSS subscriptions!
The problem is not in the concept entirely (except for the last part). The problem is that true excellence requires that you be able to do all of those things with excellence. This is too tall of an order right out of the gate. In fact, if you can even do one of those things really, really, really well then you’re in half-way decent shape.
That’s why software bloat and anemic applications are normative and accepted everywhere. Take a look at your own digital library of software solutions and ask yourself whether you use 100% of every feature in each of those apps.
Most likely you’ll come away with something paltry like 10, 20, maybe even 30% total usage? What a waste, especially if the goal of the product (and the company behind it) is adoption, which is most simply massive usage through user acquisition.
Think of all the time that could have been spent on quality product development on the one or two features that made the most sense, that were uncompromisable as a feature-set. In other words, what features that had to exist in order for the application to exist in it’s most simple form.
Often people talk about these things in terms of Lean Startup Methodology or MVPs. Call it whatever you’d like – I just think in terms of excellence – and again, I’ll admit, I fight tooth and nail this struggle every single day.
Even in my current project Pressgram I’m having to claw my way out of what I’ve been taught through years of poor product development mentorship and re-learn what it means to build with excellence. Build the things that matter. That’s why I determined early on that it would be first and foremost a publishing app, not an filtered-photo/editing app. This of course jives 100% with the core mission as well.
Does it really matter to the end user since it seems so one-in-the-same? Perhaps not. But it makes a world of difference to me, the creator, as it orients my time and core feature-set. It informs everything else. It’s prioritization in it’s higher product development form. It’s costly. It’s hard. It’s supposed to be that way.
Am I open to iterating and making adjustments to the feature-set as the app grows, expands, gains traction? Of course. But without a solid framework to base those iterations off of you’ve got nothing but yet-another-mediocre-app. I don’t want to build shit. I want to build things that matter.
And you should too.