Shreyas Doshi：先想象失败、把完美主义留给少数高杠杆任务

Doshi grew up in Mumbai, where his father ran a business making and marketing spices. As a child he packed spices into boxes and did the grunt work on marketing material, so the line between the family business and home life was thin. He moved to the United States at 21 for graduate study, and after about a month of a computer science PhD he realized academia was not for him and dropped out.

He began his career as an engineer at a couple of startups during the post-dot-com downturn, when jobs were scarce, especially for people needing a visa. On a team inside a larger company, managers kept sending him to customer meetings, and he found he loved understanding what customers were trying to do. For roughly a year he did the product job without the title, working out what needed building and then building it himself.

He eventually judged himself a top-20% engineer who would never reach the top 10%, and he was drawn more and more to product work. He credits the people who gave him a chance to do it. Asked by Lenny about students who want to start in product, he recommends trying engineering first, because engineers on empowered teams can do far more than write code.

Going company by company, Doshi says Yahoo taught him the power of many services under a single account, an idea Google later executed even better. At Google he learned to think big by default. On the ads team there was an unwritten rule that anything unlikely to produce $100 million in revenue was not worth discussing, which focused people on large opportunities, though he notes it also made Google miss some trends.

At Twitter, he saw how sticky a product becomes when network effects combine with genuine product differentiation, since there is still no product quite like it. At Stripe, he says, he saw high energy, sound judgment, low ego and small teams produce "magic", more than anywhere else he has worked. He also adds that bundling accounts, as Yahoo and Google did, can cause painful short-term backlash that nobody remembers later.

From the founders he took more personal lessons. He admired Larry Page's ability to simulate the future, and Jack Dorsey's habit of listening for a long time and then asking one vital question. In one acquisition discussion Dorsey asked how the deal would make users love Twitter more, a question Doshi could not answer because the team had been consumed by metrics and integration. From John and Patrick Collison at Stripe he learned to separate the effort spent building a feature from the effort spent talking about it, and that living your values consistently shapes culture more than posters do.

Doshi noticed that post-mortems produced great insights and wondered why teams must wait for failure to get them. He found the pre-mortem idea in a Harvard Business Review article. Early in a project, the team gathers and the leader opens with a prompt: imagine this launch has failed miserably six months from now, and work backwards to what went wrong. If you do a pre-mortem right, he says, you will not have to do an ugly post-mortem.

The imagined failure is what makes it work. It gives team members psychological safety to raise worries they were reluctant to voice because modern organizations prize optimism, and it brings a sense of catharsis; Doshi says people leave smiling even after an hour of discussing disasters. He also gives teams a shared vocabulary of three labels: a tiger is a threat that will actually kill the project, a paper tiger is a seeming threat that the speaker is not worried about, and an elephant is the thing in the room nobody is talking about.

On running the meeting, he includes people from every function involved and splits very large launches into an engineering session and a go-to-market session. After a quiet period in which people write their tigers, paper tigers and elephants privately, the group shares and each person picks the scariest tiger someone else raised, which works as voting. The leader then prioritizes and creates an action plan, staying accountable for making progress. Doshi notes the point is not to solve every problem but to surface threats no one is discussing, and that it is a low-cost, high-upside ritual.

Doshi describes his first three years at Google, which he calls the most stressful of his career. He worked long hours, his to-do list never shrank, and being a perfectionist made him dissatisfied at the end of every day. The relief came from a framework he built from ideas in a blog post: all tasks fall into Leverage tasks that return 10x or 100x the effort, Neutral tasks that return roughly what you put in, and Overhead tasks that return far less.

Ambitious people, he says, treat all three types the same, and that is the problem. His fix was to take on the few L tasks when he felt most energetic and let his perfectionism shine there, while spending less time on N and O tasks. The same activity can fall into different buckets: a bug report might need a detailed write-up in one case and a single screenshot in another, and meeting notes might deserve an hour of polish after a contentious CEO review but only a quick send after a routine meeting.

