This is the last article in the Product Organization Mistakes series, in which I explored the most common dysfunction patterns in product organizations and what to do about them.

I was once in a meeting with a client that develops software for notary offices. The company has been in the market for over 30 years and was migrating its product from an on-premises model to SaaS. To do that, they had hired a software development consultancy. At a certain point in the conversation, the project manager from the consultancy told us, very matter-of-factly: “We delivered what was asked. Whether or not it meets your customers’ needs is not our problem.”

I stopped. Took a breath. And thought: that sentence summarizes everything that can go wrong when you treat product development like a project.

What a project team is

A project team is one where the stakeholder defines what needs to be done and the team implements it. The focus is on delivery, not on results. The team is evaluated on whether it delivered what was requested, on time and within budget. Whether what was requested was the right thing to build, whether customers will use it, whether it will generate results for the business: none of that is the team’s problem. It is the problem of whoever asked for it.

This model has its own logic and works well in predictable contexts, with a well-defined scope and a clear definition of done. A construction project is a project. A datacenter migration is a project. But developing a digital product, something that needs to respond to customer needs and business objectives in an environment of uncertainty and constant change, is a different thing entirely.

A product team operates differently. It is given a problem to solve and an outcome to generate. It has the autonomy to decide how to solve that problem. And it is accountable not just for delivering something, but for generating results from its deliveries, for the business and for the customer.

The difference is not subtle. It is the difference between a team that asks “did we deliver what was requested?” and one that asks “did what we delivered generate results?”

The cost of temporary project teams that nobody sees

Beyond this difference in operating mode, with project teams focused on delivering what was asked without caring whether the delivery is generating results, the project model has another hidden cost that often goes unnoticed: the cost of teams that never reach their performance potential.

Bruce Tuckman, an American researcher in group dynamics, described in 1965 the stages a group of people goes through when they start working together. First, the team forms: people get to know each other, understand common objectives, and find ways to work together. Then the team storms: conflicts emerge, the group starts to understand each person’s strengths, and discusses how the work will be done. Next, the team norms: work processes are defined, roles become clear, mutual respect is established. Only then does the team perform: it actually starts to produce and deliver results with the effectiveness of people who know each other well.

The problem with temporary project teams is straightforward: they are dissolved before reaching the performance stage. Or, even more commonly, they are reorganized so frequently that they never leave the forming stage. The organization pays the cost of assembling and reassembling teams repeatedly, and never reaps the benefit of teams that have reached their full potential.

This is not theory. I have real data that illustrates both points, deliveries that were not generating results and the time it takes for a team to perform, with precision.

What happened at Lopes

When I joined Lopes, Brazil’s largest real estate brokerage, to lead the digital transformation, one of the main objectives was to increase the share of sales coming from digital channels. In 2020, less than 20% of sales originated online. Most still came from flyers distributed in the streets, property signs, and visits to show apartments, even as it was becoming increasingly common for people to start their property search on the internet.

Even though this was our main objective, we could not move that number. At that time, more than 60% of the team was made up of professionals from software development consultancies. They were working on three large projects: a new website, a new CRM, and a new app for brokers. Working in project mode, plain and simple.

As I have always preferred internal teams, because they are more connected to the company’s culture, values, and objectives, this situation bothered me. When I ran the numbers, I found that the cost per person for contractors and full-time employees was approximately the same, with employees being slightly cheaper. I went to the board and proposed making the switch.

The response was direct: “Joca, you are the expert. We hired you for this. If you say it is better and, on top of that, cheaper, go ahead.”

It took us about four months to complete all the necessary hires. After reducing the percentage of contractors to under 5%, something interesting started to happen: the number of leads coming from digital channels, which had been flat for over two years, started rising rapidly, doubling in two months.

The chart tells this story clearly. While the team was predominantly contractors, the digital leads line stayed flat, regardless of how many features were delivered. When the team became predominantly internal, the line started climbing.

Number of people and digital leads generated – Lopes 2020-2022

The change was not technological. The website, CRM, and app that were being developed continued being developed. What changed was the team: people who felt part of the company, who understood the business objectives, who had reasons to care about results and not just about delivery.

The cost of starting from zero repeatedly

There is another piece of data from Lopes that illustrates the hidden cost of temporary teams well, this time through the lens of Tuckman’s model.

In 2021, after making the transition to a predominantly internal team, the team went through Tuckman’s stages in a clearly visible way. In the first quarter, the team was forming, with people still getting to know each other, learning to work together, and understanding the objectives. In the second quarter, productivity remained stable but still low. In the third quarter, the team stormed: the number of items deployed per week dropped, conflicts increased, and processes were being adjusted. In the fourth quarter, the team normed and started to perform. Productivity rose significantly.

