Recently, I ran a corporate Designing Agile Organizations (DAO) training for a retail bank. Everything went great, and I really enjoyed the process! But that’s not the point here.
On the second day, we covered the module “Products and Product Groups” and got into a debate: what should be considered a real product? One participant brought up Yandex Taxi as an example. There’s an app for passengers. But there’s also a separate app for drivers.
Two different interfaces for passengers and drivers
Are these two different products? Or just one?
In the books Creating Agile Organizations and Agile Organizations Design (rus), I used the following definition of a product:
- The users are real people outside the organization.
This helps filter out fake “products” like backend or platform. These may be important parts, but they’re not standalone and cannot be purchased or used independently. - It addresses pain points and desires.
Commercial organizations engage in economic exchange with the market: they offer products and services that solve problems and satisfy desires — in return for money. - It has unique functionality and parts.
Similar products are grouped into product families. For example, all modifications of the Toyota RAV4 are treated internally as one product and are developed by a single unit. - It has an autonomous business model (PnL/ROI).
A product generates revenue and is managed as a separate business model: it has its own customers, value proposition, partners, channels, relationships, key processes, resources, revenue pools, and cost structure.
Passengers and drivers are part of the same multi-platform (or multi-sided platform) — a business model that creates value by facilitating interactions between two or more interdependent user groups. Both interfaces are part of the same product and the same business model. Thus, the product is transportation and delivery services.
The passenger and driver interfaces are value areas — meaningful parts of the product that serve different customer segments.
Scale your product along Value Areas. A Value Area is a valuable product part that addresses the needs of a customer segment but which has no useful value or identity apart from its inclusion in the product (Value Area pattern).
What could a product group at Yandex Taxi look like?
Possible product group structure
In a multi-team product development, cross-functional teams are grouped around value areas:
- Area “Drivers”
- Area “Passengers”
- Area “Internal employees” (e.g. support or moderation)
The overall product strategy and final backlog ordering are owned by the Product Owner. However, much of that work is delegated to the team (Product Owner Team pattern).
That team includes Area Product Owners (APO), who are responsible for ordering items within their respective areas. This structure keeps the product development aligned with the needs of different user segments while maintaining strategic coherence.
It’s important to stress: the Product Backlog is not tied to individual parts or value areas, but to the product and business model as a whole. Even though value areas have some autonomy, they’re interconnected. Imagine you decide to launch a chat feature allowing drivers and passengers to communicate. This requires work on both interfaces.
That’s why end-to-end ordering at the product level is essential. Without it, it's hard to coordinate the development of interconnected features in a coherent way.