“You have a gift for MVP” they tell me. Maybe so, but I don’t see it like that. What I see is that I have a concern to get things out the door. I have a big picture in my mind. I don’t picture zig zags. While I do leave room for surprises and discovery, I picture a long straight path, with an occasional curve possible if something is encountered that justifies adjustment.
I do the same thing with my apps. I have a full time job, I go to the gym, and occasionally I even sleep. So my personal app development happens in my free time slots such as on weekends, or on nights where I’m not feeling tired so I sit and program with a cup of coffee.
In that spirit, I usually put out an MVP, and then iterate with additional features as time allows. For example, the first version of my Objective-C iOS app Rhythasym had a very elemental interface that wasn’t very pretty, but it was highly functional (before.) A few months later, I made a version 2.0 of Rhythasym which was more slick (after.)
The first version of my Swift iOS app, Philly Bike Dock, contained a plain text list of bike docks in the Philadelphia area (before.) The new 2.0 version features informative new pie charts and fonts that help the user to prioritize information (after.)
In addition to the revamped interface, I added a few onboarding screens to the newest version of Philly Bike Dock and fixed a bug related to reloading information. Lastly, I added the ability for people outside of center city Philadelphia to simulate their location as though they were at Philadelphia’s City Hall. This would help them to see how the app works even if they were not around bike docks. This is helpful for tourists planning a trip to Philly.
Next time around, I will add crash monitoring and analytics. It is valuable and easy to add these things, but, for me, they ranked below basic functionality. I am also tinkering with some server side features which I will operate from my AWS Linux NodeJS server. My server will keep tabs on the status of the bike docks. Let’s picture the scenario of someone wanting a bike, but there are none available at their closest bike dock. Through Philly Bike Dock, they can have my server “watch” the station for them, and when a bike becomes available, my server will use a Parse backend to issue a notification.
I would have run the project aground if I tried to do all this out of the gate. Instead, I released an MVP app with some basic functionality, and I knew that later on I would keep adding more and more.
I first learned about MVP in one of my favorite books, Rules for Revolutionaries, by Guy Kawasaki. It contains a lot of proverbs for product development. My favorite one is “don’t worry, be crappy.” Crap is not meant to be our life’s goal, but sometimes to get a product out the door, we need to simply kick it out the door and iterate later. A nicer way of saying “don’t worry, be crappy” is to say “perfect is the enemy of begun.” It is only crap in the relative sense. It is crap compared to what you know it will someday be. But we would never turn out something we thought was legitimately subpar.
Just think of all the versions of operating systems which have been released. The job of building these things is never, ever done. If programmers had waited to build the “perfect” operating system before releasing it, we still wouldn’t have the first version because the programmers could actually work forever and always have one more thing they could improve.
So what we do instead is to pick a core set of functionality and get it out the door. Sound easy? It never is. Even getting that little set of functionality launched is inevitably filled with travails. If you ship an MVP, you will thank goodness you had the discipline to keep it limited in scope. You will have set the terms of victory by shrinking your challenge down to size, and then conquering that little challenge!
Visit my website at jackamoratis.com
Evolution Image credit: