How to Build a $40 Million Annual Profit Product — My Experience at Microsoft, Amazon, and Baihuihui | FreeS Business School

What's the Right Way to Develop Products?

Traditional product development is costly, slow, and risky. Spending heavily to build something users don't want is a terrifying prospect. So is there a cheaper, faster, less risky approach? Allen Zhang, the creator of WeChat, pointed to "agile development":

"We can come up with unconventional ideas today, see results quickly, ship them fast, validate them, pull them if they're wrong, and iterate the following week if there's room for improvement. It's a process that lets you continuously realize your ideas."

This approach has been around for a while and is widely practiced at Silicon Valley companies like Google and Facebook. George Zhu, CTO of Baichanghui — a FreeS Fund portfolio company — has deep experience with it too. Using this model, he once led a team of eight engineers at Amazon to generate $40 million in annual profit. On June 30, 2017, Zhu shared his hands-on experience at the "Teambition Agile Project Management Roadshow."

In this article, George Zhu draws on his agile development experience to address these questions:

• What is the core of product development?
• Why does your development model make or break a startup?
• Why did Windows Vista, developed over six years, fail?
• Why do product/tech teams and business teams always clash?
• What team size strikes the balance between scale and efficiency?

Featured Guest

George Zhu

Co-founder & CTO, Baichanghui

Previously VP of Product at eLong

Earlier stints at Amazon, Microsoft, and HTC leading teams

Responsible for multiple core product lines

Over 16 years of software R&D and product management experience

From Microsoft and Amazon to Putting 100,000 Venues in Your Pocket

By George Zhu

Source: Baichanghui

I grew up in China, then went to the US for school and work. I was an engineer and product manager at Microsoft and Amazon, then became a professional manager. Along the way, I helped Taiwan's HTC set up a 100-person-plus R&D center in Seattle. Two years ago, I returned to China and co-founded Baichanghui.

To sum up my career: I've led large-scale product development at a Fortune 50 company; expanded into new territory at a growth-stage public company; and taken a startup (Baichanghui) from zero to one. Developing products across these environments, I've had some successes and plenty of failures. I'm glad to share what I've learned.

What Is the Core of Product Development?

At any company, the core of product development is delivery.

No matter how well you do everything else, if you can't consistently ship excellent products, you won't achieve lasting success. Sure, some companies thrive on PowerPoints alone, but they don't last. And I assume that's not what you're aiming for.

For internet companies, the most important output is usually software. Software engineering originated in the US. Over the past 50 years, the industry has distilled a fundamental insight: to complete software development, you essentially have two methods:

• Feature-driven: Ship the product once certain features are implemented. Take WeChat — after all these years, its interface hasn't changed dramatically, but it has quietly integrated more and more features, becoming one of the world's most successful pieces of software.

• Time-driven: Launch by a specific deadline no matter what. Consider a robot toy developed for Singles' Day. Miss that window, and even a great product might fail to hit annual sales targets.

▲ This diagram outlines the 10 stages of a classic software product lifecycle. It requires coordination across multiple departments — from marketing, product, development, and QA to operations and sales. Highly complex.

Why Did Windows Vista Fail?

In the early days of software, a model called the "waterfall method" was dominant. Projects began with decisions made in conference rooms by business, product, and tech teams — to ship a product with n cool features by some future date.

In these rooms, product/tech teams and business teams often clashed fiercely. Here's why:

First, business teams struggle to grasp the complexity of requirements. Adding some buttons to a form seems simple to them, but product/tech teams must consider not just implementation, but maintainability, scalability, and testability. For startups lacking foundational systems, building these auxiliary features can consume massive development resources.

Second, business teams see product/tech teams as overly conservative. A startup's business lead is often an optimist (that's why they chose entrepreneurship), saying: "If everyone just pushes a little harder, we can definitely ship this great product on time." But the product/tech team knows that effort is only half the equation — requirements themselves can completely change in a few weeks. Uncertainty abounds during development.

The conflict ends in compromise: a list of tasks, each assigned a time estimate by product/tech, rolled into a 3-6 month development plan. Execute.

This model produced many excellent products, but also many failures. One failure I personally experienced was Windows Vista, which I helped develop at Microsoft.

