Development is at the core of what we do.
Our CEO has often spoken about product development at various conferences, sharing a few of the lessons we’ve learned over the years. A few of those lessons are below as they are relevant not only to our product development but also to our custom development philosophy.
The first lesson is:
If it doesn’t benefit the end product, or makes your life easier but hurts the end product, don’t do it. The Matt’s Big Breakfast rule.
There is a restaurant in the Phoenix area, called Matt’s Big Breakfast, and the owner, Matt, doesn’t use a freezer or a microwave. Why, because they only make his life easier, they don’t improve the product. We feel the same way about our development. We should make our development and product decisions with the result in mind, not how easy it makes it for us as developers.
The second lesson:
Even though the customer may not be as technically advanced as you, everyone knows quality when they see it. The Snap-On principle.
You could use any number of products to highlight this principle, but I still remember the first time I used a Snap-on wrench. It was a box end wrench, had no moving parts, but I could still tell by the heft and feel it was far superior to any tool I owned. I knew nothing about metallurgy or tool and die manufacturer, but I could still tell. Software is the same way. Quality, when taken to the highest level is apparent even to the untrained consumer.
The third lesson is:
The only deadline is quality. The J. P. Gallo wine principle.
OP Gallo (a wine company) had a slogan for years on TV: “We will sell no wine before its time.” That should hold true for business solutions as well. We’ve all seen the cost of releasing a product for marketing deadlines and not quality deadlines. Deadlines matter, but not at the cost of quality.
The fourth lesson:
The bigger your toolbox, the better your solution. The rock climbers rule.
The old catch-phrase “Give someone a hammer and everything starts to look like a nail” applies here. We believe that to build a solution with only one tool is limiting your ability to be creative. That is why so many of our solutions use web, mobile and other related technologies. A diverse toolbox, when used to create a coherent solution, results in a better result, diversity adds stability when done correctly.
Our fifth lesson:
You only build it once, but you support it forever. Build it for improvements and corrections.
All solutions need to be built with growth in mind, this is more true for products than custom solutions, because the product needs to be built for the modifications of many more users. The lesson still applies however, because custom solutions often have a much longer lifecycle.
Our final lesson:
A great, long term product is built for four phases. It is built to be bought, deployed, revised and replaced. And every consumer knows it, at least subconsciously.
The guys at 37 Signals wrote a book, called Getting Real. In it they deal with these concepts and many more, and we agree with a lot of what they have to say on this subject. One key component however is that if a customer is not comfortable with their ability to easily make transitions, they have a right to be less comfortable with the solution.
One final note about our custom development. Our projects also tend to be cyclical, which the below graphic represents well. We don’t think of our development as a one time investment, but an initial investment of effort. For your organization to grow, your solutions need to grow with you, and we are practiced at growing businesses.
