Owning the product service, not the page

Working with developers often involves a common issue called page ownership. Developers prefer to keep others away from the pages they have developed so that they can take credit for their work.

In a large application, multiple developers are needed to work on various features. To manage them effectively, they are divided into small teams, each with dedicated managers and leads. The application is then broken down into smaller segments to distribute the work among the teams.

The Problem with Page-Based Ownership

This approach has its downsides. Developers maintain their own codebase and coding style, and the product is segmented based on pages such as the Homepage, Inventory page, Product Page, Report page, etc. The teams mistakenly believe they own the pages themselves, rather than the services provided by those pages.

This misunderstanding creates challenges for designers:

1. They establish boundaries on global pages like settings and notifications, creating separate pages or tabs for their own content. This unnecessarily complicates the product navigation — users expect a cohesive product, not individual team products.
2. Designers have to collaborate with multiple teams for a single feature. For example, if a designer wants to display new product details, they would need to make changes across the "product page," "order summary," "search," and "homepage" — each owned by different teams.
3. Each team has its own priorities and availability, making it challenging to implement a feature seamlessly. Features often end up partially implemented, and users have to wait for missing information.

A Better Team Structure

To address these challenges, I propose the following:

1. Establish a dedicated pattern library team. This team focuses on creating and sharing reusable design components with the rest of the teams. Designers provide all the necessary details to build a component once, eliminating the need to repeat the same information with individual developers.
2. Teams should own a product service, not a specific page. For example, they own the "payment and order services," not just the "checkout" page. They are responsible for the "product details service" across the entire application.
3. Allocate a dedicated team for common services like notification, settings, and reusable global data. Team size and development time should be flexible depending on feature requirements.