What sets great teams apart | Lane Shackleton (CPO of Coda)

From an Alaskan mountain guide to the Chief Product Officer of Coda, Lane Shackleton has navigated one of the most unique career paths in Silicon Valley. Having spent over eight years at Coda and previously holding key roles at YouTube and Google, Shackleton has become renowned for his "first principles" approach to product management. He doesn't just manage products; he deconstructs the very nature of how teams operate, communicate, and innovate.

Shackleton’s philosophy centers on a fundamental truth: the primary job of a product leader is to turn ambiguity into clarity. Whether it is redesigning the hated product review meeting or redefining how teams handle feedback, his methods challenge the status quo of corporate inertia. By studying the rituals of the world's best teams—from Pixar to HubSpot—Shackleton has built a toolkit for driving velocity and alignment.

This post explores Shackleton’s core principles for product managers, the specific rituals Coda uses to maintain high velocity, and why the best way to learn is to stop talking and start making.

Key Takeaways

• Systems outperform goals: Relying solely on OKRs often leads to inconsistent results. Establishing "default on" systems creates inevitable progress, similar to Jerry Seinfeld’s writing routine.
• Build cathedrals, don’t just lay bricks: Great leaders ensure every team member sees the grand vision, not just the immediate task. This requires visualizing the end state through mocks, narratives, and diverse media.
• Operationalize feedback with "Flash Tags": Borrowed from HubSpot, this ritual categorizes feedback (FYI, Suggestion, Recommendation, Plea) to prevent teams from over-rotating on minor comments.
• Replace status meetings with "Catalyst": Coda replaced sluggish, single-threaded review meetings with a dynamic system that pulls in only the necessary "drivers" and "makers" for specific topics.
• Learn by making: Debate is often a form of procrastination. The story of YouTube’s skippable ads proves that testing extremes in the real world yields better data than endless theorizing.

Principles of Great Product Management

At the heart of Shackleton’s leadership style is the belief that a product manager's role is to navigate the unknown. Every project starts with ambiguity—unclear roles, undefined problems, and hazy solutions. The best PMs are those who can systematically convert that fog into actionable clarity.

Systems Not Goals

Shackleton argues that while goals set a direction, systems ensure arrival. He draws a parallel to comedian Jerry Seinfeld, who didn't set out with the abstract goal of "writing a great hour of material." Instead, Seinfeld focused on a system: writing every single morning, regardless of the quality, and marking an 'X' on the calendar. This "don't break the chain" method made the outcome inevitable.

In a product context, teams often set goals like "talk to 10 customers this quarter." Once the goal is hit, the behavior stops. A system-oriented team establishes a default-on habit, such as a standing Friday slot for customer interviews. Whether they are ready or not, the customer is coming. This forces the team to have something to show and builds deep customer intuition over time.

"Goals with good intentions don't work... A team that has a default-on system for talking to customers tends to have really good product instincts."

Cathedrals Not Bricks

There is a classic parable of three bricklayers. When asked what they are doing, the first says, "I'm laying bricks." The second says, "I'm building a wall." The third says, "I'm building a cathedral." Shackleton notes that product teams often get stuck in the bricklaying phase, obsessed with execution details while losing sight of the broader purpose.

To counter this, leaders must actively show different facets of the "cathedral." A written strategy document might work for some, but others need to see the directional mocks, the billboard ad for the future launch, or the projected metrics. By constantly reorienting the team toward the cathedral, leaders prevent the work from becoming a series of disconnected tasks.

Rituals That Drive High-Performance Teams

Principles are abstract, but rituals are practical. Shackleton and the Coda team are obsessive about "noticing" effective behaviors in other organizations and codifying them into repeatable rituals. These are not just meetings; they are engineered social constructs designed to solve specific collaboration problems.

Flash Tags: Calibrating Feedback

One of the most corrosive elements of product development is uncalibrated feedback. A senior leader makes a passing comment, and the team interprets it as a mandate, derailing the roadmap. To solve this, Coda adopted "Flash Tags," a concept originally from HubSpot’s Dharmesh Shah.