Before Vista, Microsoft's Windows XP was a smash hit, breaking sales records after its 2001 release. After XP, Microsoft set an ambitious goal — revolutionize how people use computers with its next OS. Things didn't go as planned. Windows Vista's development stretched six years, with repeated delays, several VPs reassigned, and a forced launch in December 2007. Less than two years later, it was replaced by Windows 7. As of this April, Microsoft announced it would no longer provide "large-scale" maintenance for Vista.

What went wrong?

Many factors, but the critical one: when projects spiral out of control, decision-makers instinctively throw more people at them. But as headcount grows, communication costs explode. This produces two consequences:

First, organizational structure becomes more complex. Decision-makers can't hear from every frontline person directly, so they add layers of product or project managers to gather information and coordinate execution. Decision-makers grow further from the details; error rates in decisions and execution rise.

Second, system design and team communication patterns converge. When team communication grows inefficient, the system architecture built by that team becomes inefficient too.

This happened repeatedly during Windows Vista's development. Eventually, Microsoft had to restructure massively, delay multiple times, and finally ship the product as a stopgap.

How Should Startups Design Their Development Model?

Recognizing the flaws of traditional approaches, leading minds in software began converging on better models. Thus, in 2002, the famous Agile Manifesto was born.

▲ The Agile Manifesto's values:

Individuals and interactions > processes and tools; Working software > comprehensive documentation

Customer collaboration > contract negotiation; Responding to change > following a plan

The Agile Manifesto is a set of guiding principles. It acknowledges the unpredictability of software development and the randomness inherent in the process. It argues that rather than focusing on timelines and output volume, teams should concentrate on improving the development process itself — using iterative, testable, growth-oriented methods to refine the product.

The rise of the internet created more possibilities for agile development. I've been practicing agile at scale since 2006, with some successes.

For example, I led an inventory team at Amazon. Just eight engineers supporting Amazon's global warehousing system, managing 30-plus services, handling peak transaction volumes above 100,000 per second. The team generated $40 million in annual operating profit for the company — and effective use of agile methods was a major reason. We'd have struggled to achieve the same results under traditional waterfall.

Most companies won't — and needn't — grow to Microsoft or Amazon's scale. So for startups, how should we design our development model?

Every company's DNA differs; market environments, product structures, and talent quality differ too. So I don't believe there's one perfect SDLC (Software Development Life Cycle) that fits all. Still, we can borrow from general methodologies when designing our approach.

First, we need to define organizational structure. Here are organizational charts from six famous companies that roughly capture their architectural principles. Among them, Amazon, Google, and Facebook's structures are more applicable to internet companies.

Next, I'd like to introduce Conway's Law, which plays a key catalytic role in agile development. Fifty years ago, Conway proposed several laws about system design from a practical standpoint. Over the past 50 years, they've been validated again and again:

• Communication dictates design. That is, how a development organization communicates determines how the final product is designed.
• A company's organizational structure gets exported to its customers. Especially in large companies, products clearly display the boundaries of internal organizational structures.
• Large organizations collapse faster than small ones. The reasons were mentioned above: larger organizations have higher communication costs; decision-makers add more management overhead, distorting information flow up and down, bloating and complicating systems until they seize up.

These laws have been repeatedly validated over 50 years of practice.

From Conway's Law, we can derive a critical implication: after setting organizational structure, we need to define product development's position within the company.

Two positioning approaches are widely recognized:

Product-oriented teams. The product development department isn't just responsible for feature output and launches; it owns the entire product lifecycle. They don't just help decide "what products can be built and shipped," but meticulously cultivate every stage of the product lifecycle.

IT project-oriented teams. More common in traditional companies. For instance, the company needs an ERP system, so engineers are assembled to build it; after project acceptance, they return to their original teams and resume prior work.

▲ Some comparisons between the two approaches.

In the internet space, I believe the product-oriented approach is more likely to lead to success.

Baichanghui's Agile Development Practice

After defining structure and positioning, how do you build an efficient, flexible team?

First, ensure information flows efficiently.

In traditional companies, information is a derivative of power — having information means having power. But in an advanced internet company, no one should have their contributions overlooked due to information flow problems. This sounds simple; it's hard in practice, and requires buy-in from the highest decision-making level.

