Software has a very unique characteristic, you create it once but can deploy it as much as you like. This goes beyond the limitation of other industries such as architecture, manufacturing, etc. In those industries you design it once, after which you can mass produce it, but the production itself has to happen every single time. Software is not bound to this as it does not deal with any physical objects. This makes software a good fit for a product approach, were it not that people have different preferences and like some customisation.
The level of customisation that is required will define which approach you can use. If the customisation is limited to a couple of themes and turning on/off some features, including this in the product is a good approach. This is what you see with customer-oriented applications, such as Microsoft Office, Mozilla Firefox, …
When developing software for businesses it is often a bit more tricky as sometimes the logic of the application needs changes. Including this in the product can be achieved, but there is no reason for that if it is only useful for this single customer. Sometimes you even have customers that want a specific look and feel of the application. Trying to sell an application to multiple customers can easily result in different clashing requirements.
To satisfy the different customers you need to be able to modify the product in a sufficient matter. This is not an easy exercise and must be handled with care, as it can easily clutter the code leaving it unreadable and unmaintainable. Completely abandoning the product strategy and create all software project specific is very unlikely to be successful as it requires a lot of time and effort to always write the program again, especially if you have to redo some common features.
If you have too much customisation to be handled as configuration in the product, it is inevitable to create new applications every time. This does however not mean that you have to start from scratch. The winning approach will be to have small modules or building blocks that can be used to create the application. For each of these modules it will be important to find the right balance between re-usability and configurability. A module that can not be configured at all is very unlikely to be a candidate for re-use in a different project, as it can only do exactly what it was written for. A module that allows everything to be configured will be hard to maintain and can easily end up as a ‘catch all’ module, which is easily extended to fit yet another purpose.
As in many cases, neither end of the spectrum is very good. A product that is completely not configurable will be impossible to sell to many customers. Creating a new product for every single customer is just too expensive. Finding the right balance is crucial, and depending on where that balance exactly lies you either use a configurable product or a product that can be created by assembling modules. In the end it is important to organise your company to enable this product development as well.