This article is part of the Product Organization Mistakes series, which will explore the most common dysfunction patterns in product organizations and what to do about them.

I received a WhatsApp message from someone looking for an Engineering Director for a fintech company. The role sounded interesting: a company in a growth phase, with technology at its core and a focus on new customer acquisition. I asked about the team. She told me: “It’s about 15 people divided across 3 teams to serve Marketing, Sales, and New Business.”

The word “serve,” combined with the teams’ dedication to internal departments, reveals a lot about how the company thinks about its technology team. It is not a product team. It is an internal service team. Each team focused on serving one department.

A pattern that keeps showing up

This model is more common than it looks. The company grows, internal departments start demanding more technology, and the natural solution seems to be creating dedicated teams for each area: one team for finance, one for support, one for marketing, one for sales. Each department gets “its own” team.

At first glance, it looks organized. Internal departments are satisfied because they have dedicated capacity. Leadership can answer “which team handles that?” for any request. The roadmap looks clean: each team has its backlog, and each stakeholder knows who to call.

The problem is that this model optimizes for internal stakeholder satisfaction — not for product and business outcomes.

What changes when the customer is internal

When a team exists to “serve” an internal department, the way it operates fundamentally changes.

The technology team focused on marketing receives requests from the marketing team. The technology team focused on sales receives requests from the sales team. Prioritization is handled by the internal department, based on their current needs. The team implements what was requested. Delivers what was asked for. Gets evaluated on its ability to handle incoming demands.

This way of operating is what I call a feature team, or a project team. The stakeholder defines what to do, and the team implements it. There is no autonomy for the team to decide what will generate the most results. There is no accountability for outcomes, only for outputs.

A product team, on the other hand, 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.

When the “customer” is an internal department, accountability for outcomes disappears. Did the technology team deliver the feature marketing requested? Great, mission accomplished. If the feature generated no results at all, that is marketing’s fault — they asked for the wrong thing.

A concrete example of what this looks like in practice: at Lopes, one of the commercial department’s main objectives was to grow the number of associated brokerages. Since brokers are independent contractors who can leave at any time, the commercial team requested that leads — people interested in buying or renting a property — be distributed sequentially among brokerages. That way, no brokerage would go without leads, which would help retain them. But that solution was bad for both the customer and the company. The real goal is not to distribute leads fairly among brokerages — it is to help the customer find the right property. And to do that, the right approach is to send each lead not to the next brokerage on the list, but to the one best positioned to close that specific sale. A product team would have challenged the request and looked for the solution that generated the best outcome for the customer and the company. A team focused on serving an internal department delivers what was asked for.

The HiPPO prioritization problem

In teams organized around internal departments, prioritization tends to follow what I call the HiPPO (Highest-Paid Person’s Opinion) technique.

The VP of Marketing decides what the marketing technology team does. The Head of Sales decides what the sales technology team does. There is no prioritization process based on evidence about what will generate the most business results. There is political negotiation between departments, where whoever has the most influence gets more engineering capacity.

The practical result: the technology team works hard, ships many features, and generates little real impact. Because the prioritization criterion is not “what will generate the most results?” but rather “what does the most influential internal department want right now?”

What the fintech should actually be looking for

Going back to the example of the person who asked me for a referral: an Engineering Director leading a team organized into department-facing teams will spend a large part of their time managing internal stakeholder expectations and negotiating capacity between departments. There will be little room to build a team focused on product outcomes.

The problem is not the Director. The problem is the structure.

If the fintech is in a growth phase focused on customer acquisition, it makes much more sense to organize teams around product objectives, like acquisition, activation, and retention, than around internal departments. A team focused on increasing new customer conversion rates has a clear, measurable objective directly tied to business results. A team that “serves Marketing” has a task list.

How to know if you have this problem

A few questions that help identify whether your organization has fallen into this pattern:

• Are teams described by the name of the internal department they serve, rather than the product problem they solve?
• Is backlog prioritization driven by internal stakeholders, rather than the team itself based on evidence?
• Is the team evaluated by the volume of requests delivered, rather than the business and customer outcomes it generates?
• When something does not work, is the conversation about “did the team deliver what was asked?” rather than “what did we learn and how do we adjust?”

If most of your answers are yes, you likely have feature teams dressed up as product teams.

Internal-facing teams exist, and they are necessary

Before going further, I need to make an important distinction: the problem is not having teams whose focus is on the needs of other departments. The problem is how those teams operate.

Throughout my career, I worked with internal-facing teams like this in several places. At Locaweb and at Lopes, we called them Central Systems. At Gympass, the name was Crossfeatures, a play on CrossFit and the need to serve the other teams in the company. And at Conta Azul, the most creative with names, we called that team Hubble, because it helped everyone see the Conta Azul universe more clearly, and needed critical maintenance mid-flight to keep it operating at full capacity.

These teams existed, had a clear internal focus, and worked well. The difference was in how they operated.

An internal-facing team that runs like a product team does not simply receive requests and implement them. It develops a deep understanding of its “customers” — the other departments — and connects their needs to the company’s strategic objectives. It does discovery, prioritizes based on impact, and is accountable for outcomes, not just deliveries.

The right question is not “which department does this team serve?” but rather “does this team have the autonomy to decide how to generate results for whoever it serves?”

This is not a naming problem

It is tempting to think the solution is simple: rename the teams. Call it “Growth Team” instead of “Marketing Squad.” But the problem is not in the name — it is in the logic of how the team was created and how it operates.

A team that exists to serve an internal department will keep operating as a feature factory even if you change the name. What needs to change is how objectives are defined, how prioritization happens, and who is accountable for results.

That requires a different — and harder — conversation with internal departments. It requires them to give up control over “their” technology team and start collaborating with a team that has the autonomy to decide how to generate outcomes.

It is not an easy change. But it is the right one.

Summary

• Teams organized around internal departments are not necessarily a mistake, as long as they operate like product teams. The problem occurs when the operating model is one of a feature factory: the department requests, the team delivers, but nobody is accountable for the results of that delivery.
• The warning signs are clear: teams named after the department they serve, prioritization driven by internal stakeholders, evaluation based on delivery volume, and no questioning of whether what was requested will actually generate results.
• The solution is not to rename the teams. It is to change the operating model: give the team the autonomy to understand the problem, connect internal needs to company objectives, and be accountable for outcomes — not just deliveries.
• Internal-facing teams can and should exist. Conta Azul’s Hubble, Gympass’s Crossfeatures, and the Sistemas Centrais at Locaweb and Lopes are all examples of this focus working very well. What makes the difference is whether the team operates like a project team or like a product team.

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.

Digital 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