When creating a software business there are a lot of things to consider and many decisions to be made. One of the most important ones, especially if you are by yourself, is: how high are you going to put the software quality bar?
Giving the day-to-day pressures to build up the business (do you have a business or do you just think you do?), the multiple feature requests by your users, the support requests you have to tend to, the pile of ideas you’ve got in the roadmap and the limited time in each day, it is clear that some compromises must be made. You’ve got to strike a balance between having enough features that your tool is compelling and making sure that what you have actually works (otherwise people that you worked so hard to convince of using your tool will be frustrated and abandon it).
In the early stages
Remember the classic essay by Joel Spolsky Good Software Takes Ten Years. Get Used To it, yes it takes time to create a great product, but you need to make sure that your company is going to survive long enough to get there and you need to make sure you’re still enjoying what you are doing years down the line 🙂
During the early stages, not every feature we’ve pushed in a release of Dradis Pro was as polished as I’d have liked, but at the time we thought it was the right choice: push the feature out and let our users start benefiting from it. However we’re not in the early stages any more. We’ve been two years in business, with a growing client base and heathy amount of new sign ups every month. Now it’s the time to take two steps back and look at the big picture, to prepare ourselves for the next ten years.
One of the most important things to learn and keep in mind, even more important to those of us coming from an engineering background is that your users don’t care about your product. They don’t want to use your product for the shake of using a product. They want the results they’ll get from using your product, that’s where the focus should be. Let me repeat that again as it is quite important:
Your users don’t want to use your product,
they want the results they’ll get from using your product.
This means you have to identify what this end results are and focus your efforts in making it ever easier for your users to get there. This often means spending time refining areas of your tool instead of adding new features.
Balancing scope and software quality
In the era of the Lean Startup, the above ties nicely with the concept of minimum viable product: in order to become sustainable, you need to identify several key pieces of functionality that when put together are going to allow your users to get the end results they are looking for. [Note that I’m talking about being sustainable (i.e. generating enough revenue to reinvest in the product to improve it), not just in order to sell or in order to find users for your product. You can sell almost any piece of broken software for a low enough price. But that’s a different discussion for a different time.]
Throwing together those pieces and making sure that they can be made to work together as a coherent application is the very first stage in the lifecycle of the product. This means you’re solving a real problem, for real people, that will pay real money to get their problem solved. However, in the path to this first summit in your journey, you may have to release half-baked solutions or quirky code you are not proud of. You may even do this without being conscious about it (at the end of the day, you’re fighting an uphill battle, and getting results is the only think that counts on a daily basis).
There is a tipping point where you realize that the strategy of knocking together functionality and releasing it is not going to work in the long run. You are accruing too much technical debt. If you are hoping to be developing and maintaining your tool for years to come, you better make sure that you are creating something that you will want to maintain, something that you are proud of.
I saw the light while reading the Designing Web Applications book by Nathan Barry a few months ago. In particular a section discussing the ideas of Ryan Singer, Software designer at 37signals, on product quality:
I like to visualize software. Here’s an intuition that works for me. Feature complexity is like surface area and quality of execution is like height.
I want a base level of quality execution across all features. Whenever I commit to building or expanding a feature, I’m committing to a baseline of effort on the user experience. That way feature complexity — scope — is always the cost multiplier, not user experience. There aren’t debates about experience or how far to take it. The user experience simply has to be up to base standard in order to ship, no matter how trimmed down the feature is.
(Ryan has an article on his blog about the subject: What happens to user experience in a minimum viable product?)
Even though conceptually we’d all agree that it’s desirable to build good quality products, Ryan’s surface/heigh metaphor makes it really easy to understand the end goal we’re striving for and the reasoning behind it. It is a great tool that you can keep on the back of your head and use to drive your development efforts on a daily basis.
Keep your focus
It’s more important to ensure a consistent height across all areas of the product than it is to expand the surface. In fact, it is a trade off, there is no expanding the surface if the heigh isn’t going to be kept consistent.
This helps in narrowing the focus of what you’re trying to build, less surface, more height, build something great. This isn’t new, and there are many ways to phrase this feeling, but I always remember Bill Crosby’s:
I don’t know the key to success, but the key to failure is trying to please everybody.
You product can’t be all things to all people. This is why you’ve seen a multitude of minimalist text editors thrive by focussing on what is important and nothing else (iA Writer, Writeroom, Byword…). Have the basics taken care of before thinking about adding new stuff. As Julie Zhuo, Director of Product Design at Facebook puts it, there is a tax associated with every new feature you introduce that you better understand.
Making this shift, this change of focus towards quality, clarity and purpose has benefits all around. It makes you proud of the work you do and it helps to ensure that you don’t have too many features that you can’t pay attention to.
This is where we are going for the next few releases of Dradis Pro: don’t expect a lot of growth in the surface, we’ll focus on pushing and levelling our height, always keeping an eye on the results our users want to realize.
I’d like to wrap this post with another quote about quality and building a software product, this time by Jason Fried also of 37 signals:
It better be good, because people are depending on it to be good