Items deployed per week – Lopes 2021, with Tuckman stages

This chart shows something that is rarely measured: the time it takes for a team to reach its potential. In Lopes’s case, it was approximately nine months from formation to the beginning of performance.

Now think about what happens in an organization that reorganizes its teams every three or six months. Every time a team is dissolved and reassembled, the clock resets to zero. The team starts over at the forming stage. The organization pays the cost of formation repeatedly, and never reaches the performance stage.

It is a cost that appears in no report. There is no budget line called “cost of teams that never reached their performance potential.” But it is real, and it is enormous.

The project mindset installs itself unnoticed

What makes this pattern especially difficult to fight is that it installs itself gradually and with good intentions.

The company has an urgent demand. It assembles a team to deliver. The team delivers. The demand changes. The team is reorganized to address the new demand. It seems reasonable. It even seems agile. But what is actually happening is that the organization is optimizing for short-term delivery and sacrificing long-term capacity.

And as we saw in the story of the notary office consultancy, when the project model becomes institutionalized, when it becomes the default way of working, accountability for results disappears entirely. The team delivers what was asked for. Whether or not it meets the customers’ needs is not the team’s problem.

That is the highest cost of all. Not the cost of teams that take time to perform. It is the cost of an organization that has stopped asking whether what it is building actually works.

Dedicated teams, real ownership

The alternative is not complicated to understand, even if it is difficult to implement.

Dedicated teams are teams that have continuous ownership of an area of the product or the business. They are not assembled to deliver a project and dissolved when it ends. They exist to solve problems and generate results for customers and for the company, and they are accountable for those results over time.

Operating with dedicated teams allows teams to develop deep expertise in their area of responsibility. People know each other well and work more efficiently. Ownership generates real accountability: the team cares about what happens after the delivery, because it will continue to be responsible for that area. And the accumulated knowledge does not disappear when the project ends, because the project never ends. It evolves.

That is what we saw at Lopes. It was not the technology that changed the results. It was the team’s operating model.

Summary

• Project teams deliver what was asked for. Product teams are accountable for the results of what they deliver. That difference defines everything.
• The project model has a hidden cost: teams that never reach their performance potential because they are dissolved before going through Tuckman’s stages.
• Reorganizing teams frequently is not agility. It is paying the formation cost repeatedly without ever reaping the benefit of performance.
• The project mindset installs itself gradually and with good intentions. The warning sign is when accountability for results disappears, when “delivering what was asked” becomes the definition of success.
• Dedicated teams, with continuous ownership of an area, are what allows product organizations to build the kind of expertise and accountability that generates real results.

Masterclass: Why Strategy Doesn’t Reach the Product

In this 3-hour masterclass, Paulo Caroli and I will present a practical model to connect product vision, strategy, OKRs, and discovery to the real work of product teams.

The goal is to understand how to translate strategic direction into real product decisions.

The Masterclass will be in Portuguese.

More information and registration:

https://gyaco.com/masterclass

Workshops, coaching, and advisory services

I’ve been helping companies and their leaders (CPOs, heads of product, CTOs, CEOs, tech founders, and heads of digital transformation) bridge the gap between business and technology through workshops, coaching, and advisory services on product management and digital transformation.

Gyaco Podcasts

At Gyaco, we believe in the power of conversations to spark reflection and learning. That’s why we have “Product in Focus” (Produto em Pauta in Portuguese), a podcast that explores the world of product management from different angles:

• Mentoring Sessions: In this series, I share real mentoring conversations with product people. One person’s questions are often the questions of many. Together, we explore concrete challenges and turn experience into practical insights you can apply to your own context.
• No Filters: In this series of episodes, Fabio Duarte, Paulo Caroli and I have candid conversations about product, technology and the real tensions we are seeing inside organizations.
• Beyond the Buzzwords: In this series, Felipe Castro and I demystify product terms with real examples from our clients.

Available on YouTube and Spotify. Recorded in Portuguese, with English subtitles on YouTube.

Product Management Books

Do you work with digital products? Do you want to know more about managing a digital product to increase its chances of success, solve its user’s problems, and achieve the company objectives? Check out my Digital Product Management books, where I share what I learned during my 30+ years of experience in creating and managing digital products:

• Digital transformation and product culture: How to put technology at the center of your company’s strategy
• Leading Product Development: The art and science of managing product teams
• Product Management: How to increase the chances of success of your digital product
• Startup Guide: How startups and established companies can create profitable digital products