[ad_1]
\n<\/p>\n
I\u2019ve been involved in software development in both my own and our clients\u2019 companies. There are a few things that I\u2019ve learned over the years about software development. Perhaps you can find some of these experiences useful.<\/p>\n I think that there are basically two paths to software development: problem-based<\/strong> and idea-based<\/strong>. Both approaches can create great results. The former, however, often provides an easier path to success.<\/p>\n Over ten years ago, my colleagues and I were helping certain organizations improve their IT governance and project management. We discovered that they were not great in managing the totality of their projects, the project portfolio. A portfolio could contain hundreds of projects, worth millions, annually.<\/p>\n A typical problem for our clients was choosing the projects to invest in. They were using financial metrics\u2014mainly costs\u2014and had only a vague idea about the benefits that the project would produce. They also had difficulty determining which projects were strategically worth pursuing.<\/p>\n The third problem was communication. There were forms for project proposals and project control, but the overall picture was unclear. Functional departments used spreadsheets to list their respective project portfolios. Management teams were not sure if they were having the right projects, the overall impact of the portfolio, and the risk levels of the projects.<\/p>\n We saw our clients\u2019 pain and realized that they needed help in both managing the process and the portfolio. Inspired by the obvious need, I made a few prototypes of portfolio management software. It would communicate visually the necessary information of a single project and the whole portfolio.<\/p>\n When the clients saw my prototypes and started asking where they could buy the software, we knew that we were onto something. Today, our software-as-a-service, called Thinking Portfolio<\/a><\/strong>, has tens of thousands of users in over 50 countries.<\/p>\n Many software developers whom I\u2019ve interviewed for my blog and podcast have shared a similar story. They\u2019ve worked in the business or been connected to it and discovered a problem that has existed for years. The problem has not been painful enough to require a proper solution. Nobody has stopped to think about the actual cost that not solving the problem generates over the years. When someone points out the problem and comes up with a feasible solution, they are ready to buy it.<\/p>\n Here\u2019s what I\u2019ve found to be essential in developing a successful problem-based solution:<\/p>\n I\u2019ve always had many ideas for software solutions and managed to make some of them commercial. The ideas have been a result of exploring new technologies and coming up with uses that are often related to increased productivity.<\/p>\n When Internet apps were still quite rare, I came up with an idea to create a simple tool for making online surveys. I designed the tool and, with the help of a programmer, Timo Gunst<\/strong>, turned it into a product. We sold it to professional research firms. They installed it on their own servers and could produce unlimited surveys without external help, which saved them a lot of time and money. Our tool was also quite affordable compared to other solutions on the market.<\/p>\n Later, I\u2019ve launched other idea-based tools\u2014e.g., for ideation, project communications, risk identification, management maturity assessments, and customer feedback collection.<\/p>\n When creating software that is idea-driven, a good practice is to start with a working prototype. It can be a visual or a functional prototype. Customers can try it out and very quickly give feedback on its usefulness and how it could be improved. Only after that should you decide whether to invest more money in development.<\/p>\n You should never assume anything in developing idea-based software. Your own assumptions don\u2019t matter if the client says that \u201cthis does not work\u201d or \u201cI wouldn\u2019t use this.\u201d<\/p>\n Many developers want to make their product perfect before they launch. Guy Kawasak<\/strong>i has notoriously said, \u201cDon\u2019t worry. Be crappy.\u201d Obviously, he does not mean that you should sell buggy software. He means that your software does not have to be complete or perfect in every way to be useful and sellable.<\/p>\n A special challenge in selling idea-based software is that your customer may not see its value up front. Therefore, it is essential to find customers who share your enthusiasm and willingness to try out new things.<\/p>\n Some time ago, I presented to an association a prototype of a simple 360-degree smartphone feedback app. Workers and managers on a construction site would use it to give and receive feedback to each other.<\/p>\n The association did not buy the idea. It was \u201ctoo light\u201d\u00a0for their liking. Later, I discovered that someone else had created a similar app in another industry and got raving reviews. I\u2019m sure some of you have experienced the very same thing!<\/p>\n Today, it is easier than ever to turn ideas and solutions to a problem into software. It can be a stand-alone solution or an extension to existing software.<\/p>\n There\u2019s plenty of room for digital tools in construction. I advise you to use open standards to communicate with other systems and services. That way, your software is not just another app but a part of a larger ecosystem.<\/p>\n<\/div>\nSolving a problem with software<\/h2>\n
\n
Turning an idea into software<\/h2>\n
Go ahead!<\/h2>\n