Product vs. Project Teams
I should have written this article two years ago, just after I published Product vs. Feature Teams.
I suspected then that I should follow up that article highlighting the difference between product and project teams, but in truth I fell victim to wishful thinking.
I really wanted to believe that it was no longer necessary to continue to make the argument that project teams are bad. Just like I wanted to believe nobody would vote for an obvious fraud, or that the people would follow the science when it came to their health, or that Facebook would do the right thing.
Unfortunately, wishful thinking doesn’t change reality.
My SVPG partner and EMPOWERED co-author Chris Jones shared with me recently that he continues to encounter project teams, but I didn’t want to believe it was still that prevalent.
It’s not that I haven’t written about the problems with project teams, it’s just that many of those articles are more than ten years old, and I really wanted to believe we were past that.
This topic is of course related to the difference between product and feature teams. The difference between a product and feature team is essentially about empowerment. The difference between giving a team a problem to solve, versus giving them features to build.
However, the difference between a product and project team is essentially about ownership. The difference between a team taking responsibility for an outcome, versus a team just there to deliver a project (output), and then move on to something else.
In lean startup lingo, a product team is durable. It is long-lived (usually 1-2 years at a minimum).
In contrast, a project team exists for the duration of the project itself. This is why project teams are sometimes referred to as “the pool model.” Engineers are drawn from the pool to work on the project, maybe for a week or a month or two, and then once the project is released, they go back to the pool to be reassigned to some other area.
The biggest myth surrounding project teams is that this is somehow more efficient because every engineer is “fully utilized” on the most important project at the time.
If you’re working on something trivial, such as building brochure web sites, then sure. But I have never worked with a single company building trivial things.
Tech product companies build things that are anything but trivial. In fact, it’s normal for an engineer to need several months to learn the enabling technology, the underlying architecture, the relevant code base, and the domain well enough to play the key role they need to play. The same learning curve applies to designers and product managers.
The concept that any engineer or designer or product manager can easily and instantly switch between major areas and be expected to innovate defies reality and goes way beyond wishful thinking.
And that’s just talking about velocity. Things get even worse if you try to talk about actually creating something of real value, not to mention innovating on behalf of your customer. Not only do the people on the project team barely know the code base, they barely even know their own teammates, so there’s little if any of the trust that’s so necessary for real collaboration and problem solving. And they know even less about the actual customers. Good luck trying to find missionaries willing to work in this model.
More generally, one of the things we learned many years ago is that success does not come from projects, but rather from continuously working and iterating on an area until we achieve the necessary outcomes.
The signs of project teams are plain to see: teams of mercenaries, slow velocity, little to no innovation, ballooning technical debt, no ownership of results, orphaned projects and blame directed everywhere.
Maybe you’ll be able to get back to this project at some point in the future, but that’s far from assured, and even if a follow-on project is approved, who knows if the same people will be assigned?
These deficiencies are long established and well known. So why in the world do so many companies still use project teams?
The main reason is that project teams are part and parcel of the IT culture. Remember that the defining characteristic of IT is treating technology as a cost center.
And the classic way IT organizations fund things is by project. The old, provide a business case for the project, get funding for the project, staff the project, ship the project, hope nobody checks actual results against the business case, rinse and repeat.
Usually in these organizations, the root of the issue is the CFO and CIO. They are two sides of the same coin. The CFO wants to believe she is being fiscally responsible (she’s not). The CIO wants to believe she is serving the business by delivering for the stakeholders (she’s not).
They are not intentionally trying to hurt their company, but nevertheless this leads to epic amounts of waste, and more importantly, makes the company ripe for disruption.
This is also why it’s so important to realize that transforming from project teams (or feature teams) to empowered product teams goes well beyond product and technology. In this note alone you can see how it impacts finance as well as the business owners/stakeholders.
It’s worth pointing out that it’s not only big, old, IT style companies that have this problem. I’ve seen the situation where a startup with excellent product skills has grown rapidly, but instead of scaling by empowering teams to work much as the startup did in its earlier years – among the purest forms of empowered product teams – the leaders instead try to scale by staffing and directing project and feature teams, not realizing they are losing the most important ingredient from their earlier years.
I’m certainly not the only one to observe and write about this fundamental topic. As I said, these issues are well-established and well-known. Thoughtworks wrote an excellent summary a couple of years ago.
