Software Development Done Right

If you haven’t picked up by now, I LOVE developing software. I love everything from ideation and conception all the way to implementation and then release into the market. It just feels so good when I help a company move through each phase and get to where they want to be. However, one major stumbling block I see in clients that I’ve worked with is not shipping a product until every feature is done. If there is just one rule that I believe would have the biggest impact on your success in the marketplace it is this one. Read on…

“Build Half a Product, Not a Half-Assed Product” - 37Signals

Let’s consider this scenario. Imagine you are sailing toward your destination - a treasure chest that contains the release of a perfect software product. However, every time you get closer, the chest is moved and you have further to sail. This is what it’s like for those trying to release the “perfect” product. Instead, I suggest you settle for some small wins along the way, get your product released, and gain booty as you continue to learn and adapt, each time getting closer to the release that has everything you are wishing for.

37Signals did an interesting podcast on the principle of releasing half a product. Basically their stance (and one that I agree with) is that you only have limited time, resources, and people so you are going to have to remove some things. To quote them, “embrace the editing process!”

 

Be Extremely Picky

 

Beyond removing things, I would go one step further and that is don’t even spend your precious time considering extraneous features. Be extremely picky with each and every feature you add. This is not only when you are developing the software product from scratch, but also on versions 2,3, or 4. What are the basic minimums that you need in this next release? I’ll cover how you decide on these in a future chapter, but let me give you a hint… it’s the ones that are the simplest.

 

Think about this: When you work with a team to build software you should be well aware of the costs that each feature is going to have on the product, not only the time to build it but also the work to maintain it going forward. Remember SDDR Rule #1: Software is Never Done.

 

Each new feature you add is like putting a charge on your credit card to be paid at a future date. Thus, you should be extremely careful about what you are willing to sign on for. Besides the cost to get there, let’s also consider your time to market! There’s a huge cost to being slow to market. I like to tell customers, in general, to plan to release to the public with about 70% of your feature list complete.

 

But 70% is just a passing grade? Shouldn’t I be doing more?

 

No. One study by McKinsey & Co found that a product that is six months late to market, earns 33% less profit over five years. Those are some real numbers and should be a motivational factor to bring your minimum viable product to market as soon as possible.

 

However, I still see it all the time. We can’t release until X is done, people won’t buy our product if Y isn’t there. True - I don’t know your customers, fair enough, but I know that your customers won’t buy a half-assed product and that’s guaranteed.

 

I hope I have shown in this lesson why building half a product is OK. Through this process, you will pick up some treasure along the way. The point here is to be working with your crew to continually strive for fully completing a small number of features done well and picked up, over a large number that are half-baked.

 

Until next time when we’ll keep the maritime metaphor going with how to handle times when you find yourself with rough seas ahead!