For example, Google holds weekly tea sessions where anyone can directly ask the founders questions, including critical strategic ones; the founders answer candidly. To date, this hasn't caused any major leaks.

Second, prioritize written communication when interacting with others.

Early in a company's life, verbal communication is usually most effective. But once teams hit 20 people or more, oral communication becomes complex and inefficient; written expression becomes the better alternative.

▲ Verbal expression (left) and written expression (right) differ in logical rigor and systematic structure.

When you want to understand a topic, a written report usually outperforms a verbal report or slide deck. That's because before describing something in narrative form, the writer must have thought it through thoroughly; the act of writing helps them carefully and systematically consider every aspect of a problem.

Moreover, written communication can easily be organized into a recorded, searchable system. When people disagree about past decisions, they can simply look up prior written records to avoid much subjective misjudgment.

Third, the most effective combat team size is 7-8 people.

Amazon has a famous rule called the "two-pizza rule." Jeff Bezos said: "If a team can't be fed with two pizzas, it's too big." Of course, American pizzas are fairly large — enough for about 7-8 people.

This happens to match the size of a US Marine Corps fire team, or a Chinese army squad. Across multiple domains of human society, practice has shown that 7-8 people best balance team scale and efficiency.

Our company currently has about 80 people. At 8-person squads, that yields 10 teams. Accounting for people participating in multiple projects, the number of collaborating teams grows further.

At this point, a good collaboration tool becomes essential. We currently use Teambition. Its strength is quickly organizing multiple iteration teams around products and versions, effectively tracking and resolving issues in each iteration.

Below is the agile board we use daily. You can define more or fewer stages depending on your company's situation. For us, every task flows through planning, in progress, code complete, testing, and finally release.

▲ Baichanghui's Teambition board, used to track task progress with clear ownership and visibility.

Back to the question of organizing an efficient team.

Efficiency depends on whether the team can consistently find better ways to work. One thing we constantly do is complicate simple things into processes, simplify complex processes, then automate simple processes. This lets us focus our core, most expensive human resources on tasks requiring creativity and imagination. We believe many tasks currently done by humans can be solved with technology.

For example, ten years ago few companies used DevOps. Every company had an operations team that deployed engineers' code to servers, monitored them, and fixed issues when software, hardware, or network problems arose.

Today, more and more companies — especially startups — no longer have such teams. We don't either. So who handles those tasks? The answer: 90% through software and tools, the remaining 10% handled directly by the development team.

Agile development can create a "moat effect" strategic advantage for companies. Because of agile development, we can achieve more output with fewer resources. Only when technology platforms and product platforms are sufficiently modularized and standardized can we provide clearly positioned, distinctly featured personalized products and services for every niche market.

▲ Niche market product strategy.

Whether agile or waterfall, development models aren't decisions made by product/tech teams in a vacuum. For a company — especially a startup — the development model is a matter of life and death. A startup's product line, tech line, PR line, and resource line are all fluctuating wildly, with enormous uncertainty.

The premise of agile development is the team's admission that we can't predict all problems in advance, so we embrace change, trusting that we can iteratively produce products approaching perfection.

▲ Scientific management that embraces change.

That said, agile doesn't mean no time constraints. No matter how well a product is polished, when funding runs out, it's game over for everyone. So I don't believe in purely agile development — time constraints always exist.

Finally, I'd like to share a success story that delivered on both features and timeline.

In 1961, President Kennedy announced to the world that the US would put a man on the moon and return him safely before the decade was out. At the time, no rocket in existence could reach the moon, let alone return. But through national mobilization, the goal was achieved in 1969. What many don't know: the US developed 20-plus systems simultaneously. The one that got Armstrong to the moon and back was simply the most successful among many.

So no matter how complex the system or product, with confidence, a willingness to embrace change, and sufficient effort, there's always a way. Thank you!

---

▲ On Cold-Starting Products: Possibly the Most Honest Share in All of VC

▲ Your Product Is Free — So Why Isn't It Working? | FreeS Fund Free Talk

▲ A Sneeze Infects 5 People — Why Can't Your Product Work After Burning $5 Million?