It was October 2001 when my brother, my uncle and I agreed to develop an ERP software. We researched about the major players and its markets such as SAP, Oracle, Baan, Lawson and for small businesses such as Quickbooks and PeachTree. During that time, nobody offers a complete web-based solution. We liked the idea to build a product for multi-location, real-time business information anytime and anywhere. Since Microsoft was the dominant software player at the time, we initially chose .NET platform, but eventually switched to Java because of its open nature.

We bought books from Amazon when they still ship internationally to the Philippines. One of the books we purchased was about financial accounting. I remember I read the entire book in a day. We downloaded a lot of ebooks came up with a huge class diagram.

My uncle referred us to his former colleagues at SGV. One of them was a finance manager in a medium-sized manufacturing company. We went to him to validate our design. I remember a lot of sleepless nights to finish the whole design diagram.

We started coding in Java EJB framework as the backend and Struts framework in the front-end. We finished the general ledger module by April of 2002. At the time, we were ready to continue to receivables and payables modules. We decided to add more programmers and move to a bigger space. We hired two non-programmers instead because it was challenging to convince outsiders to work in a residential condo. One person we employed was our cousin Neil who’s a financial accounting graduate, and one is my former housemate and neighbor Shotie, an industrial engineering graduate. We trained them to create a program from scratch. We believed that anything could be learned and so they were able to.

After the A/R and A/P modules, we met another friend of our uncle, a CFO of a luxury car brand distributor. He sat down with us for consecutive nights to validate the product that we developed. I remember skipping a lot of dinners to go through each detail of the product and note the changes.

After a few months, he resigned from the car company and started his accounting firm. His company was the first-ever user of our product. And the rest was history. To-date, Hilsoft has more than ten business software products catered both for the horizontal and some industry-specific market.

So what is the formula behind a successful business software product? Here are some lessons I learned from the story above and our experience in the past 18 years.

  1. Deal with the problem first. Beyond products, start with the group you seek to serve and the problem you seek to solve and the change you seek to make. You cannot serve everyone. Start small. You can be a big fish in a pond than a small fish in the ocean.
  2. Successful is when the users say it is, not when you think the users will use it. In the above, we made a major overhaul when the end-user looked at it and told us this is how it should be. It is then important to involve the users as early as its design phase so you wouldn’t waste time coding them. We are developing two new products as of this writing and what we do is we get actual transactions, actual forms and reports to make sure that we are digitizing the actual process and not a make-believe process.
  3. Make it personal. I noted a lot of sleepless and hungry nights in my story above because of how personal it was to us at the time. You can only do big things if you do significant efforts. There are no shortcuts. If you’re an employee of a software company who develops these products, you can still make it your own and make it your legacy to the company. Recognition and rewards are inevitable if the company sees your passion for what you do.
  4. Be entrepreneurial. My cousin Neil is now a senior developer/analyst in a multi-national company. I still find the story amusing, on training them to be a programmer just because we couldn’t source for one at that time. Being entrepreneurial is having the ability to become resourceful and do workarounds on the available resource that you have.
  5. Release early and often. We often hear the term MVP or minimum viable product. But it is important to note that “viable” means working successfully. During the release planning stage, agree with the end-users on what is the minimum scope that is viable to them.
  6. Don’t advertise yet. Build a tiny tribe of loyal users from your community. Start with your close friends and relatives. Offer it for free. Advertising without getting enough traction is an old-school way of marketing. During the industrial age, when there is no Internet yet, people believe whatever they see in prints and ads. But now in the world of so much noise online, you’ll just be seen as another fly-by-night company if you don’t have initial active customers or users.

In summary, building a successful product requires choosing a market you want to serve, a big deal of an effort to develop and sales/leadership skills to send your message and gain loyal customers.

Leave a Reply

Your email address will not be published. Required fields are marked *