First Principles and Scalable Lean‑Agile Implementation in Product Development

Author Introduction

He Mian Best‑selling author of "Lean Product Development: Principles, Methods and Implementation". Senior lean product development consultant focusing on lean delivery, lean startup, innovation and lean product design. Has introduced lean product development at Huawei, Ping An Technology, China Merchants Bank and many startups.

Preface

Today's talk is titled "First Principles and Scalable Lean‑Agile Implementation".

We start with the opposite of first principles – "goods worship" – and illustrate it with a wartime island story.

On a South‑West Pacific island, after the US troops left, the locals began a religious ritual worshipping aircraft as "iron birds" that brought abundant supplies.

They believed that by mimicking the soldiers' actions—drawing "USA" on their bodies, marching with wooden guns, and flipping leaves—they could summon the divine aircraft again.

These rituals persisted unchanged, becoming a religion of "goods worship" that idolizes the planes and the material they bring.

In lean‑agile practice we see similar worship: product managers are called PO, project managers become Scrum Masters, requirements become "stories", and we hold ceremonies like stand‑ups hoping the form will produce results.

Often the form is copied without changing the essence. Successful teams focus on value delivery; unsuccessful ones suffer from various root causes but share the symptom of goods worship—obsessing over form while ignoring substance.

This serves as an introduction to first principles.

1. First Principles 2. First Principles of Product Development 3. Scalable Lean‑Agile Pathways 4. Using First Principles to Evaluate Scale‑up Effectiveness

1. First Principles

We must move away from goods worship and return to first principles, which means getting to the root of things.

The term became popular because Elon Musk frequently cites it, and investors now ask "what is the first principle of this project?"

First principles mean looking at the world from a physics perspective, stripping away appearances to reveal the underlying essence.

Elon Musk’s example: when building electric cars, he ignored the claim that batteries are too expensive and instead calculated the raw material cost of the metals, arriving at about $60 per kWh.

Our task is to approach the cost of raw materials, because everything else is human collaboration that can be eliminated.

Steve Jobs also applied first principles: everything should revolve around the product—company, management, technology, sales, and innovation all serve the product.

Jobs said: "I created the company solely to build products; the company is just a means for creative people to collaborate." and "If we build a great product, users will love it and pay for it, so sales are not a problem." and "I’m not interested in innovation; I care only about great products, and everything else follows."

First principles thus require returning to the essence and building from there.

2. First Principles of Product Development

The fundamental goal of product development is to deliver useful value to the external customer.

We must ensure delivery is smooth, high‑quality, and useful. "Smooth" means the external value flow is uninterrupted regardless of internal processes; "quality" must be met; "useful" means the user cares, is willing to pay, and creates business benefit.

3. Scalable Lean‑Agile Pathways

3.1 Insights from Conway’s Law

Many scaling proposals start with organizational structure, but Conway’s Law tells us that structure determines product architecture.

Conway’s famous law states that the organization’s structure will dictate the communication structure of the product.

Example: a team of 8 programmers built two compilers, COBOL and ALGOL. Because COBOL was deemed more complex, it got 5 programmers; ALGOL got 3. Consequently, the COBOL compiler ended up with five compilation steps and ALGOL with three, mirroring the team split.

Another example from hardware development shows the same effect.

3.2 Focus on User Value to Drive Scale

Starting with organization design locks the product structure. Instead, we should begin with user value and let business needs drive the organization.

Two types of scaling needs emerge: first, breaking down end‑to‑end value streams; second, coordinating teams across layers to ensure alignment.

Breaking the value stream means moving beyond waterfall‑style batch processing to true iterative delivery, avoiding the "Water‑Scrum‑Fall" trap where only a part of the process is iterative.

In large telecom solutions (e.g., Huawei’s VOIP/VOLTE), thousands of people work on many network elements; each element has its own development team, creating a layered demand hierarchy (user demand → functional demand → allocable demand).

3.3 Different Scaling Patterns and Cases

Four common patterns: Fusion, Expansion, Connection, and Hierarchical.

3.3.1 Fusion

Example: an enterprise‑cloud storage department split into front‑end and back‑end teams. By fusing them into a single team and redesigning the board to focus on user stories rather than tasks, the flow became smoother and more visible to product managers.

3.3.2 Expansion

Ping An’s case: the business side created a compressed board that added UAT and production validation stages, making the end‑to‑end flow clearer.

3.3.3 Connection

Complex multi‑site projects (business in Shenzhen, services in Shanghai, applications in Chengdu) were linked via an electronic board that showed value flow while preserving detailed physical boards for task tracking.

3.3.4 Hierarchical

Huawei’s layered product structure required a solution‑level board for planning, a project‑level board for each network element, and alignment of stories across layers to ensure user‑level demand is delivered efficiently.

4. Using First Principles to Evaluate Scale‑up Effectiveness

Measure success by value‑stream metrics such as lead time from demand to delivery, waiting time between development and testing, and cumulative flow diagrams that reveal bottlenecks and improvement trends.

Conclusion

Starting from first principles, we presented four scalable implementation patterns. Scaling should be driven by user‑value needs, not by organizational size, and the simplest sufficient solution should be chosen.

Boards are merely carriers; the real engine is the value‑delivery team behind them.

Modern agile scaling must avoid "goods worship" and return to the core principle of smooth, high‑quality delivery of useful value.