How great product teams build clarity, rituals, and culture

Executive overview

The core job of a product person is to turn ambiguity into clarity — everything else flows from that. Most teams confuse goals for strategy, and rituals for process. Lane Shackleton, CPO of Coda, shares the principles and rituals that separate high-performing product teams from the rest.

Great teams build systems, not goals — and orient everyone toward the cathedral, not the bricks.

Systems, not goals

• Jerry Seinfeld didn't rebuild his comedy set by setting a goal — he wrote every morning and performed every night. The goal was secondary.
• Teams with a customer-talk OKR often stop talking to customers the next quarter; teams with a default-on system for it develop lasting instincts.
• Coda held a standing Friday customer slot from early days — the calendar pressure forced readiness, and the habit built product intuition over time.
• Ask not "are you growing?" but "how many oh-shit moments have you had in the last six months?" — moments of feeling underqualified are the clearest signal of growth.

Cathedrals, not bricks

• A brick-layer describes the task; a cathedral-builder describes the mission. PMs who stay execution-focused risk leaving their teams without a sense of purpose.
• Showing vision through only a write-up often fails — people need to see their version of the cathedral. Pair the write-up with a metric, directional mocks, and a sense of what the product will look like.
• Different people need different facets of the vision; showing all sides removes the mystery and creates alignment.

Proactive, not reactive

• Learn by making, not talking. At YouTube, skippable ads could have been debated for years — instead, a single experiment with a tiny skip button and a giant skip button resolved the question in weeks.
• Test the extremes first. Seeing upper and lower bounds fast is more valuable than extended debate.
• This principle applies at every level — IC PM to CPO. Always be putting ideas out there, not just discussing them.

Principles for developing principles

• Read broadly outside of tech. Sports, storytelling, and craft — not PM literature — tend to generate the freshest thinking.
• Notice what you say repeatedly in one-on-ones. Recurring advice is a signal of a deeply held belief worth formalising.
• Find the best in a given craft, unpack what they do, then throw yourself into uncomfortable situations to practise it.

Role stages at Coda

• Five levels — apprentice, practitioner, career, principal — applied consistently across product, design, and engineering.
• Rope metaphor: apprentice learns about rope; principal invented nylon. The bar at the top is intentionally aspirational.
• Levels are not visible company-wide. Compensation is set by a centralized committee, not managers — removing individual-level incentive distortions.
• Coda delayed introducing ladders for as long as possible, acting on advice that levels shift focus from company to individual.

Flash tags — calibrating feedback weight

• Dharmesh Shah's system from HubSpot: four tags signal how strongly the giver stands behind a piece of feedback.
• FY (for your information): take it or leave it, no hill in sight.
• Suggestion: I'd do it this way, but I won't die on this hill.
• Recommendation: I've thought hard about this — don't ignore it.
• Plea: used rarely; this is a real hill, trust me.
• In practice: a feedback table with a dropdown, so the giver has to consciously decide how strongly they feel. Forces calibration. Used verbally in meetings too — "is this a recommendation or a plea?"

Catalyst — solving the review meeting

• Most review forums suffer from two problems: standing attendees (wrong people in the room) and single-threading (bottlenecks velocity).
• Catalyst replaces the traditional review: three one-hour blocks per week, whole company kept free. Topics are added dynamically; multiple topics run simultaneously if attendees don't overlap.
• Each topic has four roles: driver, maker, brain trust, and interested — transparent, so anyone can self-select in.
• Result: higher throughput, right people every time, clear decision ownership.

Tag up — replacing the one-on-one bottleneck

• Discussing project work in one-on-ones is an anti-pattern — the engineering lead and design lead aren't in the room, and fidelity degrades through retelling.
• Tag up is a group one-on-one with the core triad (PM, design, engineering) plus relevant stakeholders, held weekly.
• Anyone can add a topic; topics are upvoted and the table self-sorts. The team addresses what's most on people's minds.
• Modelled on Pixar's brain trust concept — a small, trusted group with shared context.

$100 voting

• A planning ritual: list problems, solutions, or themes in a table. Each person allocates $100 across them.
• Instantly surfaces disagreement — a wide spread on one item means it needs discussion; consensus on another means move on.
• Low barrier to run; works at IC level without needing authority over the whole planning process.

Two-way write-ups

• Historical arc: PowerPoint → one-way prose docs (Amazon's six-pager) → two-way write-ups.
• Problems with one-way write-ups: unclear who has read the doc, discussions buried in comments, mega-comment threads on the title as a stand-in for overall feedback.
• Two-way write-ups add: a done reading button (track readership), a Dory table (upvotable questions, so the most important rises to the top), and a sentiment/pulse table (how does everyone feel overall?).
• The sentiment table surfaces quiet dissenters — people who wouldn't speak up in a meeting but will register a single smiley face.

Strategy and planning

• OKRs are not strategy. Keep strategy discussions and OKR-setting in separate rituals — conflating them is a common mistake.
• 10% planning rule: never plan for more than 10% of the execution period. One-week sprint → half a day of planning. One month → roughly three days.
• Planning more than 10% usually means planning before you've learned anything from execution.

Career development

• The oh-shit moment test: if you can't recall a moment in the last year when you felt underqualified to be in the room, you may not be growing.
• Being customer-facing early is underrated. PMs who know the customer best earn trust from engineers and leadership without needing titles.
• Take the transition slowly. Four to five years in adjacent roles before PM is normal — deep customer knowledge is the lever.
• Mentors matter: one piece of advice Lane carried — start customer-facing from day one, because you're serving a customer your whole career.

Building and sharing rituals

• Rituals are worth cataloguing and sharing. Coda hosts "rituals dinners" — three or four presenters share what they do and why.
• The best rituals are noticing-driven: spot something in a customer interaction, probe it, build on it.
• A handbook of rituals (covering Catalyst, decision rituals, planning, roadmaps) was in development at time of recording.