Asked which tasks are high leverage, Doshi says PMs usually already know, because those are the ones nagging at them. Strategy is the classic example: people say they lack time, but the deeper fear is that they will not have anything good to say. He has procrastinated on L tasks himself, and offers two tactics. One is "placebo productivity", spending a couple of days on deliberately neutral and overhead tasks until you feel ready; the other is changing location, such as going to a coffee shop, to force a shift in mindset.

Doshi describes three levels of product work: impact, execution and optics. His example is a product review where a PM explains to the CEO why customer service response will be slow at launch, with perfectly rational reasons such as another team's funding. The PM is thinking at the execution level, while the CEO is thinking about the customer experience and the brand. Both sides end up litigating the details without realizing they are at different levels.

He defines optics, in its internal sense, as creating awareness of the impact and execution a team is delivering, and says some of it is healthy because it creates energy and feedback. It becomes harmful when optics turns into the goal, which happens gradually through who gets hired, promoted and praised at all-hands meetings. Praising a well-written status update, he says, signals that status updates are what matter.

Asked whether PMs should default to one level, Doshi says the real value is the shared vocabulary, which lets teams discuss mismatches without pointing fingers. The right emphasis depends on context. An early-stage team with a reasonable hypothesis should mostly optimize for execution, since impact will not show up on a weekly or even quarterly horizon, while a platform team that has disrupted others with outages might need to pay more attention to optics and communication.

Doshi says he realized late in his career as a leader that most execution problems in high-performing environments are actually strategy, interpersonal or cultural problems. The busiest leaders he coached were overwhelmed by optics demands and by an endless game of whack-a-mole with execution problems. His example is two misaligned teams: leaders hold a dozen meetings and create new review processes, when the real cause is that nobody knows the strategy or priorities.

The cause can also be cultural. If teams are expected to optimize mainly for their own OKRs, a manager whose team helps another team for the company's sake may be penalized at the next performance review, and no sync meeting will fix that. A third possibility is plain interpersonal friction between two managers, which a leader should spot and coach them through.

Some problems are truly about execution, such as old infrastructure that cannot handle current usage or a skills gap, for example a zero-to-one PM put in charge of a mature scale initiative. His test for telling the difference is the bandaid: if you apply a fix and it falls off, the problem is probably something deeper. Organizational memory is short, he warns, so teams forget the earlier fix failed and simply invent another meeting.

Doshi says he learned this idea by watching Patrick Collison at Stripe. In a high-leverage role, such as product manager, founder or engineering or design leader, hundreds of tasks will have positive ROI, and you should not do most of them. Because time sits in the denominator of the ROI formula, the way to raise ROI is to work on things that take less time, so teams fill their plates with quick wins and low-hanging fruit and miss the upside elsewhere.

Opportunity cost is the value of the optimal option minus the value of the one you chose. Thinking this way changes the question from "is this a good use of my time?" to "is this the best use of my time?" It shows up most in planning, where five well-defined sure things crowd out two ambiguous ones that could change the trajectory of the business. When he started on Stripe Connect, he says, the team was busy with positive-ROI work, and pushing a big, scary project around flexible marketplace payments turned out to be a huge opportunity.

Doshi does not recommend adding an opportunity-cost column to a spreadsheet, because it is too hard to quantify. Instead, leaders should give teams permission to pursue big bets by setting a rough allocation, inspired by Google's 70-20-10 approach. His example guidance is about 60% on incremental improvements, 30% on one or two big new initiatives, and 10% on stability and infrastructure, and he says teams often surprise him with what they propose within those bounds.

As a bonus sixth idea, Doshi discusses high agency, a term he attributes to Eric Weinstein. He defines it as finding a way to get what you want without waiting for perfect conditions or blaming circumstances. It matters especially for product managers, he says, because they constantly face adverse conditions such as limited resources, legacy infrastructure, staffing issues and customer problems.

He noticed that PMs who surprised him positively exceeded what their credentials suggested, while others with great potential on paper never came close to it. High agency, he concluded, was a big factor. It has three components: strong ownership, creative execution through challenges, and resilience. He believes the idea resonated because it gave people vocabulary for something they had already seen but could not name.