How to Boost Platform Efficiency: Lessons from Youzan’s Mid‑Platform Coordination

Background

In many internet companies a “mid‑platform” (or simply “platform”) is built to increase code reuse and reduce duplicated development effort. As the business grew, the platform was scaled to serve dozens of business domains and sub‑domains. While the platform delivered benefits, it also introduced systemic coordination problems that lengthened development cycles and reduced overall delivery efficiency.

Problems Identified

1. Demand planning difficulty – Each business domain maintains its own backlog, while the platform is split into functional modules (product, transaction, marketing, etc.) that also have independent backlogs. High coupling between domain sub‑teams and platform modules creates cross‑team bottlenecks, conflicting priorities, and mismatched planning rhythms, causing the coordination complexity to grow exponentially as demand increases.

2. Lengthened development cycles – A single business request often requires support from multiple platform modules. If those modules are already engaged with other domains, the new request must wait for the previous work to finish, extending the waiting period and the total delivery cycle (waiting + implementation). This effect is measured by the “research concentration” metric (see https://mp.weixin.qq.com/s?__biz=MzAxOTY5MDMxNA==∣=2455764070&idx=1&sn=8e7e9f6000bd215d7bf08df009134469).

3. Uneven value delivery – High‑priority demands that are not represented in the platform backlog remain unaddressed, slowing progress for certain domains and forcing platform teams into overtime to meet unrealistic expectations.

Attempted Solutions

1. Company‑level backlog mechanism

A LeSS‑style large‑scale Scrum process was introduced. A “High‑Priority Demand Committee” meets monthly, ranks all domain requests, and selects the top 20 items for a company‑wide backlog that becomes the core delivery target (reference: https://mp.weixin.qq.com/s?__biz=MzAxOTY5MDMxNA==∣=2455760399&idx=1&sn=d5d5df2d160ce931c5d827a28c3d61de).

Pros: Aligns capacity with business goals, reduces coordination friction, and concentrates effort on the most impactful work.

Cons: Prioritization focuses on current impact and user count, overlooking emerging domains that may miss market windows.

2. OKR‑based goal alignment

Regular “World Café” workshops let product owners decompose OKRs into concrete projects, present them, and allow platform teams to evaluate whether the request can be abstracted into a reusable capability. Agreed items are added to joint planning (reference: https://mp.weixin.qq.com/s?__biz=MzAxOTY5MDMxNA==∣=2455760329&idx=1&sn=bccdb44fc3291b68b1ccea9a5747bc8f).

Pros: Early detection of infeasible platform support, reducing friction at the goal‑setting stage.

Cons: Relies heavily on product owners’ planning ability; fast‑changing markets generate many ad‑hoc requests that are hard to fit into the plan.

3. Proportional resource allocation

Business domains and the platform agree on a resource‑investment ratio. During monthly planning the platform commits resources up to the agreed quota for each domain’s highest‑priority demands. Requests exceeding the quota are negotiated among domains without platform involvement.

Pros: Guarantees each domain receives a baseline of platform support.

Cons: Simultaneous peaks can overwhelm total manpower, creating “bank‑run”‑like resource shortages.

4. Splitting generic platform capabilities into product features

From a product perspective this clarifies the relationship between platform goals and business objectives. However, architectural and code‑level coupling remains, so the core issue is not resolved.

5. Co‑development (shared repositories and consulting)

To address deeper bottlenecks, the team applied the “Yang Triangle” framework, focusing on three levers: technical framework, tool‑chain support, and proactive initiative. Developers were encouraged to abandon siloed thinking, adopt a business‑goal‑oriented mindset, open platform code repositories for consulting, and allow business sub‑domains to contribute code directly to the platform.

Pros: Business teams can close the loop on their own features, shortening waiting cycles and freeing platform engineers to work on core capabilities.

Cons: Initial learning curve increases development time for business teams, but the cost diminishes as familiarity grows.

Practice Effects

After the first co‑development iteration, the overall delivery cycle (waiting + processing) decreased by 10%, with the waiting period alone reduced by 30%.

Subsequent phases revealed new challenges: differing expectations for engineering quality (e.g., unit‑test coverage), lack of regression control for core code changes, stricter stability requirements, and the learning cost of the platform. The team plans to evolve the co‑development approach to a second version to address these issues.