The Organization Is a Design Problem

We have a strange double standard in product organizations. We insist on user research before building features, but reorganize teams based on gut feel. We A/B test button colors but never test meeting structures. We design products with rigor and leave the organization to evolve by accident.

The result is predictable: the organization becomes the primary constraint on the product. Not the technology. Not the market. Not the talent. The system in which talented people operate is what determines whether great work ships or dies in committee.

An organization is a system. It has inputs (people, capital, information), processes (how decisions get made, how work flows, how quality is defined), and outputs (the product, the culture, the customer experience). When the output is broken, the system is broken.

Design leaders are uniquely positioned to see this because we practice systems thinking every day. We understand that a button isn't just a button: it exists within a flow, which exists within a product, which exists within a user's life. The same nested, interconnected thinking applies to organizations.

A team structure isn't just a reporting line: it determines which information flows freely and which requires a meeting. A planning process isn't just a cadence: it determines whether strategy translates to execution or evaporates into slide decks. A design review isn't just quality assurance: it's a cultural signal about what the organization values.

The most impactful work I've done has never been a single product redesign. It's been the moment an organization starts treating its own structure as a design problem: something to be researched, prototyped, tested, and iterated on with the same rigor we bring to the products we ship. I wrote a book about this.