Scrappy Vs. Polished

I’ve been thinking a lot recently about the best way to launch a new software product. The majority of my career has been spent working on small “scrappy” products. Even my enterprise experience started as a small bootstrapped startup before taking a large investment. These are products that typically have small budgets, where the product market is unknown or largely unproven.

Because of my background, I have developed a sense of urgency around my decision making process to try to build as much as possible as quickly as possible. The justification in my mind has always been that you don’t want to invest too much time, effort, money, etc in something that you may or may not throw away. It’s better to do the bare minimum to get the job done, and then move on to the next problem. This is the agile way… Do the minimum possible, get feedback, and iterate.

This has worked for me for a long time. I’ve learned this because I’ve been burned by investing too much time in a product that wasn’t worth it. If you’re a football fan, you may remember “Deflategate” from a few years ago. The Brackets for Good team thought this was the perfect opportunity to do good in the world and do a fundraiser. Tens of hours of product development later, and the turnout wasn’t great… In retrospect, we should have done everything possible to prove this idea was worth development before actually writing any code.

I’m recently working on a new product where I am a bit out of my comfort zone. We are moving slower than I’m used to, but the level of polish of this application is lightyears beyond the products I typically launch. On one hand, it feels good to be building something that looks and feels really nice. On the other hand, it’s terrifying to not know for sure if it’s worth it. Are we going to realize that what we built was wrong and pivot? It’s always possible, but I suppose that’s part of being in the startup game.

I was really inspired today seeing the release of Hey.com. The good people at 37 Signals started building this two years ago. Rather than releasing a bare minimum MVP, they are releasing an extremely polished experience right out of the gate. It definitely shows, and I was more excited about the product because of the UI interactions shown in the demo video. Now, half the reason I want to try it out is just to experience the UI.

A few years ago, a good friend and former business partner of mine told me “You can always tell when a product is well designed because as a software engineer it seems like you could replicate it in a weekend”. Of course, if you actually tried, you would realize that it’s not possible. It takes a ton of time, effort, and money to get to the level of polish to make it look that simple.

The lesson learned for me is that in the world of enterprise software, productivity is king. Pushing feature after feature out pleases your customers. In the world of software users want to use, polish is king. It has to be extremely easy and intuitive or users will leave and never come back. As an entrepreneur, it’s your job to pick a problem worthy of that time and investment that people truly care about. Once you’ve identified that problem, don’t limp in.

Photo by Joshua Fuller on Unsplash

Standard