In April 1968, Datamation, one of the leading technology publications of the time, published an article by Melvin Conway, an American programmer and researcher, with a title that seemed to be about management: “How Do Committees Invent?” The article made an observation that seemed simple but proved to be one of the most powerful in software engineering. Conway observed that:

Organizations that design systems are constrained to produce designs that are copies of the communication structures of those organizations.

In other words, the way we organize our teams determines the way our product gets built.

This observation became known as Conway’s Law, and it applies with surprising consistency across organizations of all sizes and sectors.

Why Conway’s Law matters

Conway’s Law is a description of how things tend to work in practice. Separate teams build separate systems. Teams that do not communicate well build poorly defined interfaces between their systems. Teams organized around technologies build products that reflect those technologies, not the needs of their customers.

Structure creates incentives and constraints that shape decisions in ways that often go unnoticed. An engineer working on a team dedicated to the search portal will naturally solve problems by adding features to the search portal. Not because she is limited, but because that is what falls within her area of responsibility.

When the structure is wrong, it works silently against the strategy.

The Reverse Conway Maneuver

If Conway’s Law describes how structure shapes the product, the Reverse Conway Maneuver proposes flipping that logic: instead of letting team structure emerge organically and then observing the product it produces, you first define the system architecture you want, and then organize teams to reflect that desired architecture.

The idea is powerful. If you want a well-defined microservices system, organize teams that correspond to those services. If you want certain parts of the system to evolve independently, create teams that can work independently. Team structure becomes a system design decision, not an accidental consequence.

The problem is that the Reverse Conway Maneuver, as it is frequently applied, starts from an incomplete assumption: that system architecture is the only relevant factor in defining team structure. System architecture matters, but it is not the only factor that should determine how teams are organized.

System architecture is an important technical constraint. But it is not the only factor. The customer and the business objectives are also extremely important factors. When these are ignored in favor of a purely technical reorganization, the result can be a technically elegant structure that still fails to generate results for customers and for the business.

What happened at Lopes

When I joined Lopes to lead the digital transformation, the Lopes Labs team structure mirrored the systems the team had built. There was a team dedicated to the property search portal, a team dedicated to the web CRM for franchises and brokers, and a team dedicated to the brokers’ app.

From a technical standpoint, the logic was reasonable. Each team knew its system deeply. But from the perspective of the business and the customers, there was a fundamental problem: Lopes operates a three-sided marketplace. On one side, the end customer who wants to buy or rent a property. On the other, developers and property owners who want to sell or rent their properties. Since buying a property is one of the largest, if not the largest, purchase a person will ever make, it is natural to expect the help of a third element: the real estate consultant, which is what brokers and franchisees are.

To generate results in this marketplace, the team needed to understand and solve the problems of each of these actors and the relationships between them. But the system-based structure created an invisible barrier: each team looked at its product, not at the users of the product. And when the focus is the product, the only way to solve problems is by adding features to the product.

This manifested in a concrete way. The team’s main objective was to increase the number of leads reaching brokers as quickly as possible, since the faster a broker contacted a potential buyer, the higher the chance of conversion. The solution the team was developing was a brokers’ app with push notifications. An MVP with 58 defined requirements and features, and another 90 already queued up for after launch.

This was clearly a structural problem: the team was organized around the app, so the solution to any problem ran through the app.

If, instead of focusing on the product, the focus had been on the actor whose problems we wanted to solve, the question would become: how do we get the lead into the hands of the broker as quickly as possible? And then other solutions would become obvious. SMS, for example. Or WhatsApp, which in Brazil has far greater penetration than any proprietary app. Simpler solutions, faster to develop, and probably more effective, but outside the field of vision of a team organized around a specific product.

Reorganizing around users

Before proposing any structural change, I needed to understand how Lopes operated. Only after gaining clarity about the business, the marketplace actors, and the relationships between them was it possible to design a team structure that made sense.

The new structure moved from the logic of systems to the logic of users. Instead of a Portal team, a CRM team, and an App team, we moved to teams organized around the marketplace actors: one team focused on the End Customer, another on Developers and Property Owners, and a third focused on Brokers and Franchisees. Plus a Central Systems team, responsible for the shared infrastructure that supported the entire operation.

The change was made in one week. The first days were turbulent, as expected from Tuckman’s model. But after a month, each team already had clarity on who their users were, what problems they needed to solve, and what results they were expected to generate.

The most immediate result was a shift in perspective. The teams stopped thinking about features to add to existing systems and started thinking about problems to solve for specific users. That shift in perspective, by itself, opened up a much wider solution space.

What the Reverse Conway Maneuver does not resolve

Lopes reorganization was not an application of the Reverse Conway Maneuver in the classic sense. We did not start from the desired system architecture to define the teams. We started from the marketplace users and the business strategy.

That distinction matters. The Reverse Conway Maneuver is a valid and powerful tool, but it answers the wrong question if applied in isolation. The question “what system architecture do we want?” is a legitimate technical question. But it can only be answered well after answering the more fundamental question: “who are our users, what problems do we need to solve for them, and what business objectives do we want to achieve?”

The inverse does not work either. If we only take into account our users, their problems, and the business objectives, but do not consider the system architecture we want, that will come at a price: there will come a point where evolving the system hits significant technical constraints that are very difficult to overcome.

Team structure must reflect both system architecture and the logic of value creation for customers and for the business. When these two factors are aligned, structure works in favor of the strategy. When only one of them is taken into account, structure continues working silently against it.

Summary

• Conway’s Law describes a reality: team structure shapes the product the team will build. Teams organized around systems build solutions within the limits of those systems.
• The Reverse Conway Maneuver proposes flipping the logic: first define the desired architecture and organize teams to reflect it. It is a valid tool, but an incomplete one.
• What it leaves out is the customer and the business strategy. A technically elegant structure that does not reflect the logic of value creation for customers will keep imposing limits on how the product solves customer problems and generates value for the business.
• When the focus is the product, the only way to solve problems is by adding features to the product. When the focus is the user and the expected outcome, the solution space opens up.
• The Lopes reorganization moved from the logic of systems to the logic of marketplace users. The change was made in one week. The impact on how teams thought about their problems was immediate.

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