> The project/product distinction is an important one for many reasons, so let’s touch on that here for a moment so we don’t conflate or confuse the two, especially since one is more productive than the other. Projects are delivered as one big monolithic thing, meaning that coordinating all the activities within a big release is difficult and slow. Projects create big batches of work that are handed off to others at the end of the project to deliver and maintain. Projects come and go and require extra coordination and communication to set up and organize temporary teams. Many issues can arise when maneuvering through a cumbersome, project-oriented process.
> In contrast, organizing and managing by product keeps the same group of people with the necessary expert domain knowledge consistently involved. Those who develop the product features don’t leave; they stick around to deliver changes to prod and maintenance. Project teams tend to be measured by vanity metrics (e.g., test teams within a project team are measured by the number of software bugs), whereas product teams are measured by the business value derived.
From _[Making Work Visible](http://a.co/0VnzWCf)_