Let's face it: Product vs Project
Are you working on a Project disguised as a Product?
I am amused to see how innocent or unaware are some well-known organizations and their leaders. Especially the organizations that have been in business for quite some time and influence their market/domain are sometimes so preoccupied that they start missing out on the big picture and the transforming atmosphere around them.
I see projects in disguise as products and everyone playing along until they start seeing their adverse effects and losing out on their peers.
Business leadership, product managers, engineering teams, other stakeholders, etc. are often satisfied to continue the game as is because they either don’t understand the bigger problem or they think it’s easier to just continue doing what they have been doing for years over transforming their end-to-end approach to product.
This is my attempt to define and distinguish between Product and Project so that when you come across it, you can identify it, help your leadership see the challenge, and support them in being a true Product organization.
To be clear, I do not have anything against Projects. In fact, Projects have a very important role to play in the life of any product and product organization. However, it needs to be understood that the Product, outlives Project and has a much bigger scope, purpose, and impact value for customers. The problem arises when teams fail to distinguish between the two and start using them interchangeably in their day-to-day communications and practices.
Let’s start with the Project. A simple Google search will reveal many ways to define a project. To put it simply, a project has often below key characteristics:
It has a defined and unique objective, often output-focused with outlined deliverables and success criteria
It’s a temporary endeavor/initiative with a defined start date, end date, and duration
Constrained within the limits of the Iron triangle (Core elements: Scope, Time, Cost). You could see other variations of this as well with factors such as quality, risk, etc.
There are more, but for now, let us limit ourselves to just these key identifiers. So, now let’s see some examples of a project:
A project to build an underground pedestrian crossing at a busy intersection. Construction start date 1st Feb 2024 and a project duration of 6 months with a maximum extension of 2 more months depending on follow-up change requests.
Photo by Matthew Henry on Unsplash The total sanctioned cost is 1.2 Mn USD with defined delivery specifications for quality checks, material usage, approved design, construction milestone-based funding release plan, etc.
A project to create an iOS app that will deliver the specified functionalities as per the requirement specification/backlog in the next quarter with no P1 bugs aligned with the platform security, quality, and design specifications with a sanctioned budget of 850 K USD.
Note how the project conversation often revolves around the earlier specified key characteristics. The success of the project depends on the delivery of the defined deliverables as per the agreed specifications.
So, the bridge-building team will have a big celebration as soon as they are done with the delivery of the deliverables. They might even move to their next project soon after. Their success (and payment) is not dependent on the achievement of the purpose of creation of the bridge such as helping the pedestrians, reducing accidents involving pedestrians at the intersections, making pedestrians feel safer in using the underground crossing, etc. There is nothing wrong is it, but it highlights how the success of a project could be very tactical while undermining the big picture.
Similarly, the app-building project is considered a success if it meets all the delivery specifications, irrespective of the performance of the app. Whether the target audience of an app likes it or not, Whether the app is downloaded or not, whether the app gets any revenue or not, etc performance factors are not considered to decide the success or failure of a project.
You get the point! And, this is where we enter the Product paradigm!
Product-focused mindset emphasizes Outcome over Output!
I define a Product as a good or a service that is in pursuit of solving a problem or leveraging an opportunity concerning a target audience. The owner or creator of the product seeks to benefit (nature, definition, and measurement vary by product, stage in product life cycle, business objective, creator’s intent, etc.) from the application of the product while solving the target problem or leveraging the target opportunity.
Hence, a Product would have the following crucial attributes:
A defined value (and strategic mission) in the form of a problem or potential opportunity that the product is targeted towards
A target set of users or customers who would be getting the value of the product
A problem solver of the provider of the product who is orchestrating to make the product successful
These are just some of the very high-level initial Product attributes. However, a Product needs more to grow and evolve
A current version of the hypothesis that the product increment is targeted to validate
An evolving understanding of the competitive landscape, business scenarios, solution technologies, and customer preferences
A continued leadership drive toward the strategic objectives with tactical agility
and more such attributes
Taking forward our earlier example:
An underground pedestrian crossing at a busy intersection is the product and the first project was to build it as per the specifications. After the success of this project, the product team might decide to undertake another project related to providing a small retail and food joint section to add to the convenience and experience of the pedestrians using it. The decisions of these projects are taken based on several factors such as market research, commercialization needs, some similar products in some other part of the world, or most importantly, the direct feedback of the pedestrians using it.
Product deploys a very different mindset which is very entrepreneurial, strategic, business outcome-oriented, and long-term focused. A Product can have multiple projects ongoing concurrently or in sequence over its life cycle. Each underlying project is a step towards the strategic objective of the Product that they are contributing to.
So, to conclude: YES, “Product" and "Project" have their respective values. Often, the second one adds value to the first. It's crucial to grasp their differences and mindsets and to use them appropriately depending on the context and purpose.
Signing off. More in the next edition.
In the meantime, I invite you to join my professional network on LinkedIn.