Last week, Spottah 2.0 was released. The redesign was made possible by the talented Chris Allen. He discovered Spottah at a bachelor party, loved it, and pitched us on a redesign. Two days later, he shipped a reimagined home page. It was stunning.
Chris crafted crisp designs and Yin brought them to life. And for the next few months, I had the honor of watching the Lennon/McCartney of app builders compose their masterpiece.
For the last five years, I have been immersed in technology. My journey began as a market analyst covering the technology needs and buying patterns of financial service companies. Currently, I help Teach For America budget and forecast its technology investments. Given the pace at which TFA invests in technology I have seen some amazing projects, most notably ERP and CRM implementations.
The amount I have learned in the last five years, however, does not sum to what I've learned in the last five weeks. Before Christmas, I began developing a mobile application with a team I met at NYU. I'll spare you the details until we launch in mid-February, but let's say we built and distributed a minimum viable product and the feedback has been overwhelmingly positive.
Having never worked on the product development side, the learning curve is steep. My biggest takeaway to date is deciding whether to invest in performance or functionality. Product novices take for granted that applications work reliably and securely. We log into Gmail and expect our emails to be there. We post a picture to Facebook and expect it to instantly appear in our feed. In other words, we take for granted what we cannot see. This is performance and it makes or breaks an application. Would you use Gmail if 1 out of every 100 emails got lost? Would Facebook be as popular if it took 15 seconds instead of 0.15 seconds to post a photo?
On the other hand, product novices are quick to identify -- and long for -- missing features. We are accustomed to using complete products built by teams of engineers. We expect every bell and whistle, and get flustered when we are unable to do a seemingly easy task. We cannot imagine a product that is not integrated with Twitter or designed to send alerts. Functionality is what you see, and it too can make or break a product. Instagram is a great example; would the up-start be as successful without filters?
Early-stage companies have limited resources and therefore must decide between better performance or more features. As I wrestle with this decision, I am reminded of my family friends. The husband drove a Jaguar and the wife drove a Porsche. When I got my license, they were kind enough to let me test their exotic vehicles. (My family had a Ford Taurus and a Mercury Grand Marquis so you could imagine my joy.) When I got into the Porsche, I was amazed at how sparse it was. It was basically an empty cockpit with a pathetic after-market stereo. Then I turned it on, put it in first gear, and slalomed through the back roads. Damn; it was the definition of performance. Then I got into the Jaguar. It had everything. Plush seats, a great stereo, beautiful wood paneling. It was comfortable and pretty but it didn't drive much better than my dad's Grand Marquis. And even worse, the Jaguar was always in the shop. In short, the Jag was all features and no performance.
So as I discuss the development roadmap with my team, I remind myself it is better to be a Porsche than a Jaguar. A sparse product that works is better than a fully-loaded flop.
I'm the Founder and CEO of Peak Support. This blog is my take on early-stage companies and innovation. Every so often, there may be a post about culture, networking, family -- you name it. After all, what is a blog if it isn't a tad bit unstructured.