Project vs. Product: Words Matter
A project exists because we envision a goal to be achieved. A product has no end and evolves based on user feedback.
To misname things is to add to the world’s misery.
Always start with a quote from Albert Camus, just to claim a little of his intelligence for yourself.
What misery are we talking about here?
Mine, when I hear “we’re looking for an Agile project manager.” If that phrase doesn’t instantly make you want to run far, far away from civilization to take stock of your life and thoroughly reevaluate your priorities 🐐🧘, read on.
A project exists because we envision an end goal
“A project is a goal one sets out to achieve,” according to the Larousse dictionary. Carrying out a project therefore requires knowing where you’re going, which makes sense in certain contexts, depending on the risks you’re willing to take and how you assess the project’s profitability.
A topical example: the 2024 Paris Olympic Games. What a great project. The specifications, established by the International Olympic Committee, define the list of competitions to be held as well as the related procedures. Not to mention the timeline: needless to say, there’s little room for improvisation, and Tony Estanguet is, after all, feeling a little, just a tiny bit, of pressure 😱
A project therefore has a scheduled end and is based on a set of specifications that define the goal to be achieved. Once delivered, the project is complete and the project team is disbanded. Tony will then be able to take 4 or 5 years off to try to recover. We then move into the maintenance phase (equipment maintenance in this specific case).
Shrewd as you are, you’ve noticed that I chose an example from outside the software world to illustrate what a project is. That makes sense, since software development doesn’t lend itself well to a project-based approach; it’s much better suited to a product-based approach.
A product has no end
The problem with the product (its appeal?) is that we think we know what we want, and we’re wrong. You believe it, as the product developer, and your users believe it too. But all of this is just speculation; the only true arbiter, the real truth, is user feedback.
Building a product, therefore, involves moving into the unknown in search of a market, testing hypotheses, and making adjustments. This requires an iterative and incremental approach: build, gather feedback, assess, and start over. Each iteration is an opportunity to ask the same questions: Should we do more in this direction? Do things differently? Reevaluate our priorities?
In some cases, the market signals that you’re on the wrong track or presents you with a more promising opportunity. You must then be ready to “pivot,” that is, radically change the focus of the service provided and, consequently, the product. This is commonplace: Instagram and Criteo are good examples.
Consequently, a product has no predetermined end. It lives on for as long as possible, but adapts and evolves indefinitely, even if that means completely reinventing itself and having nothing in common with what it originally was.
When working in an Agile way, there are no projects, there are only products.