Situational Applications - Build for Today be Ready for Tomorrow

Today I want to talk to you about the concept of "situational applications". The term is relatively new, but the concept is not. The concept is KISS (Keep It Simple, Stupid).

First let's define a situational application: "A situational application is 'good enough' software created for a small group of users with specific needs. . . as the requirements of a small team using the application change, the situational application also continues to evolve to accommodate these changes."

Many of the best applications begin as situational. For example, SMTP, which is the standard protocol for sending email, was initially developed as a simple way to send electronic messages, after the introduction of many bloated formats (including Mail Box Protocol and FTP Mail). Many early internet providers found these original protocols, although comprehensive, too complicated to implement. SMTP, which stands for Simple Mail Transfer Protocol, was developed as a simple way to send text-based messages from point A to point B. The simplicity of the framework caught hold, ultimately became the standard, and has since been enhanced with the features you know as an e-mail user.

Web services are another great example. The original vision manifested as Simple Object Access Protocol (SOAP), which was a comprehensive, complex protocol for allowing different systems to talk to one another. Ultimately, SOAP grew in comprehensiveness and complexity. As a result, Representational State Transfer (REST), a simple protocol that does the same thing as SOAP but without all the bells and whistles, was developed. The result is that REST has taken hold as the preferred standard. REST has continued to evolve to meet additional needs as they gain traction, but its evolution is organic, not forced.

I've had the opportunity to build a lot of new software products for great companies. And the more applications I build, the more I realize that most (if not all) of them are in fact, situational, and should be treated as such. Instead of trying to build the end-all-be-all in release 1, I've found we're more successful successful if we build an application that can addresses the core business problem, and getting it out into the user community quickly. Ultimately, the user community will drive the direction of the application. If a core need is met quickly, the app will be used; and if the app is friendly and appealing enough, users will want to give ideas on how it can continue to make their lives/jobs easier. In all of my years building applications, the most time-tested and well received, have inevitably started by simply solving a "situational" problem. Over time, they have become much more than that, but they all started with a laser focus.

If you are a product manager (or if you work for one) remember to Keep It Simple. Get the product out early and request feedback from users often. Use Agile Software Product Development to get that first release out quickly. The methodology lends itself to this approach. Stay focused on business value and work to achieve it as quickly as possible. Do not try to solve every problem for everyone right away, instead solve the BIG problem for everyone first. Everyone will line up behind you and your product after that to take care of the small stuff.

Please use the comments below to share ways that you Keep It Simple in your software product development, or share your experiences of how your 'situational applications' have become THE application because of laser focus on solving real business problems.

As always, thanks for reading.

-J

Whoa. . .this post was picked up by CIO.com.