With the rise of software development, we've developed this sort of mindset as an entrepreneurship society that you should release early to test your concept and see how it goes. That the risk is taking too much time building something that nobody wants. That you should always start with an "MVP" (minimum viable product) and then iterate from there if it goes well. "Fail fast and fail often."
On the other side is this "build it and they will come" mentality. That you should take as much time as it takes to build something great, and trusting that people will recognize that it's great and will show up for it.
I don't think that there's one right way to do things. But to me, the "MVP" concept has never really rung true to how I want to build. And it has bothered me in the past that people treat this as the only practical way to create a new product.
There's something to be said about building something truly great, from the very beginning, and not releasing until it's a terrific product. There's something romantic about that. And I'm not trying to diminish the risk of it. It would be very painful to spend multiple years building something that you deem as great, only to have nobody want to use it. But even if that's the case, have you really lost any time on it? Or is the value in the journey of building the thing itself? And haven't you learned things along the way that will benefit you in your next product? If you're building something that you believe is insanely great, I don't believe that time spent building is time wasted, even if the release doesn't go as hoped.
I also tend to think that if you're building something that you want, the chances are slim that you are 1 in 7 billion people that want that thing. But marketing is a whole different story that I won't dive into here.
To me, building an MVP tends to have an air of disingenuous-ness. Not that it's always that way, or that's not an okay way of doing things. But it's difficult to feel passionate about something that I'm not pouring my whole heart and soul into. It's much easier to get my brain and heart along for the ride, and convince myself that something is worth spending time on, if my mission is to build something truly awesome, something "insanely great".
"MVP" has only recently become an option, but that doesn't mean it's the only way to do things
Before software, the minimum-viable-product mentality was not an option. Because the product couldn't be given over-the-air updates later on, it had to work as intended, and work in a great way, from the very beginning. You couldn't buy a toolset in the 1800s with the promise of future updates. You had to research and buy the best toolset, with the knowledge that what you bought was what you got.
One of the benefits of software are over-the-air (OTA) updates. That functionality should absolutely be taken advantage of. We shouldn't be dependent on it (Fisker is a great recent example of a company that released their product too early, with promises that it would get better after some planned OTA updates) - we should still be releasing a finished product - but we can absolutely take advantage of adding additional features after the fact. I love updates on software. I don't love unfinished software.
And I know that I'm not the only one in this. One of the greatest video games of all time, The Legend of Zelda: Breath of the Wild, is evidence that there are other people that might feel this way too. This was a game that was released not as an MVP, but as an essentially finished product. A couple of updates did come later down the road with some additional gameplay, but the product as it was released could be completely enjoyed and appreciated all by itself. It wasn't missing anything at launch.
That's the kind of product that I want to build. That's what I feel is a positive use of my time. Building something beautiful, something terrific, something that I believe in.
The risk of never releasing a "finished" product
My theory is that big companies may have an easier time of releasing finished products than do companies made up of a single individual. This is because bigger companies have timelines to hit, and sometimes investors to please. An individual on the other hand, working by themself, maybe on a side project, could very likely shift a release date without anyone noticing.
Feature creep is the situation of constantly adding new features to a product that weren't originally intended on being included. It can lead to this mindset of never feeling that your product is finished, or in a state to be released.
So, for me, and anyone else working on releasing a beautiful finished product, it's important to set these timeline goals and a clear definition of what is and what isn't considered a finished product.
With Stuff, my upcoming to-do list app, I've had a clearly established feature set since the time I began development over 2 years ago. That list has changed very slightly as I've used the app myself and decided it didn't need some things or it did need others, but it hasn't changed enough to substantially effect timelines. A red flag would be if I was coming up to the end of that list, but still adding new things onto the bottom of it.
Build something wonderful
Again, I'm not calling the MVP method a bad way of doing business. But it doesn't represent the type of mindset I want to have. I don't want to be thinking, "what's the minimum I could do, and still succeed?" I want my mindset to be, "What's the very best thing I could build, something that I'll be proud of, and that will really benefit other people?". I feel passionate about building something terrific, in gratitude to humanity, showcasing the best of what people can create.
One of the ways that I believe people express their appreciation to the rest of humanity is to make something wonderful and put it out there.
Steve Jobs
Making something wonderful is so much more exciting to me. It's how we used to do it. And it's the attitude I want to have towards the products I create.
Comments