When giving feedback, stakeholders must tag their comments with one of four levels:

• FYI: Just a thought. No action required.
• Suggestion: A hill I am not willing to die on. Take it or leave it.
• Recommendation: A hill I am climbing. I have thought about this deeply; please don't ignore it.
• Plea: A hill I am willing to die on. Stop the line.

This shared language dramatically increases velocity. A team can look at 100 comments, see zero "Pleas," and move forward with confidence, rather than treating every "FYI" as a blocker.

Catalyst: Fixing the Product Review

Traditional product review meetings suffer from two structural flaws: standing attendees and single-threaded discussions. You often end up with the wrong people in the room (wasting their time) or missing the right people (delaying decisions). Furthermore, discussing one topic at a time creates a bottleneck for the entire organization.

Coda developed a ritual called Catalyst to decentralize decision-making. The structure involves three one-hour blocks per week where the entire company is assumed free. However, there are no standing invites. Topics are added dynamically, and for each topic, roles are clearly defined:

• Driver: Owns the outcome.
• Maker: Doing the work.
• Brain Trust: Essential stakeholders for input.
• Interested: Optional attendees who want to listen in.

This allows multiple, parallel discussions to happen simultaneously with exactly the right people in the room, removing the review meeting as a bottleneck to shipping.

Bias for Action: Learn by Making, Not Talking

Early in his career at YouTube, Shackleton was tasked with a project nobody wanted: skippable ads. At the time, advertisers hated the idea of users skipping their content, and the sales team feared revenue loss. The theoretical debate could have lasted years.

Instead of creating endless slide decks to convince stakeholders, his manager gave him crucial advice: "Test the extremes." The team immediately launched two experiments—one with a tiny skip button and one with a massive button covering the video player. The data arrived within weeks, proving the model worked, and eventually leading to the industry-standard "TrueView" ad format.

The lesson is that debate is often a low-fidelity way to learn. Building prototypes, running experiments, and "making" generates high-fidelity data that cuts through opinion.

"Stop talking about it and go make something... Go run an experiment, go make a prototype, go write a doc. That is much more valuable than pontificating about it."

The 10% Planning Rule

This bias for action extends to roadmapping. Shackleton advocates for the 10% Planning Rule: never spend more than 10% of a cycle's duration on planning that cycle. If you are planning for a week, spend half a day planning. If you are planning for a quarter, spend a few days. Over-planning creates a false sense of certainty and eats into execution time. The goal is to get to the "making" phase as quickly as possible.

The Evolution of Written Culture

How teams write and read is just as important as how they meet. Shackleton outlines three phases of corporate communication history:

1. The Presentation Era (1980s): PowerPoint dominated. Information density was low, and charisma often outweighed logic.
2. The One-Way Write-Up (2000s): popularized by Amazon’s six-pagers. This improved clarity but introduced new problems: "Did the executive read my doc?" and "Which of these 50 comments actually matters?"
3. The Two-Way Write-Up (Today): This is the interactive future. It moves discussion out of the margins and into the document itself.

Using tools like Coda, teams can embed interactive elements like Sentiment Tables (Pulse) directly into proposals. Instead of a messy comment thread debating the document's title, stakeholders vote on a scale (e.g., 1 to 5 smiley faces) regarding the proposal. This democratizes feedback, allowing quiet team members to register dissent without needing to interrupt a meeting or write a combatative comment. It ensures that when a decision is made, the leader has a true read on the room's alignment.

Conclusion

Whether it is through rigorous systems, transparent rituals, or a bias for making over talking, the common thread in Shackleton’s approach is the pursuit of growth through discomfort. He advises aspiring leaders to seek out the "Oh moments"—those terrifying split seconds where you feel underqualified or stretched.

If you ask yourself, "When was the last time I felt stretched?" and the answer is "a long time ago," it is time to change your environment or your approach. Great teams distinguish themselves not by avoiding these difficult moments, but by building the rituals and principles necessary to navigate them with confidence.