Youzan's Demand Backlog Management: From Single Product to Multi‑Product Scaling

As business grows, organizations evolve from a single product to multiple product lines, expanding technical teams from hundreds to thousands. This growth makes demand management increasingly complex, requiring alignment of strategic goals with customer needs.

The article explains how Youzan uses OKR to set strategic objectives, treating the derived product backlog as the actionable steps toward those goals. The backlog must align with OKR to avoid wasted resources and timing.

Demand backlog originates from both strategic (top‑down) and stakeholder (bottom‑up) inputs, including external users, customers, partners and internal decision‑makers, product, operations, and service teams. Effective stakeholder expectation management prevents chaotic feedback loops.

The Product Owner (PO) is the sole owner of the backlog, responsible for gathering input but making independent decisions without resorting to voting. The PO must hold a product vision and use the backlog to reflect that vision and the implementation path.

To handle large volumes of disparate information, the backlog serves as an information integration hub, enabling synchronized communication with decision‑makers, operations, and service roles, providing clear expectations and timelines for planned versus unplanned items.

Prioritization balances user value, business value, and cost using techniques such as user story mapping, impact mapping, and MoSCoW. The article emphasizes a "more with less" mindset, focusing on the most valuable items rather than exhaustive lists.

Backlog items for the next iteration need certainty; Youzan employs fixed cycles (monthly planning, weekly iterations, daily stand‑ups) akin to Scrum time‑boxing or Kanban WIP limits to balance long‑term uncertainty with short‑term clarity.

Demand planning should be progressive and detailed only as needed; over‑detailed long‑term planning is risky in a VUCA environment, requiring continual iteration between vision and action.

For small‑scale products, a single prioritized backlog suffices. Large‑scale products require splitting the backlog by business/domain, avoiding functional silos (e.g., separate front‑end, back‑end lists) that create wells and goal loss.

When multiple large products and a business middle platform exist, each product line maintains its own backlog while the middle platform maintains a separate backlog fed by upstream demands, prioritized through combined customer requests, business strategy, and platform roadmap.

Organizational structure influences demand management: functional organizations must retain a user‑centric view and avoid fragmenting requirements across functional teams, encouraging evolution toward feature‑team models.

Tools such as electronic kanban boards visualize the flow, record timestamps and states, generate reports, and enable different role‑specific views (e.g., release calendars for operations).

The author concludes that, after two years of practice, the overall framework remains stable, though continuous improvement is needed in areas like requirement granularity and value‑loop closure.