In recent years we have seen the arrival of many concepts that have been embraced to a lesser or greater extent, such as big data, SaaS, cloud or agile, but there are still some concepts that are more difficult to take on board; as is the case with product development.  The aim of this article is to reflect more closely on the implications of this and the difference between product development and the more traditional concept of product design.

What Is a Product?

Although the question may seem trivial, if we go to Wikipedia we will find more than 20 definitions according to the field in which we apply the term “product”.  In this case, the closest definitions would be:

When applied to the technology sector, a product may be defined as an ‘item’ or application arising from the development of software that allows us to offer a solution to the day-to-day business needs of a specific unit, department or even a group of companies, if the product is something we may offer the market. 

In other words, a product is a software application offering a set of functions or capacities that satisfy the different needs of a client or group of clients.

Differences Between Project And Product

Having defined ‘product’, it may seem that there is not much difference between a product and the more traditional and well-known software project, and therefore we will consider these differences in more detail.


A project is an initiative that usually has a set time limit.  A team has a predefined scope within a pre-established time period in which to undertake the creation or setting up of a solution in response to specific predefined needs. However, unlike a project, a product does not have a fixed timescale but starts with the identification of a need and is developed via delivery of continued value and through collecting feedback from users. Therefore, whilst the project has a start and end date, the product could (and should) continue for as long as applicable, evolving and adopting new capacities (including the undertaking of new projects to enable it to evolve). 

This leads us to another difference: product lifecycle.  Unlike a project (which has a schedule instead of a lifecycle), the product goes through various stages: product conception, construction and introduction to market, development and finally, withdrawal of the product when it is discontinued or replaced. Consider, for example, an operating system. When launched in the market, this has a series of capacities and innovations, but continues to develop, solving possible issues and adopting new capacities, until the time when, after a couple of years, it is substituted by a new product and the cycle begins again.


Another distinguishing factor between project and product is when we begin to build the product. On many occasions we do not have all the information we should about its capacities but once we start to build the product and revise its capabilities with product owners, product managers and users, new characteristics arise.

In a project, on the other hand, all information must be gathered at the start to avoid problems during development, which is critical since these problems cannot always be resolved, leading to one of the problems traditionally found in software project development (and other types).


Having clarified that the product objective exceeds the timescale of a project objective and that products have their own lifecycle, it follows that the job profiles involved in defining and constructing a product will be different from the traditional roles required for a project. Thus new profiles emerge, among them the product owner/manager

The product manager role is traditionally associated with the world of marketing and is the person with ultimate charge of a product.  As a result, the product manager is responsible for drawing together the different needs of the market or business areas, and once these have been identified, for finding a solution that results in the creation of a product, with a series of characteristics, capacities and functions.  

Furthermore, ‘product owner‘ as such is not a separate post in business but is a role taken on by people such as the product manager, whose objective is managing the product lifecycle. Thus a product manager would take on this role in product construction. 

However, the traditional project leader or project manager is the person responsible for the project team and for undertaking delivery of capacities throughout, meeting the project schedule and budget. Once the project has been completed, the project leader and team move onto a new project, unlike the product manager, who retains the role until the end of the product’s lifecycle. Moreover, the product manager/owner is the person with final responsibility for the project’s functionality whilst the project manager/leader is responsible for delivering the functionality agreed in the scope of the project. 

Another significant difference is that the role of project manager may be fulfilled by someone external to the organisation in many cases, whereas the product manager needs to be someone employed by the company who can collate the information and decide the product’s functionality.


Even if the project does not necessarily mean traditional waterfall in terms of methodology, if we are talking about the project as a time-bound initiative, in which a team with a pre-established timescale and predefined brief is asked to create or introduce a solution to these specific and a priori defined needs, what we are in fact being asked to do is to manage it in a traditional way, following Gantt and using change management as a cornerstone within the project. However, the approach to product development is more closely linked to agile methodologies and frameworks in order to achieve:

Continuous value delivery to the end user: The product is constructed incrementally and iteratively in frequent deliveries to the client from the start. The delivered product is usable by the client who is given end-to-end service. 

Customer-centric focus: The product grows around the needs of the client and based on continuous feedback which is incorporated into the product, optimising its value and reducing the risk of investment in functions of no interest.

Reduced time-to-market: Priority should be given to generating a Minimum Viable Product (MVP) and supplying this to the client quickly, choosing the functionality that best responds to market demand at any moment. 


Another relevant point that many businesses are still in the process of understanding is the idea of the product as a solution that brings a tangible benefit to the business and which therefore gives a return on the investment made in it. This point, often taken for granted, is not totally understood, when compared to the investment made in more traditional projects that is considered a cost (and the project, therefore, a cost centre). This is different from products, which must be considered (and are starting to be) as profit centres. However, as this concept is increasingly integrated, it is important to know the expected return on investment (ROI) of the product, the period required for payback and thus to best quantify the value of the product. 


The validity or success of the project compared to what makes a product successful follows the aforementioned point. 

A project that is completed in time and on “form” (with well-defined deliveries in the allocated time according to scheduled resources and budgets) may be considered a successful project, regardless of whether users find value in its use or application. On the other hand, for a product to be considered successful it must combine a series of capabilities that bring real value to the business and users, and more specifically, must be capable of meeting key performance indicators such as those mentioned previously.  Moreover, meeting these KPIs is key to giving continuity and improvement to the product. If we consider a machine learning product that helps us improve the sale of products at a cost much lower than the benefit it brings, not only would we keep it for a long time but we would also try to improve it.


At Keepler, our aim is to help our clients develop beyond projects (which we also undertake) to create products aimed at design, exploitation and obtaining value from data available in different organisations.  This is what we refer to as Data Products and these are constructed based on three pillars:

Data value: Data are the new company asset.  The true value of data is in their ability to be interpreted to lead to intelligent decision-making that helps the success of the business. 

Client knowledge:  In a competitive setting, businesses benefit from having a greater knowledge of their customers / products so that they can improve the services they offer and differentiate themselves from the competition.

Adjustment of cost and demand: More value with less cost.  Product adapted to the market that generates greater benefit and competitive advantage through the use of the public cloud: pay per use, automation, reduced operation costs.

Image: unsplash | rawpixel


  • Ana Manzanares

    Business Development en Keepler. "Computer engineer with experience in technology consulting with public cloud providers. I have managed traditional projects and product development for large accounts. In recent years I have combined it with internal mentoring and team management applying agile practices."