把模糊变成清晰：Coda 产品负责人 Lane Shackleton 谈好团队的原则与仪式

Shackleton, who shares a surname with the Antarctic explorer but claims only a distant connection, began his career as a mountain guide in Alaska. He admits he was not the best guide and stopped after a trip to Mount Fairweather, where a client he was roped to fell near the top on the way down. They arrested the fall, but he spent the next six hours thinking that he did not want to die roped to someone he barely knew.

He says the experience still shapes how he works. Guides spend months preparing for a few days of climbing and run through checklists a dozen times to build redundancy into every system. He also remembers a rescue in which a client broke his feet and the senior guide calmly decided to carry him out for miles. The pattern of stay calm, assess, prioritize and act, he says, has a smaller version in building software.

Shackleton started writing down his principles of product management for three reasons. He kept giving the same advice in one-on-ones, and writing forces you to clarify your thinking and invites feedback. He is also frustrated by career ladders with ten or fifteen levels that differ between companies, so he wanted principles that hold for a new PM and a head of product alike. The third spark was Bret Victor's talk "Inventing on Principle", which a Coda designer showed the early company.

Coda put off formal levels for a long time, following advice that introducing them shifts incentives from company-focused to individual-focused. Eventually the team wanted clearer guidance on what growth means and settled on five "role stages", from apprentice to principal. In his rope analogy, a principal is someone who "invented nylon", so the bar at the top is deliberately very high.

The stages are described similarly across roles, are not visible across the company, and compensation is set by a central committee rather than the manager. Shackleton says they introduced this at around 20 PMs and designers.

Shackleton's unifying thesis is that the core job of a product person is to turn ambiguity into clarity. Everything is unclear all the time: your role, the problem, the target customer, which prototype will solve it. The first principle he wrote about is "systems, not goals", illustrated by Jerry Seinfeld in the documentary *Comedian*. After throwing out fifteen years of material, Seinfeld set a goal of building a new hour, but what mattered was the system of writing for an hour every morning and performing at night.

He applies this to customer learning. A team with an OKR to talk to 10 customers might hit it, then drop the goal next quarter, so its learning rises and falls. A team with a default-on habit of talking to customers a few times a week develops strong customer instincts. In Coda's early days a Friday slot for customers was on the calendar, which meant someone sometimes scrambled to have a prototype ready.

Lenny adds parallels from Airbnb's weekly host lunches and from Rick Rubin's book. Shackleton also borrows Rubin's idea of listening: absorb everything a person says, including body language, and switch off the part of you that is already composing a reply. Coda's "walkthrough" ritual applies a beginner's mind by having someone act as a total newcomer while five or ten colleagues watch and fix every problem they see.

Another principle is "cathedrals, not bricks". Shackleton recalls complaining to a mentor at YouTube that his team was underperforming and being asked whether they knew their cathedral. In the parable, three bricklayers describe their job as moving bricks, applying cement, and building a cathedral, and he wants teams to feel like the third. When PMs are busy, it is easy to go task by task and never widen the aperture.

A less obvious lesson is that each person needs to see a different facet of the cathedral. A single vision or strategy document often leaves people unable to find their own version of the broader arc. During big planning cycles Coda pairs a writeup with a metric and directional mocks, such as what a billboard or the homepage might look like, to take the mystery out of where the team is headed.

To develop your own principles, he recommends reading broadly outside product literature, including team sports and storytelling, and noticing what advice you repeat when mentoring others. He praises Matthew Dicks's book *Storyworthy*, whose core idea is that a good story hangs on five seconds of transformation. He adds that you learn a craft by studying the best practitioners and by throwing yourself into uncomfortable situations early in your career.

Shackleton says he picked up a career-growth heuristic from Seth Godin. Moments that make you uncomfortable, or when you think you should not be here or are underqualified, are the ones to seek out because they stretch you and give you a new foundation. A question like "are you growing in your role?" is too ambiguous, he argues, so he asks how many "oh shit" moments you have had in the last six months, year or two years, and what they were.

If the honest answer is that it has been a long time since you were stretched, he says that is worth digging into. Lenny relates this to his own reluctance to start a podcast and recalls the line that the cave you fear contains the treasure you seek. Shackleton points to Ryan Holiday's *The Obstacle Is the Way*, whose idea is to run toward obstacles rather than away from them.

Shackleton says good product starts with noticing, and that Coda studies rituals by asking customers questions, meeting their teams and building new rituals alongside them. His co-founder Shishir is writing a book called *Rituals of Great Teams*, and they host dinners where several companies present theirs. One favorite is HubSpot's flash tags from Dharmesh Shah: FYI, suggestion, recommendation and plea, mapped to a hill-dying metaphor from "no hill in sight" to "you should really trust me".

In Coda docs the tag is a select list next to each comment, so the writer has to ask how strongly they really feel. Without it, a list of 100 comments gets treated as equal and slows everything down, whereas with it a team can see that there is one plea and a pile of FYIs. Shackleton notes that the same vocabulary now comes up in meetings, and Lenny points out that it also helps leaders signal that an offhand remark is not an order.

Another ritual is Catalyst, built to fix two flaws in review forums: standing attendees and single-threaded agendas. Instead, three one-hour blocks a week are held free for the whole company, each topic has a driver, maker, braintrust and interested roles, and the day before, the hold is replaced by specific topics. Several topics can run in parallel because their attendees do not overlap, which raises throughput and puts the right people in each room.

