Product vs project teams

I planned to write this article two years ago, right after the publication “Grocery vs. Feature Teams”. At the time, I thought I should develop the central line of thought in an article about the difference between product and project teams, but in reality it was wishful thinking.

I really wanted to believe that there was no longer a need to keep arguing that project teams were ineffective. Just like when you believed that no one would vote for outright fraud, or that people would rely on science for their health, or that Facebook would always do the right thing. Unfortunately, self-hypnosis cannot change reality.

My Silicon Valley Product Group (SVPG) partner and book co-author EMPOWERED: Ordinary People, Extraordinary Products Chris Jones recently shared with me that he still clashes with project teams, but I don’t want to believe that this is still common. It’s not that I didn’t write about problems that arise in project teams, it’s just that many of those articles were written more than ten years ago, and I really wanted to believe that we had already gone through all this.

This topic, of course, is related to the issue of differences between product and feature teams. The essential difference between a product team and a feature team is empowerment. The difference is, on the one hand, to give the team a problem that needs to be solved, and on the other hand, features that need to be implemented.

However, in essence, the difference between a product and a project team is responsibility. In one case, the team takes responsibility for key business results (“outcome” is a business effect metric that makes it possible to measure the value received for the company and customers); and in the other, the team is engaged in the delivery of the project, the actual results (“output” is a metric of the result of actual actions; numerical measures of the result of tasks, steps, or actions taken to create value).

In Lean Startup jargon, a product team is long-lived, with a long lifespan (usually at least 1-2 years). The project team, in contrast, exists throughout the life of the project. Therefore, project teams are sometimes associated with the concept of “pool model”: engineers are involved in working on a project for, for example, a week, a month or two, and after the end of work on the project, they return back to the pool, from where they will be reassigned to some other area. The biggest myth about the project team is that it works because every engineer is “fully engaged” on the most important project at the moment.

If you are working on something trivial like building websites, then yes. But I’ve never worked with a company that makes trivial things.

Product companies create things that are anything but trivial. In fact, it’s normal for an engineer to spend several months learning the required technology, the underlying architecture, the relevant codebase, and the area itself well enough to be able to play their key role. This same learning curve applies to designers and product managers.

The idea that any engineer or product manager can easily and immediately switch between major areas and be expected to come up with innovative ideas defies reality and goes far beyond wishful thinking.

And we are only talking about speed (velocity). Things get even more complicated when you try to talk about creating something of real value, not to mention innovating for the benefit of your customer. Not only are the people on the project barely familiar with the codebase, they’re even barely familiar with their peers, which doesn’t create the level of trust needed for real collaboration and problem solving. And they know even less about the real customers. It remains only to wish good luck in finding missionaries who will agree to work according to this model.

More generally, one thing we learned years ago is that success comes not from projects, but from constant work and iteration in a certain area until the necessary results are obtained.

The hallmarks of project teams are fairly easy to spot: contract teams, slow speed, little or no innovation, ballooning technical debt, lack of ownership of results, orphaned projects, and widespread blaming. You may be able to return to this project at some point in the future, but there are no guarantees, and even if a subsequent project is approved, who knows if the same people will be assigned to it?

These shortcomings have long been established and are well known. So why do so many companies still use project teams? The main reason for this is that project teams are part of the IT culture. Recall the defining characteristic of IT – technology is considered as the center of budgetary responsibility.

IT organizations usually fund something through projects. Build a business model for the project, secure funding for the project, assemble a team, launch the project, and hope no one checks the actual results against the business model, and so on in a circle.

Usually in these organizations the root of the problem is CFO and CIO. The CFO wants to believe that they are financially responsible (which they are not). The CIO wants to believe that he is serving the business by delivering value to his stakeholders (and he isn’t). They are not intentionally trying to harm their company, however, their actions often lead to significant losses, and more importantly, to the state of the company, in which it is ripe for destruction. For this reason, too, it is important to realize that moving from a project team (or feature team) to an empowered product team far beyond product and technology.

It is worth noting that not only large IT companies that have been on the market for a long time face this problem. I have seen a startup with great product skills grow rapidly, but instead of scaling by empowering teams to work hard like the startup did in its early years, leaders try to scale by hiring and leading project and feature teams without realizing that they are losing the most important ingredient of their past years.

Of course, I’m not the only one discussing this fundamental topic. As I said, this is a recognized and widely known problem. Excellent article Thoughtworks wrote about this question a couple of years ago.

Material prepared as part of the course “Systems Analyst. Advanced”. If you are interested in learning more about the format of training and the program, get to know the teacher of the course – we invite you to an open day online. registration here.

Similar Posts

Leave a Reply Cancel reply