What Lessons Do We Learn From a Year of Building an Education Middle Platform?

Story Beginning

In March 2018 the author became a middle‑platform product manager at NetEase Youdao, tasked with building EduOS – an "operating system" for online education that would provide shared services such as accounts, permissions, video‑on‑demand, live streaming, question banks, and surveys across multiple business lines.

The project faced two major challenges: the middle‑platform concept was new in internet companies, offering little precedent, and existing siloed teaching systems had to be unified, akin to swapping an engine on a flying plane.

The only theoretical foundation at the time was Alibaba’s 2017 book “Alibaba Middle‑Platform Strategy”. After a small internal feasibility team proved the concept, the project was approved.

Why Build a Middle Platform?

Middle platforms enable shared services for companies with multiple products; without multiple products, a middle platform is unnecessary.

They aim to improve development efficiency, which initially may require sacrificing short‑term speed.

When a company expands to a second or third product, two approaches emerge: inherit the existing architecture and gradually evolve the platform, or redesign everything from scratch. The author’s division grew from one to five product lines, each initially built as separate codebases, leading to high maintenance costs and prompting the middle‑platform initiative.

Product Design Perspective

Middle‑platform product managers need a blend of product thinking, technical depth, and UML skills. Their responsibilities include:

Designing user‑friendly features that span front‑end to back‑end, ensuring a good experience for internal developers and end users.

Bridging the gap between product and engineering, often writing pseudo‑code in PRDs to clarify requirements.

Driving adoption across business lines by aligning incentives, offering custom support, and building an ecosystem of early‑adopter products.

An illustration shows the skill matrix for business product managers (market‑focused) versus middle‑platform product managers (technology‑focused).

Technical Layer

The platform was designed as a front‑back‑end integrated service, allowing business products to embed front‑end modules that communicate directly with the platform’s back‑end. Initial architecture required both front‑end and back‑end integration, leading to high coupling and maintenance overhead.

To reduce this, the team switched to a front‑back‑end direct‑connect model, where the platform’s front‑end and back‑end interact independently, and business products only need to integrate at the front‑end layer. This reduced integration cost, isolated platform upgrades, and simplified testing.

Key design principles emerged:

Unified data structures are essential; consistent schemas allow flexible UI changes without breaking services.

Standardized front‑end boundaries balance the need for visual consistency with the diverse requirements of different business products.

Front‑back‑end direct connection minimizes integration effort while keeping the platform’s services stable.

Organizational Challenges

High‑level support is crucial because middle‑platform initiatives often do not contribute directly to short‑term KPI targets and may even hinder them initially. Senior leadership must endorse the strategy and help establish shared interaction, visual, and component standards.

Adoption across business lines relies on demonstrating concrete cost savings, aligning incentives, and sometimes “brain‑washing” product owners with the benefits of shared services.

Choosing the right pilot products is vital; targeting high‑potential, resource‑constrained products yields faster adoption than trying to convince well‑funded flagship products.

Value Quantification

The author proposes a formula to estimate total cost savings:

Total Savings = (a1 * Savings₁ + a2 * Savings₂ + …) - Platform Development Cost - Data Migration Cost - Platform Operations Cost

where a₁, a₂ … are priority coefficients for each business line, and Savingsᵢ is the man‑day reduction achieved by each line after adopting the platform. The formula guides prioritization based on strategic importance, demand reliability, and alignment with platform goals.

In practice, the team used this model as a reference rather than a strict metric, focusing first on establishing reusable design patterns, stable APIs, and migration pathways.

Conclusion

After the platform was discontinued, the author reflects on the personal and professional growth gained: rapid prototyping experience, deeper understanding of the education sector, and valuable collaborations. The narrative underscores that middle‑platforms, when properly supported and strategically scoped, become essential infrastructure for scaling multiple products efficiently.