My Lessons Learned from Software Development

I’ve been involved in software development in both my own and our clients’ companies. There are a few things that I’ve learned over the years about software development. Perhaps you can find some of these experiences useful.

I think that there are basically two paths to software development: problem-based and idea-based. Both approaches can create great results. The former, however, often provides an easier path to success.

Solving a problem with software

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.

A typical problem for our clients was choosing the projects to invest in. They were using financial metrics—mainly costs—and had only a vague idea about the benefits that the project would produce. They also had difficulty determining which projects were strategically worth pursuing.

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.

We saw our clients’ 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.

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, has tens of thousands of users in over 50 countries.

Many software developers whom I’ve interviewed for my blog and podcast have shared a similar story. They’ve 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.

Here’s what I’ve found to be essential in developing a successful problem-based solution:

  • You must understand the customer’s business and “speak their language”
  • The client’s management, preferably the executive management, must know that the problem exists and must also want a solution
  • Your solution must solve the problem in a new, perhaps unexpected, way
  • Your solution should not generate new problems; it must not be too slow, difficult, or costly to implement
  • Social proof is good; having similar clients who have made the same choice creates confidence
  • Your solution must make both the decision maker and the users happy

Turning an idea into software

I’ve 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.

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, 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.

Later, I’ve launched other idea-based tools—e.g., for ideation, project communications, risk identification, management maturity assessments, and customer feedback collection.

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.

You should never assume anything in developing idea-based software. Your own assumptions don’t matter if the client says that “this does not work” or “I wouldn’t use this.”

Many developers want to make their product perfect before they launch. Guy Kawasaki has notoriously said, “Don’t worry. Be crappy.” 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.

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.

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.

The association did not buy the idea. It was “too light” for their liking. Later, I discovered that someone else had created a similar app in another industry and got raving reviews. I’m sure some of you have experienced the very same thing!

Go ahead!

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.

There’s 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.