skip to Main Content

Product Teams vs Project Teams

Ah, the IT project. You could recognize it from across a Gannt chart, right?

A champion proposes something. Senior leaders make funding decisions. Requirements are written. Estimates are offered, usually reluctantly. There’s a kickoff. Work proceeds. Scope changes (and the PM grumbles).

Finally, there’s a release, or maybe a few. Then we celebrate with cake in the breakroom, and everyone disbands and moves on — usually, to the next project.

Projects are necessary. Projects are even good. And organizations have gotten pretty good at managing projects.

But projects are not enough.

Instead of being driven by their project processes, smart teams and businesses organize around the products they offer users, and they have a creative and expansive understanding of what those products are.

Why do we prefer a product and a customer approach to the traditional project approach?

First of all, it’s too easy to forget about the customer when focused on the project. Think of how we measure the success of a project: Were we on budget? Were we on time? Did we meet the requirements? Was the sponsor happy?

The problem: even if all these measures are looking great, they don’t tell you a thing about your customer’s experience or about your business’s health. A product’s measures, on the other hand, contribute directly to your business.

Customer engagement. Sales. Satisfaction. Delight.

And projects are designed to end. That’s great, but if you’re focused on finishing the project, it’s tough to respond to new insights and a changing market. A product orientation expects new information to inform growth, ideally for as long as possible.

Most project-based processes discourage changes to requirements, but a product-based process encourages them: after all a new requirement just means we’ve learned more about our customer and our business, right?

In a sentence: you manage projects to end; you manage products to endure.

Keep that at the top of your mind, and your attitude toward customers, requirements, releases, delivery, and funding will all shift — we think, to the better.

So rather than funding projects, try funding product teams, and give those teams the autonomy (and the responsibility!) to relentlessly and continually manage the product to delight customers and deliver results — and the courage to adapt it or even shut it down if it doesn’t.


Leave a Reply

Your email address will not be published. Required fields are marked *