I wrote yesterday about the need to read manuals, and today I wanted to talk about the need to build simple and elegant solutions. My popular example is from my own life when I used to run a business intelligence software product development team and we did lots of exciting innovation, but some of this was really for rocket scientists only. We were building a rocket to take off from Houston to moon, while the end user was ok taking a car from Trophy Club to downtown Dallas (30 minute ride).

Yesterday, I got some tweets back about whether a software solution should be so intuitive that there should not be a need for a manual. In some cases this is true, but if you are using a complex engineering product, the case is definitely not about the UI or usability. Some products just have been built along the years with huge amount of features and functions and it is just not possible to explore these features without somebody guiding you, whether it is a video or a manual. I tend to learn more from online video presentations that are more “to-the-point” and will guide you through the process.

In my workshops I remind people that they should not be building solutions for themselves, especially if they have been around for a while (like myself). They should be building for the new  generation of users that are born with Internet and mobility. This generation assume expect Internet and mobility to be there and this generation does not really care about where the data resides… as long as they have access to it.  My daughter Daniela is a good example of the new generation. She would not tolerate an app that “she does not get” and that is not fun to use. That is by the way a common trend among teenagers of today. Try to get them to use a solution that is built 10 years ago with agonizing screens, multiple steps to get the task done. You can’t force these youngsters to use these kind of systems and therefore I believe many mature software organizations are really struggling to create something that is user friendly. One way to do this is by acquisitions as we have all seen happening this year.

One typical approach for the mature ISVs is not to re-create the current solution, but to identify the Minimum Value Product (MVP) that will match the new market entrants and this gives the potential for the mature ISV to get into the game and then add new functional layers on top of the platform itself. When I recognized this, my mind went back to my doctoral dissertation where I was optimized a software product platform for an analytical application software and how this could be used as part of your software product line engineering. Have you look at your software product development strategy from MVP perspective or are you trying to “cloud enable” your existing solution? If not, you should really think through how your transition to cloud and app world will look like especially if you have an existing on premise solution that could eventually become obsolete. These are strong words, but this is what I am seeing out there.