把圈子画大：Julie Zhuo 影响艰难产品决策的五步方法

Julie Zhuo opens by asking how many people in the audience have tried to influence a decision in the past week. She recalls assuming that design leadership was mostly storytelling, then assuming that becoming a founder would let her simply tell people what to do. Instead, she found that founding a company required more influence than ever. The audience poll establishes that most of the room has recently tried to influence a decision.

She presents a prioritization exercise with three doors: an infrastructure rewrite that engineers want, an onboarding redesign that designers want, and a generative-AI feature the CEO wants after talking to founder friends. Audience members vote for each option. Zhuo then reveals that the prioritization choice is not the real question she wants to address.

The real challenge is the process that moves a team from a strong individual opinion to a better collective outcome. She notes that such decisions are hard because many variables and questions collide in every prioritization discussion. The talk is therefore about process rather than about which of the three projects should win.

The first step is to draw a circle. Zhuo tells a story about being at home with her brother: when cousins visit, it is the two of them against the cousins, and when neighborhood kids arrive, the alliance expands again. The point is that people choose where to draw the circle—around themselves or around a larger shared group.

At work, even when people are on separate pages, there is a circle around the company and its success. She suggests opening with lines such as 'what we really want is to make a great product that customers love' or 'it is really important that we hit our revenue targets.' The mindset matters: going into a meeting to prove you are right draws the circle around yourself, while going in to solve a shared problem changes the energy.

Step two is to assume everyone is seeing the truth. Zhuo retells the parable of the five blind men and the elephant, in which one man feels a tree trunk, another leather, another a rope, and each describes a different part of the same animal. With sight, observers can see that all of them are right about something and none of them sees the whole truth.

Disagreements at work usually work the same way. A designer immediately evaluates customer comprehension and aesthetics, while a salesperson immediately evaluates revenue impact; a product leader has to hold these partial truths together. Cross-functional conflicts, such as growth and retention teams optimizing against revenue teams, often reflect legitimately different views of what matters.

Zhuo recommends acknowledging that difference explicitly. A useful opening is to say, 'It really does seem like we see things differently, but we all have something valuable, so let’s put that on the table.' She also suggests calling out in advance what each person is likely to see more easily, which helps people feel heard and makes it easier to consider other perspectives.

Step three casts the group as detectives trying to uncover where each person’s truth applies. Zhuo offers two questions: 'What would have to be true for us to believe we should do feature A?' and 'What would have to be true for us to generally agree that feature B matters more?' If one person advocates A and another advocates B, the second can ask what would convince the B advocate that A is better for the shared goal.

For the infrastructure rewrite, the extreme conditions are clear: performance has degraded badly enough that customers will churn, a major marketing push will bring new users to a buggy product, or engineers are so unhappy with the codebase that morale collapses. Talking about the extremes helps people agree, because reasonable people can agree that those outcomes would be bad. The prioritization question then becomes a shared search for the right balance rather than a fight between factions.

The same method applies to onboarding and generative AI. Onboarding matters if the company is about to add many new users and the product has product-market fit but new users cannot understand how to get value; a generative-AI feature matters if it makes the value proposition two, three, or five times better, or if competitors are doing it and customers might leave. In each case, Zhuo looks for conditions that reasonable people can endorse before debating whether those conditions are true.

Once the group agrees on the scenarios, step four turns the problem into a data question. The key questions are 'How can we know it’s really true that degraded performance will cause customers to churn?' 'What evidence do we have that the new generative-AI idea will be well received?' and 'How can we quickly get signal on whether engineers are fed up with the codebase?'

Zhuo defines data broadly as any information that adds context. It can be quantitative dashboards or ad hoc analysis, but it can also be customer-success conversations, sales interviews, calls with ten customers, or an internal survey. The point is not to demand perfect measurement before acting, but to find the fastest credible way to learn whether the agreed scenario is real.

In the examples, that means checking whether performance has been getting worse and whether it correlates with churn, or asking twenty customers how they feel about recent bugginess. For onboarding, it means asking whether the company will really add many new users, what current and benchmark retention look like, and whether manually walked-through users stick more than users who go through the normal experience. For generative AI, it means prototyping, using ChatGPT to test whether the feature dramatically improves the value proposition, talking to smart customers about five ideas, and doing market research on competitors.

She also cautions that data will never provide certainty. The best a team can get is a little more evidence, and many of the biggest decisions still require a leap of faith. If the team has gathered what it can, or cannot wait for more, the question becomes what to do when disagreement remains.

If the group has drawn the circle, acknowledged partial truths, and gathered evidence but still disagrees, step five is to move the conversation up a level. The question becomes: who is now the best person to make the call? Zhuo finds that people often agree more easily on who should decide than on the decision itself.

The best decision-maker has the best combination of context and skill. Zhuo uses technical infrastructure as an example: she may have context but not the experience to choose the right infrastructure, while someone with skill but no history or data may also be a poor fit. A product leader’s leverage is to nominate the person who fits the specific decision rather than insisting on making every call personally.

That nomination can point to an engineering leader for a technical-infrastructure call or a design leader for a customer-experience call. The nominated person should be clear-eyed and calm, without a bone to pick or a need for revenge, and ideally not so stressed that judgment is compromised. Zhuo jokes about 'founder mode' but says it is also acceptable to nominate yourself, as long as everyone feels they are sharing in the effort to drive the best outcome.

The process does not guarantee that Zhuo or anyone else gets the outcome they wanted. She believes time eventually reveals more truth, so teams should write down what happened: who thought what, who was nominated, and who made the call. Then they should revisit the decision after one month, three months, six months, or a year; Zhuo schedules calendar reminders for herself because different time frames reveal different lessons.

The most obvious lessons concern customers and product levers: what the team learned about customer needs, and whether pricing, onboarding, or power-user features moved the outcome. A deeper layer is measurement itself: teams may discover that what looked like a growth problem was really a retention problem, and later refine that to retention of a particular customer segment that matters most for monetization.

Beyond that, teams can learn how to make decisions better—whether to spend more time gathering evidence or move faster instead of repeating the same conversations. The most underrated layer is the quality of each person’s individual judgment: if an executive is wrong across ten decisions in a row, the company should learn not to trust that person on that dimension, and individuals should also watch for their own biases.

Zhuo recaps the process: draw the circle, assume everyone sees part of the truth, investigate like detectives, turn the question into evidence, and, when needed, turn it into a people question. She also emphasizes revisiting decisions to watch the replays. The five steps are a way to improve the odds and the relationships, not a guarantee of a specific answer.

She ends with the Zen Buddhist concept of mu, which literally means nothingness but points to the idea that the true answer can be vaster than the question posed. The original prioritization question—rewrite infrastructure, redesign onboarding, or add a generative-AI feature—may be too narrow. Three, six, or twelve months later, a great outcome might mean better instrumentation, a different sequencing of all three projects, the discovery of a retention problem with twenty other ideas, or a better process for working together.

She illustrates this with Facebook’s growth story. When growth stopped, Mark Zuckerberg tasked a small group with solving the problem; the team tested hypotheses and found levers, but the durable gift was the process, data-informed culture, and framework that spread to every team. The specific solution mattered less than the capability the company built.

Her conclusion is that problems and decisions will keep coming—tens of thousands of them—but relationships, learnings, people, and wisdom are what last. She argues that the truest gift is learning to solve problems well with people you like, rather than treating every day as a fight. That is what she says teams should optimize for.