This is one of the most common topics in my consulting sessions, how to best organize a product development team. It’s also one of the most requested modules in Gyaco’s Product Maturity Program.

Because of that, I decided to write my fifth book, titled “Designing Product Organizations: How Strategy Defines the Structure of Product Development Teams.”

The book’s central thesis is:

Product organizations should be designed around strategy first, and systems architecture second. Strategy defines what needs to be built. Architecture defines how it can be built. Ignoring either one will work against you, but getting the order wrong will too.

By integrating team structure with product vision and strategy, this book aims to give leaders a systematic approach to designing product organizations capable of sustained performance.

Who this book is for

If you’re a founder or CEO, this book will help you understand why your product organization might be struggling to execute its strategy, and what to change before the next reorg makes things worse.

If you’re a CPO, CTO, or head of product, this book offers a systematic approach to designing and evolving your organization as your product and strategy change.

If you lead people operations or HR, this book will help you understand what product organizations actually need from a structural standpoint, and why the design decisions made here have consequences that reach well beyond the product team.

If you’re a product manager, designer, or engineer, this book will help you understand the forces shaping the structure around you, and what good organizational design looks like from the inside.

How this book is structured

Part I: Why product organizations fail

We start by examining why so many product organizations fail to deliver what they’re capable of, and why the most common responses to that problem tend to make it worse.

The first chapter opens with one of the costliest and least visible mistakes in product organization design: structuring work around temporary, project-based teams instead of persistent, dedicated product teams. In this model, people get assigned to a project, deliver it, and move to the next one. There’s little ownership, little accumulated learning, and little opportunity to develop the deep expertise that makes teams genuinely effective. The organization keeps rebuilding what it just lost, institutional knowledge, unwritten rules, trust, deep understanding of users, things that only come with time, and rarely notices the price it’s paying.

The second chapter examines an equally common and equally damaging pattern: organizing teams around internal departments instead of customer problems. When a team exists to serve Marketing, or Sales, or Finance, it stops being a product team. It becomes a feature factory, implementing whatever it’s asked to build, with no autonomy to question whether what was requested is actually what should be built. The internal department defines the work. The team delivers. No one is responsible for knowing whether it generated any result.

The third chapter examines what happens at the leadership level when CTO and CPO operate as two separate departments instead of co-leading a single product development team. When that split becomes structural, separate budgets, separate agendas, separate cultures, the consequences ripple through the whole organization. Product loses its connection to engineering. Engineering loses its connection to the customer. And when the tension becomes unsustainable, it’s almost always the product function that gets dismantled, leaving the organization even more vulnerable to the feature-factory dynamic described in the previous chapter.

From there, we examine how Conway’s Law shapes both systems architecture and the communication structures within teams, and why bad organizational design compounds over time.

Part II: Strategic context for designing product organizations

In this section, we cover the strategic elements that shape how product organizations operate: product vision, product strategy, outcomes, strategic bets, and discovery and delivery. Together, these elements define how organizations translate strategic intent into product decisions and day-to-day work.

We also examine how organizations manage their product portfolio, and why portfolio logic plays a critical role in organizational design. Products within a portfolio tend to have different strategic roles and sit at different stages of maturity, from early bets to growth engines, to mature cash cows and legacy products. Understanding these roles matters because portfolio logic shapes how organizations allocate investment, attention, and teams.

Part III: Designing product teams

With the strategic context established, we move to designing the teams themselves. This section’s central argument is that product teams should be organized around one of four logics: product, user, journey, or objective. The choice between them isn’t arbitrary, it follows directly from the vision and strategy defined in Part II. We also examine structural teams, like platform, data, and security, that support the broader product development environment without owning user-facing outcomes.

Part IV: Evolving the organization

Product organizations aren’t static. As products evolve, markets shift, and technology advances, organizations have to adapt their structures. In this final section, we explore how product organizations evolve over time: leadership structures like CTO, CPO, and unified CPTO roles; the impact of AI on team structure; and practical challenges like managing interdependencies, scaling internationally, reorganizing teams, working with external development partners, and building sustainable career paths for product managers and product leaders.

The goal of this book isn’t simply to describe organizational models. It’s to help leaders design product organizations capable of translating strategy into sustained product success.

I want to hear from you

I put together a quick survey with ReveLumi, the continuous qualitative research company I co-founded with Anderson Borges. It’s a conversation run by an AI agent right on WhatsApp, takes just a few minutes, no form to fill out.

Take the survey

Every contribution helps make the book more complete.

Scale your customer research

In a world where AI levels the playing field, deep customer knowledge is the one asset your competitors can’t copy. ReveLumi was built exactly for that. Learn more at revelumi.com.

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’ve created “Produto em Pauta” podcast, with new episodes every Thursday.

The main series is called Mentorias: coaching conversations with product professionals, built on the idea that one person’s questions are often the questions of many others. We explore concrete challenges and turn experience into practical insights you can apply in your own context.

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