Six Principles to Build a Great Product

This is a redacted excerpt from an internal letter I wrote, with all sensitive information removed or masked.

To stress it again: our strategic principles are built on working out how to play to our strengths and avoid our weaknesses, how to make trade-offs between goals, and how to build a chain of interlocking moves.

Principle 1: Step by Step

The core of going step by step is this: as we make progress module by module, we must remember to keep switching perspectives and make sure we haven’t thrown away the advantage of our integrated ecosystem. If the point of splitting up the different businesses in the past was to stop us from tripping over our own feet and holding each other back, then the point of going step by step on any one product now is to make sure, at every step, that we haven’t pushed modular thinking to an extreme and ended up each going our own way. Going step by step makes sure we are building a chain of interlocking moves, not charging ahead with our heads down and losing our objectivity.

With every major feature update or user-growth plan, we have to ask ourselves, rigorously: Is it connected with the traffic side? Is it connected with the creator-economy side? Does it make use of the advantage of our integrated ecosystem? Does it lay the groundwork for integrating the ecosystem later?

Making sure every step is closely coordinated with the other business lines has a cost, and we must be clear about that. Put bluntly, when one business line flops, it drags the others down with it. This means we may have to live with not expanding module by module as fast as we could, but we must gradually build the ability to run more complex closed loops. We need to firmly believe that if we hold to the one-step-one-loop path without wavering, the advantage of our integrated ecosystem will only grow over time, and it will become our core moat.

The step-by-step principle is also an important rebuttal to the overly hasty expansion strategies of the “quick victory” theory. We must never let performance targets like MAU and DAU go to our heads. Always remember: 10 users who love you matter far more than 100 users who sort of like you.

Using the advantage of vertical integration in one area means this: when our ecosystem as a whole is weaker than our rivals’, we make the battlefield smaller and concentrate our strength there, so the weaker side can beat the stronger one.

Principle 2: Proximate Objectives

An important duty of any leader is to absorb a large part of that complexity and ambiguity, passing on to the organization a simpler problem—one that is solvable. Many leaders fail badly at this responsibility, announcing ambitious goals without resolving a good chunk of ambiguity about the specific obstacles to be overcome. To take responsibility is more than a willingness to accept the blame. It is setting proximate objectives and handing the organization a problem it can actually solve. — Good Strategy, Bad Strategy

Goals that are too grand bring enthusiasm, but they also bring confusion and fear. If we set only big-picture goals and no proximate objectives, our engineers won’t know where to start. We need to give the frontline engineering teams the power to make product decisions, and at the same time greatly reduce the ambiguity of the situation they make those decisions in. The more our goals are broken down to look like tasks, the better.

Another big benefit of setting proximate objectives is that it lets us motivate the team in time. Product competition is a protracted war, and a protracted war means we can’t expect to keep getting lots of big positive feedback from the market. It is bound to be a war full of hardship and negative feedback. Setting one proximate objective after another, and motivating the team to reach them, gives the team very good positive feedback and lifts its morale. This matters especially in a protracted war.

Principle 3: Keep Going to the Market

90% of product ideas are stupid. It all comes down to whether you can find out faster than others that they’re stupid. — Marc Randolph, Co-founder of Netflix

Going to the market again and again has three big benefits:

• It checks whether we are building behind closed doors, making things other people don’t necessarily need.
• It uses what we’ve just built to probe what the market really needs (scout thinking).
• It tests whether our own team is reliable.

Building products is basically a process of running social experiments. There has never been a genius product manager who made something everyone needed but nobody had thought of. The market is really our lab, and how fast we get results out of the lab is what will set us apart from our competitors. Mark Zuckerberg once said that building products is a turn-based strategy game, and the secret to winning is to ship fast so you get more turns than everyone else. The truth is: speed up the process of exposing problems and increase their exposure, so people have to take responsibility for what they make, and everyone has to be tied closely to the situations where the things they make get used.

Getting feedback from the market is an art too. We can’t forget our big-picture strategy and rush to build feature X as soon as a user says they need it; that would have us running around like headless chickens. Nor can we follow only our own urge to build and ignore the market’s feedback completely, with our eyes shut and our ears stopped. There is no standard answer to this. The only way out is to keep going to the market more often and faster, reduce the bias in our feedback, and understand where the market’s real core needs are.

Principle 4: Build a User Culture

Once we understand why product competition is bound to be a protracted war, we quickly realize that what we need is a rock-solid, excellent team to carry out this mission. As the part above about the three stages of competition said, we are still early in stage one, and this is not the hardest it will get. The competition ahead will only get bloodier and more hand-to-hand, and holding on to our drive will matter even more.

Any team member who pays no attention to users, doesn’t care where the business is going, or isn’t willing to stay for the long run will drag the team down someday. That said, building a great team is also a protracted war, and rushing to replace people often is the same mistake of counting on a quick victory. But we must treat building a great team with real seriousness and urgency. We need to see clearly that a team full of people who don’t understand users will never get far. So pushing a user culture, hard and in earnest, is in no way optional; it is a must.

Why do we have to push a user culture, that is, why must our development team understand users so well?

• If we are going to give frontline engineers decision-making power (and we must), then those engineers must understand users’ needs very well. Otherwise they’re just copying the PRD by rote, which is no different from building behind closed doors.
• Get rid of every go-between sitting between engineers and users. A go-between does nothing except add extra burden and noise to the flow of information.
• For Principle 3, “Keep Going to the Market,” the most sensible approach is to make everyone build in public and answer questions and handle bugs directly. More importantly, if an engineer can’t clearly explain the feature they built, or users don’t understand it, then you need to know what it is you built and why it doesn’t work well, and understand deeply what your feature actually does for users. Only once we’ve done this can we give engineers decision-making power.

Principle 5: Stay Objective

What a protracted war tests most is our state of mind. We can’t be pessimistic and feel victory is hopeless, and we can’t try to play the hero with our numbers and be overly optimistic about the situation. To keep a sound judgment of the situation and a good state of mind, we must remind ourselves to stay objective.

See the Gap Objectively

We must always stay alert to what competitors are doing and how far they’ve gotten. As much as possible, we should try every competitor’s product update ourselves and look at the market’s response, so a competitor’s smoke-screen update doesn’t throw us into disarray. We also need to keep doing thorough research on the industries upstream and downstream of our competitors, so we don’t get overly optimistic about the market’s prospects or the difficulty of the competition, and so we don’t build features in an already saturated market while thinking we’re innovating.

Recognize That Things Twist and Turn

Things move back and forth and twist and turn; they don’t go straight to where we want. We’re not gods, and we don’t know what the right road looks like. All we can do is keep trying and failing (by going to the market) and keep adjusting our direction. Never fall into the student mindset that doing A will get you B. A new feature won’t necessarily get used, and there can be many reasons for that: we misjudged the need, the product wasn’t good enough, and so on. What we can do is try and fail as widely as possible at the lowest possible cost.

Always remember: negative feedback is still feedback. And among negative feedback, being scolded by users is better than dead silence; at the very least, it proves that we defined the need reasonably.

Principle 6: Stay Alert to Opportunities

Over the long run, things grow along a compounding curve. Over the short run, they grow in waves, in small, intermittent bursts.