A Brief Explanation of Project vs a Product
We’re in the days of optimization. Optimizing everything we do — the way we eat, talk, make friends, work, deliver work. Even the way we refer to things now can have a profound impact.
There are (at least) two ways of looking at delivering a digital “thing” for a brand or a customer. The first, the age-old, tried & true method of looking at delivery is as a Project. This way stems from history — software has historically taken a long time to build, has a lot of moving parts, depends on a lot of systems, and is hard to change after the fact. Often it was delivered on a disk or a CD and literally couldn’t be changed after the fact without patches. This work needed to me “managed” by a “manager” and so now we see PMP in email signatures.
The second, “trendy” way of approaching digital work is the Product. A product is entirely different from a Project in that it seeks no clear “finish date”. The product team continues on as long as the product itself is seeing growth and success. It continuously changes and improves. Whereas a Project has a firm delivery date when success is measured by time, cost, and quality, a Product includes some aspects of those but works to always improve them.
Important Differences
Timeline
A product by nature usually launches much earlier than a project will. An important feature of product management is in-market learning. How can you learn what the customer wants without letting them use it for real? Research and user testing are important parts of deciding what to build — but getting that first version out is everything.
After initial delivery, expect continuous development and delivery.
Updates
Products are updated constantly. As often as every day or even multiple times per day. As hypotheses are experimented with, we’re always learning how people use the product, if they find value, and if they are converting into customers. There are no bulky statements of work or change requests that get assimilated. If a feature seems like a good idea, we test it. Features that work well, we keep and build one. Ones that stink we kill.
We call this feeding the winners and starving the losers.
The Team
A Product team is usually different than a project team, though you’ll see many of the same players. Designers, developers, analysts all have a role on the team. The key difference is the project manager vs the product manager/owner. A project manager is hell-bent on delivery. Their goal is to make sure that all the objectives are met, the project goes out, and their job is done. Maybe they start working on the next set of project deliverables, but they waterfall that work too.
A Product Manager is responsible for not only the success of delivery, but for the product itself. They are reliant on building a great product and seeing it succeed. Their work is not finished when first launch happens, but rather it is likely never finished (unless the product simply can’t succeed, which is also fine). A product manager will understand product/market fit, the competition, the right to win, and the space the product is in.
Where a project manager will usually report to a stakeholder, and their success metric is delivery, a product manager should “report to the consumer”.
When to deliver Product vs Project?
There are times when simply delivering like a project is a good idea. Quick marketing sites, simple apps, proofs of concept, and other low-risk items are all good examples. Or, even though it seems silly, sometimes there is just extra budget and idle hands. Putting together a hackathon or a “20% project” can be a fine way to deliver a project.
A product, however, should be chosen whenever growth is in mind. When working in a product mindset, a team is focused on quick delivery and experimentation, understanding the consumer very well, and in-market learning. E-commerce shops, social networks and platforms, productivity tools, etc, are all products. They have to cater to a set of customers and continue to innovate in their space to stay competitive.
Think of big pieces of software: Facebook, Google Suite, Outlook. All of these are products that are constantly changing and evolving with the world. New features are released all of the time, some small enough that you barely recognize that they’ve been introduced. Whole teams of people are iterating on features and reviewing results.
To win in the digital space, product development must be the new normal, the new mandatory. If you start with one set of assumptions and they are proven wrong, how quickly are you able to try new ones? Do you start a new project, or do simply swap out the losers for winners?
Initial delivery is but a moment in time, followed by countless further deliveries, each one producing something better for your customers.