Asked how easily rituals transplant, Shackleton says it depends on your position. A brand-new PM should not remake the head of product's review cycle, but can bring a decision template or a lightweight ritual to their own team. His example is hundred-dollar voting, in which people allocate $100 across a table of problems or themes, which quickly reveals large disagreements and gets the elephant in the room out in the open.

Coda's backbone is Catalyst, tag-ups and a concept called Bullpen, with continual iteration on top. He gives the example of PM lead Nathan, who listed upcoming decisions in a table and let stakeholders react to say they only need notification, have opinions but can proceed, or want to be heavily involved. That allowed him to give his PMs better guidance on whom to involve.

Tag-ups are group one-on-ones with a team and its braintrust, modeled on Pixar's. Shackleton calls discussing project work in one-on-ones an anti-pattern because it creates a game of telephone between the manager and the engineering and design leads. Instead the group reviews metrics, then a table of upvoted topics, so the whole triad, and often sales and marketing, hears the discussion. Coda is also writing a handbook of these rituals with templates.

Shackleton tells the story of skippable ads at YouTube. He had just become a PM shortly after the acquisition, when the site was seen as a home for cat videos, advertisers did not want to talk to YouTube, and the company was being sued by Viacom. On day one he was handed the project nobody wanted: put a skip button on ads and align advertisers, viewers and creators by charging per view. Advertisers and the sales team did not want it, and the thesis was unproven.

His boss Phil Farhi cut short the debate by telling him to test the extremes and start the experiment the next day. The team ran one experiment with a tiny skip button and one with a giant button covering the whole player. Within a few weeks very directional data had given them conviction. Shackleton's lesson is to stop talking and run an experiment, build a prototype, write a doc or make a mock, and he says it applies to leaders at every level.

Lenny compares it to Twitter spending years deliberating over an edit button, and Shackleton adds that things are almost never as bad as you fear.

Shackleton began in tech reviewing AdWords ads by hand, marking them family safe or not, then moved to chat and phone support, where one call might be a Fortune 100 company and the next a psychic or a taxi driver arguing over a keyword. A mentor told him to get customer-facing from the beginning, because you serve a customer throughout your career, even as a CEO. He also learned that most customers do not care about your product, only about outcomes like more phone calls or more people in the store.

He later became a product specialist, one of 15 at Google at the time, sitting on seven or eight core product teams and watching what worked for different PMs, which he calls a masterclass in PMing. Getting his first PM role took at least four or five years, partly because Google then required a computer science degree. Lenny notes that this shows the path does not happen overnight.

For those who want to become PMs, Shackleton says people in customer-facing roles are experts on the customer, which tech organizations undervalue, and that you need a diverse, continuous stream of customer interactions to earn engineers' trust. He and a friend got their shot at PM because they knew the customer well and bridged the gap between what customers said and what to build. He concludes that people should assume nobody cares and write sharply, a point Lenny reinforces with a story about Airbnb hosts who think their home, not the website, is the product.

Shackleton recounts "Tim Ferriss Day" at Coda. A team member named Al Chen, a Tim Ferriss fan, had worked his way to the people around Ferriss and written a doc implementing one of his rituals. One morning traffic and signups spiked, Shackleton assumed it was spam, and the fire alarm even sent everyone outside to investigate on their laptops. They eventually learned they had been featured in Ferriss's newsletter, which taught them the importance of content distribution and publishing flywheels.

He then lays out a history of how work gets decided: PowerPoint in the 1980s, then one-way writeups after Google Docs and Jeff Bezos's memo banning PowerPoint at Amazon, and now two-way writeups where feedback is part of the content. One-way docs leave you wondering who has read them, push discussion into a narrow margin of comments, and often produce a mega-thread on the title.

The alternative uses a "done reading" button, a table where people upvote questions (what Coda calls Dory), and a sentiment table of smiley faces. Shackleton gives an example in which he expected a proposal to sail through, but a quiet lead designer gave it one smiley face, feedback he would probably never have heard otherwise.

Shackleton shares two planning insights that will appear in the Coda handbook. First, OKRs are not strategy, so teams should run a strategy ritual that is distinct from goal and metric setting, whatever framework they choose. Second is Coda's 10% planning rule: do not spend more than 10% of an execution period on planning. Lenny agrees, saying a week of work gets half a day of planning and a month gets about three days.

Over-planning, he says, is an easy and hard-won mistake, because teams feel rushed and stretch planning to three weeks, even though you often cannot know what lies ahead until you launch or learn something.

In the lightning round Shackleton recommends *Turning the Flywheel* by Jim Collins, *Storyworthy*, *Good Strategy/Bad Strategy*, Sam Harris's *Waking Up* and *The Inner Game of Tennis*. He enjoyed *The Last Dance* and is rewatching *Arrested Development*. His favorite interview prompt is "teach me something I don't already know", and he sometimes asks candidates to explain a topic to a grandparent and then to a deep expert. He also writes about reference-check questions.

Recent favorites include the SwingVision tennis app and the Waking Up meditation app. His motto is that the present moment is all we have, plus a mentor's advice to "make things happen". His mother, a psychologist, taught him active listening, which he now thinks of as steelmanning someone's argument. For aspiring climbers he repeats the saying that the safest climber is the one who knows when to come down, and adds that climbing is not a one-way door.