phronesis 1.0.0

package/templates/codex/seed/leadership/talent-density-is-the-master-variable.md

@@ -0,0 +1,39 @@
+---
+type: codex-principle-seed
+name: talent-density-is-the-master-variable
+title: Talent Density Is the Master Variable
+created: 2026-06-24
+exposure: shareable
+stance: adopted
+provenance:
+  authored_by: seed
+---
+
+> **Talent density is the master variable: in creative work the best are many times more
+> productive than the average, so one outstanding person outperforms two adequate ones —
+> and the bar a team tolerates becomes the bar it meets.**
+
+In procedural work the best are perhaps twice as good as the average; in creative,
+inventive work the gap is an order of magnitude. When individual output varies that
+widely, *who* is on the team dominates *how* the team is run — density beats process, and
+headcount is not the lever it appears to be. A high performer raises everyone around them;
+a tolerated low performer drags the whole team down and teaches it what is acceptable. The
+discipline is to raise talent density faster than complexity grows, so the organization
+can run on judgment and freedom rather than on rules written to contain its weakest work.
+
+The mechanism that maintains density is honest assessment: would you fight to keep each
+person if they tried to leave? Anyone you would not is a slot better opened. This only
+works alongside psychological safety — high standards without safety produce fear and
+politics, not performance. High standards and safety together produce the candor-driven
+performance the whole model is after.
+
+*Diagnostic: would you enthusiastically re-hire everyone on your team today? Each person
+you would hesitate over is quietly teaching the rest where the real bar sits.*
+
+*Source: Reed Hastings and Patty McCord.*
+
+## Interview Prompt
+
+If everyone on your team had to re-interview today, who would you fight hard to keep — and
+what is the presence, or absence, of your strongest people teaching everyone else about
+the standard?

package/templates/codex/seed/leadership/under-pressure-calm-is-contagious.md

@@ -0,0 +1,36 @@
+---
+type: codex-principle-seed
+name: under-pressure-calm-is-contagious
+title: Under Pressure, Your Calm Is Contagious
+created: 2026-06-24
+exposure: shareable
+stance: adopted
+provenance:
+  authored_by: seed
+---
+
+> **Under pressure your own state is contagious before your words are. Steady yourself
+> first — the room catches your calm or your panic within the first minute.**
+
+The highest-stakes rooms are lost not by being wrong but by arriving wound-up: racing in
+late, over-intense, transmitting an urgency that the other people absorb and mirror. The
+target is not a better script but a lower heart rate. Arrive with a minute to spare so the
+room settles onto your nervous system rather than the reverse; and when you do slip,
+apologize in one line and move on — the elaborate, flustered apology keeps your own pulse
+high and prevents the other side from letting it go, when they were ready to.
+
+When you do speak, compress to the one thing that must land. Pressure pushes you to hedge
+every claim until nothing is left to act on; a short, clear, true statement reads as
+command, while an over-explained one reads as panic. Clarity, under stress, is a kindness
+to the people who have to act on what you say.
+
+*Diagnostic: just after a high-stakes moment, notice your own state. If your pulse is
+still racing, the room felt that too — and that, more than your words, is what the people
+in it will remember.*
+
+*Source: Sam Lessin.*
+
+## Interview Prompt
+
+Recall a high-pressure moment you led people through. What state were you actually
+transmitting to the room — and how did that shape what happened next?

package/templates/codex/seed/leadership/your-best-alternative-is-your-leverage.md

@@ -0,0 +1,37 @@
+---
+type: codex-principle-seed
+name: your-best-alternative-is-your-leverage
+title: Your Best Alternative Is Your Leverage
+created: 2026-06-24
+exposure: shareable
+stance: adopted
+provenance:
+  authored_by: seed
+---
+
+> **Your real power in any negotiation is your best alternative to making a deal. The
+> ability to walk away is the source of leverage; without it you are not negotiating, you
+> are asking permission.**
+
+When your needs are already met, you negotiate from strength and can hold your position;
+when you are desperate, you concede to authority. This is why it is easier to find a job
+while you still have one, and why the side with a credible alternative sets the floor for
+the whole conversation. Strengthening your alternative — before you ever sit down — does
+more for your position than any tactic at the table.
+
+Two habits protect that leverage. Do not let haste betray it: urgency benefits the other
+side, and slowing down signals that you are not cornered. And where you can, let the other
+side name the first number — the party that anchors early sets the ceiling, and you learn
+more from what they offer than from what you demand.
+
+*Diagnostic: before any negotiation or hard ask, name your best alternative if you walk
+away. If you do not have one — or know you will not actually use it — you do not yet have
+leverage, and the move is to build the alternative, not to push harder.*
+
+*Source: Roger Fisher and William Ury, the BATNA concept.*
+
+## Interview Prompt
+
+Think of a negotiation or hard ask in front of you right now. What is your honest best
+alternative if you walk away — and how much does having, or lacking, that alternative
+change how you will show up?

package/templates/codex/seed/pm/a-problem-well-stated-is-half-solved.md

@@ -0,0 +1,39 @@
+---
+type: codex-principle-seed
+name: a-problem-well-stated-is-half-solved
+title: A Problem Well Stated Is a Problem Half Solved
+created: 2026-06-24
+exposure: shareable
+stance: adopted
+provenance:
+  authored_by: seed
+---
+
+> **The constraint on learning is rarely more tests — it's a problem stated clearly enough
+> that a test can resolve it.**
+
+It's tempting to treat experimentation as a throughput game: run more tests, learn more. But
+you can run a dozen tests against a misformulated problem and get a dozen wrong answers
+faster. The binding constraint is usually understanding — naming the real problem precisely
+enough that a test can actually resolve it. A single well-aimed question that reframes the
+problem often makes the solution write itself, after every test aimed at the wrong framing
+came back flat.
+
+This is why experiments are instruments for finding out you're wrong, not for confirming
+you're right. A test that no possible result could change is theater; the one worth running is
+the smallest test whose outcome would actually move your decision. The leverage sits upstream
+of the test — in the qualitative work of stating the problem honestly — because the test only
+multiplies whatever understanding you bring to it.
+
+*Diagnostic: look at your last several tests. How many were preceded by a step that actually
+defined the problem being tested — a real conversation, a close look at where people get stuck
+— versus jumping straight to variants of a guess? If most skipped that step, you're testing
+guesses faster, not learning.*
+
+*Source: Charles Kettering.*
+
+## Interview Prompt
+
+Think of a problem you've been running at without progress. Have you actually stated it
+precisely — or are you testing variations of a guess? Describe a time when restating the
+problem made the answer obvious.

package/templates/codex/seed/pm/a-real-strategy-makes-planning-trivial.md

@@ -0,0 +1,40 @@
+---
+type: codex-principle-seed
+name: a-real-strategy-makes-planning-trivial
+title: A Real Strategy Makes Planning Trivial
+created: 2026-06-24
+exposure: shareable
+stance: adopted
+provenance:
+  authored_by: seed
+---
+
+> **When you have a real, aligned strategy, planning collapses to a short exercise. When
+> planning is painful, the problem isn't the process — it's a missing or unshared strategy
+> upstream.**
+
+A leader with a genuine product strategy can do annual planning in a few days; peers without
+one burn four to six weeks in spreadsheet hell — dependency mapping, false-precision debates
+over whether it's eight engineers or nine, stakeholder theater — and then forget the plan a
+month later and execute off a different list anyway. The friction isn't a planning-tooling
+problem you can fix with a better template. It's the absence of the upstream thing that would
+make the choices obvious. A strategy is what lets you quickly dismiss even positive-return
+work that doesn't serve it; without one, every option looks defensible and nothing settles.
+
+This makes planning friction a *diagnostic*. When the plan won't come together — when the
+debates loop, when everyone is working from a slightly different list — don't grind harder on
+the planning. Treat the pain as the signal that the strategy is missing, or that you haven't
+actually achieved alignment on it. Fix that, and planning becomes a formality rather than a
+season.
+
+*Diagnostic: if planning is a recurring slog, stop debugging the process and ask whether a
+clear, agreed-upon strategy actually exists. The slog is usually a missing strategy wearing a
+planning problem's clothes.*
+
+*Source: Shreyas Doshi.*
+
+## Interview Prompt
+
+When your team plans, is it a quick formality or a drawn-out fight? If it's a fight, what
+would have to be true upstream — about your strategy or your alignment on it — for the plan to
+settle itself?

package/templates/codex/seed/pm/barrels-and-ammunition.md

@@ -0,0 +1,39 @@
+---
+type: codex-principle-seed
+name: barrels-and-ammunition
+title: Barrels and Ammunition
+created: 2026-06-24
+exposure: shareable
+stance: adopted
+provenance:
+  authored_by: seed
+---
+
+> **The number of people who can independently drive an initiative from inception to success
+> — the "barrels" — sets how many things your organization can do in parallel. Everyone else
+> is ammunition.**
+
+Hiring more people without growing the count of barrels just stacks ammunition behind the
+same initiatives: more coordination cost, no more output. Barrels are rare. Even famously
+talent-dense organizations have only a handful, and most very good companies have about two.
+The test is simple to state and hard to pass: "There's a hill — get us over it." Someone who
+can take an ambiguous goal, accumulate the resources, motivate the people, measure progress,
+and deliver the outcome come hell or high water is a barrel. Anything less, however capable,
+is ammunition.
+
+The practical consequence shows up when headcount doubles and throughput doesn't. The reflex
+is to question execution or motivation; the real answer is almost always that you added
+ammunition, not barrels. Growing the number of people who can own an outcome end-to-end — by
+finding them, developing them, and actually handing them the initiative — is the constraint
+that determines how many things you can do at once.
+
+*Diagnostic: when more people haven't produced more output, count your barrels, not your
+headcount. If the barrel count didn't rise, you bought coordination cost, not throughput.*
+
+*Source: Keith Rabois.*
+
+## Interview Prompt
+
+How many people on your team could take an ambiguous goal and carry it all the way to a
+delivered outcome without you steering? What would it take to turn one more of your people
+into that kind of owner?

package/templates/codex/seed/pm/develop-taste-in-your-beliefs.md

@@ -0,0 +1,38 @@
+---
+type: codex-principle-seed
+name: develop-taste-in-your-beliefs
+title: Develop Taste in Your Beliefs
+created: 2026-06-24
+exposure: shareable
+stance: adopted
+provenance:
+  authored_by: seed
+---
+
+> **Taste isn't only about recognizing good design — it's about the quality of the beliefs
+> you choose to hold. Evaluate the idea separately from the social proof wrapping it.**
+
+We get seduced by the packaging around ideas rather than the ideas themselves: by vivid
+metaphors (a phrase wins because it's catchy, not because it's true), by alliteration ("fail
+fast" would never have caught on as "fail slowly"), by authority bias (a famous founder said
+it, so it must apply to your context), and by complicated charts we don't actually
+understand. Each of these is social proof masquerading as substance. The discipline is to
+strip the packaging and judge what's underneath.
+
+Real taste is the ability to recognize quality *before* the scoreboard confirms it. Calling
+a now-celebrated leader a genius today takes nothing — the results are public record.
+Recognizing it years earlier, before the consensus formed, took genuine judgment. The person
+didn't change in the interval; what changed was who could see it early. That early seeing —
+believing the right thing before it's safe and obvious — is what taste in beliefs actually
+buys you, and it's a different muscle from admiring something after it has already won.
+
+*Diagnostic: when a framework or strategic bet attracts you, ask — am I drawn to the idea
+itself, or to the metaphor, the authority, or the popularity around it? Strip all three and
+see whether the claim still stands on its own.*
+
+*Source: Shreyas Doshi.*
+
+## Interview Prompt
+
+Think of a belief currently shaping your strategy. How much of your confidence comes from the
+idea itself versus the vividness, the authority, or the popularity of where you first heard it?

package/templates/codex/seed/pm/hire-for-progress.md

@@ -0,0 +1,44 @@
+---
+type: codex-principle-seed
+name: hire-for-progress
+title: Hire for Progress, Not for Features
+created: 2026-06-24
+exposure: shareable
+stance: adopted
+provenance:
+  authored_by: seed
+---
+
+> **People don't buy products — they hire them to make progress in a circumstance. The
+> unit of analysis is the job, not the customer's demographics or the product's features.**
+
+A job is what someone is really trying to accomplish in a given situation — from "pass the
+time while waiting in line" to "transition into a new life." When a product does that job
+well, the customer hires it again; when it does the job badly, they fire it and look for an
+alternative. The decisive shift is to reason from the progress someone is struggling to
+make, not from "who is my customer and what features do they want."
+
+The circumstance matters more than the customer's characteristics. Demographics correlate
+with behavior but don't cause it — two people who look nothing alike on paper may hire the
+same product for the same job, and one person hires different products for the same job in
+different circumstances. The trap of abundant data is that it pulls teams toward correlation
+("customers like this one also bought…") when they need causation ("what progress was this
+person trying to make?"). Defining the job by its circumstance is what restores causal
+reasoning. It's also why you can ship a functionally correct product nobody hires: jobs are
+never only functional — they carry social and emotional weight, and missing that dimension
+misses the job.
+
+A clear understanding of the job becomes a kind of spec — it lets you design and make
+trade-offs without guessing, because you know what the customer is actually trying to get
+done rather than what they happen to look like.
+
+*Diagnostic: for your product, finish this sentence in the customer's own words — "I hire
+this to ______ when ______." If all you can describe is who the customer is or which
+features they touch, you haven't found the job yet.*
+
+*Source: Clayton Christensen.*
+
+## Interview Prompt
+
+What is a customer of yours actually trying to get done in the moment they reach for what
+you've built — and how much of that job is emotional or social rather than purely functional?

package/templates/codex/seed/pm/jobs-are-stable-solutions-churn.md

@@ -0,0 +1,39 @@
+---
+type: codex-principle-seed
+name: jobs-are-stable-solutions-churn
+title: Jobs Are Stable; Solutions Churn
+created: 2026-06-24
+exposure: shareable
+stance: adopted
+provenance:
+  authored_by: seed
+---
+
+> **The job a customer is trying to get done stays remarkably constant over time; the
+> products hired to do it change constantly. Anchor strategy to the durable job, not the
+> current solution.**
+
+People have wanted to enjoy music for as long as there has been music; the solution churned
+through records, cassettes, CDs, downloads, and streaming while the underlying job held
+still. This is the most useful asymmetry in the framework: solutions, technologies, and
+competitors are transient, but the job endures. A roadmap anchored to a current solution
+inherits the solution's expiration date. A roadmap anchored to the job survives the next
+technology shift, because the thing it serves doesn't move.
+
+The same stability redraws your competitive set. If the unit is the job, your competition is
+everything a customer could hire to make that progress — a rival in an entirely different
+category, a makeshift workaround, or simply doing nothing at all. Defining competitors by the
+job rather than the category is what keeps you from being blindsided by something that looks
+nothing like you but does the same job better — or by the customer who just keeps coping with
+the status quo because no option is worth the switch.
+
+*Diagnostic: state the job your product does in one solution-free sentence, then list
+everything a customer could hire for it — rivals, substitutes, hacks, and inaction. The
+threats you'd never have listed by category are usually where displacement comes from.*
+
+*Source: Tony Ulwick.*
+
+## Interview Prompt
+
+What is the enduring job underneath your product that will still exist when today's
+technology is obsolete — and who or what else is currently being hired to do it?

package/templates/codex/seed/pm/level-by-the-ambiguity-someone-can-own.md

@@ -0,0 +1,39 @@
+---
+type: codex-principle-seed
+name: level-by-the-ambiguity-someone-can-own
+title: Level by the Ambiguity Someone Can Own
+created: 2026-06-24
+exposure: shareable
+stance: adopted
+provenance:
+  authored_by: seed
+---
+
+> **A person's real level is the size of the ambiguous, undefined problem you can hand them
+> and walk away from.**
+
+Seniority is not years or title; it is how much ambiguity someone can absorb without needing
+the strategy supplied from above. The great filter in most careers is the jump from executing
+well-defined work to owning the definition itself — taking a problem that arrives as a vague,
+unowned mess and resolving it into a plan, and then into results. People who only execute
+compound into strong operators; people who learn to own ambiguity compound into leaders. You
+develop someone toward the second by handing them genuinely complex surfaces to own, with real
+autonomy, and letting them grow into the scope.
+
+The hiring corollary is to bet on slope over credentials — on how fast someone is climbing
+into larger ambiguity, not on the polish of what they've already collected. The willingness to
+take a role you're not yet qualified for, fall for a while, and climb out is exactly where
+outsized growth comes from. Beware the asymmetry: a polished outsider's limits are hidden by
+the interview, while a high-slope insider's limits are visible because you've watched them
+work — which biases you toward the wrong one unless you correct for it.
+
+*Diagnostic: for each person you're leveling or hiring, ask how large a problem you could hand
+them with no definition and no oversight before they stall. That boundary is their real level
+— and their growth is whether it's moving outward.*
+
+*Sources: Casey Winters; Molly Graham.*
+
+## Interview Prompt
+
+How much ambiguity can you take on before you need someone above you to define the problem?
+Describe the most undefined, unowned problem you've turned into a real outcome on your own.

package/templates/codex/seed/pm/listen-before-you-prescribe.md

@@ -0,0 +1,38 @@
+---
+type: codex-principle-seed
+name: listen-before-you-prescribe
+title: Listen Before You Prescribe
+created: 2026-06-24
+exposure: shareable
+stance: adopted
+provenance:
+  authored_by: seed
+---
+
+> **When you step into a new leadership role, listen first and synthesize what you heard into
+> a shared, public set of observations — before announcing priorities from instinct.**
+
+The disciplined sequence is weeks of structured listening before any prescription. Ask
+everyone the same few questions — how the organization fits together, what is going well,
+what most needs to change — and gather enough conversations that patterns emerge rather than
+anecdotes. Then write the synthesis down and share it openly. That observations document does
+three things at once: it forces you to turn dozens of conversations into coherent themes, it
+signals to the organization that you actually listened, and it becomes the anchor everyone
+defers back to when later decisions get contested.
+
+The failure modes it replaces are the common ones. Less-disciplined leaders announce
+priorities in week one — fast, confident, and uninformed — or they avoid committing to
+anything for six months and leave the team rudderless. Listening first, then publishing what
+you heard, is what earns the right to prescribe. The writing is the leadership act, not a
+report on it.
+
+*Diagnostic: early in a new role, ask whether you could write a synthesis of what's going on
+that your team would read and recognize as true. If you can't yet, you've been talking more
+than listening — and you haven't earned the prescription.*
+
+*Source: Sriram Krishnan.*
+
+## Interview Prompt
+
+If you joined a new team tomorrow, what questions would you ask everyone before proposing a
+single change — and would you have the discipline to publish what you heard before acting on it?

package/templates/codex/seed/pm/live-in-the-future-and-build-whats-missing.md

@@ -0,0 +1,38 @@
+---
+type: codex-principle-seed
+name: live-in-the-future-and-build-whats-missing
+title: Live in the Future and Build What's Missing
+created: 2026-06-24
+exposure: shareable
+stance: adopted
+provenance:
+  authored_by: seed
+---
+
+> **The best ideas are noticed, not brainstormed — by people living at the leading edge of a
+> change.**
+
+Good ideas aren't thought up at a whiteboard; they're noticed by people who already live in a
+changed world and see what's obviously missing from it. Someone at the frontier of a
+fast-moving field — as a builder or as a heavy user — feels gaps that people who haven't lived
+through the change literally cannot see yet. The recipe compresses to: live in the future,
+then build what's missing. An even better version is to build what seems *interesting*,
+because the things that look like toys to outsiders often have everything an idea needs except
+a track record, and the importance shows up later.
+
+The counter-pattern is the made-up idea — the plausible-sounding concept you reasoned into
+existence rather than noticed. These survive precisely because you can imagine *someone* using
+them, and they dissolve on contact with real users, who all say "I could see using something
+like that" and then never do. Noticed ideas come from lived friction; invented ideas come
+from imagining other people's lives.
+
+*Diagnostic: for your current idea, can you point to the specific moment you noticed the gap
+in your own life or work — or did you reason your way to it because it sounded like a good
+business? The first kind has a witness; the second kind only has an argument.*
+
+*Source: Paul Graham.*
+
+## Interview Prompt
+
+Where are you living at the leading edge of a change most people haven't caught up to yet —
+and what feels obviously missing to you there that doesn't exist yet?

package/templates/codex/seed/pm/match-effort-to-leverage.md

@@ -0,0 +1,37 @@
+---
+type: codex-principle-seed
+name: match-effort-to-leverage
+title: Match Effort to Leverage
+created: 2026-06-24
+exposure: shareable
+stance: adopted
+provenance:
+  authored_by: seed
+---
+
+> **Match your effort to the leverage of the task, not to the task itself.**
+
+Not every task deserves the same quality bar. A few are high-leverage — they return ten to a
+hundred times the effort you put in, and they deserve your best hours and your inner
+perfectionist. Most are neutral — they return roughly what you invest, so do them adequately
+and move on. A third kind is pure overhead — it returns less than you put in, so do it at the
+minimum quality that clears the bar.
+
+The non-obvious part: the same activity can be high-leverage, neutral, or overhead depending
+on context. Notes from a routine status meeting are overhead — send them the moment it ends.
+Notes from a contentious decision meeting are high-leverage — spend the hours to make the
+language airtight, because a misread there costs weeks. Perfectionists burn themselves out by
+treating every task as high-leverage; the discipline is permission to be deliberately
+mediocre exactly where mediocrity is free.
+
+*Diagnostic: look at where your best hours actually went last week. Were they spent on the
+two or three things that compounded, or spread evenly across everything in the inbox? Any
+low-leverage task that got your perfectionism was effort stolen from a high-leverage one.*
+
+*Source: Shreyas Doshi.*
+
+## Interview Prompt
+
+Think about how your effort is spread across a typical week. Which tasks quietly deserve far
+more care than you give them — and which are you over-polishing when "good enough" would cost
+you nothing?

package/templates/codex/seed/pm/not-my-fault-but-my-problem.md

@@ -0,0 +1,40 @@
+---
+type: codex-principle-seed
+name: not-my-fault-but-my-problem
+title: Not My Fault, but It Is My Problem
+created: 2026-06-24
+exposure: shareable
+stance: adopted
+provenance:
+  authored_by: seed
+---
+
+> **When a decision-maker doesn't buy your idea, treat it as your problem to solve — not their
+> failure to understand.**
+
+If a leader doesn't approve your idea, the satisfying story is that they didn't get it. The
+useful stance is the opposite: it's not your fault, but it is your problem. They operate with
+fragmented context — their attention jumps between unrelated problems like a strobe light —
+and with constraints you can't see (budget, pressure from above, commitments you weren't in
+the room for), and they're optimizing for the whole while you optimize for your part. Walking
+in to get approval is the mistake; walk in to learn what would strengthen the plan and to find
+out what they actually doubt.
+
+Managing up is managing the decision and the context around it, not just presenting a
+recommendation. Part of the job is learning how a given person's judgment activates — whether
+they move on data, on customer stories, on design, on the numbers — and bringing the case in
+that form. Owning that gap, instead of assigning blame for it, is the shift from junior to
+senior. And once a call is made, the same ownership means committing to make it work rather
+than relitigating it.
+
+*Diagnostic: after a proposal doesn't land, listen to your own explanation. Are you describing
+why they failed to understand — or asking what context you failed to supply, and what doubt
+you failed to answer? The first keeps you stuck; the second is the move.*
+
+*Source: Jessica Fain.*
+
+## Interview Prompt
+
+Think of a time a decision-maker didn't back your idea. Did you treat it as their failure to
+get it, or as a gap in how you made the case — and what would change if you assumed the
+second?

package/templates/codex/seed/pm/pick-the-job-then-refuse-everything-outside-it.md

@@ -0,0 +1,37 @@
+---
+type: codex-principle-seed
+name: pick-the-job-then-refuse-everything-outside-it
+title: Pick the Job, Then Refuse Everything Outside It
+created: 2026-06-24
+exposure: shareable
+stance: adopted
+provenance:
+  authored_by: seed
+---
+
+> **Strategy is choosing one job to do and declining everything outside it — especially the
+> lucrative, adjacent, tempting things you'd be good at.**
+
+Anyone can pick a focus; the discipline is *applying* it as a binary filter over the constant
+stream of adjacent-but-misaligned opportunities. Turn the jobs-to-be-done lens on your own
+offering: name the single job you exist to do, and let every build-or-decline decision flow
+from that one choice. A partnership that pays well but serves a different job is a decline. A
+move you'd execute beautifully but that doesn't advance the chosen job is a decline. When
+your strategy compresses to one crisp sentence, the compromises become visibly obvious — you
+can see, in the moment, that an opportunity is off-strategy even when it's attractive on its
+own terms.
+
+The hardest version is refusing something genuinely lucrative. Operators walk away from
+"opportunity of a lifetime" offers precisely because taking them would dilute the one job
+their work is built around. That refusal is not a cost of the strategy; it *is* the strategy.
+A focus you never decline anything for isn't a strategy — it's a preference.
+
+*Diagnostic: can you name the specific thing you would refuse even though it's lucrative and
+you'd be good at it? If not, you've picked a vibe, not a job.*
+
+*Source: Lenny Rachitsky.*
+
+## Interview Prompt
+
+What is the one job your product or team exists to do — and what attractive, profitable
+opportunity have you turned down (or should you) because it falls outside that job?

package/templates/codex/seed/pm/retention-sets-the-ceiling.md

@@ -0,0 +1,38 @@
+---
+type: codex-principle-seed
+name: retention-sets-the-ceiling
+title: Retention Sets the Ceiling
+created: 2026-06-24
+exposure: shareable
+stance: adopted
+provenance:
+  authored_by: seed
+---
+
+> **Retention sets a hard ceiling on how large you can become; acquisition only fills a bucket
+> that retention keeps from leaking.**
+
+There's a simple, brutal formula: new customers per period divided by your churn rate is the
+maximum number of customers you will ever have. Add a hundred a month against five percent
+monthly churn and you will never exceed two thousand — because cancellations grow in
+proportion to the base (five percent of a bigger number is a bigger number) while acquisition
+grows only as fast as you can improve it, which is slow and linear. Cancellations always
+overtake acquisition eventually. That is why growth slows, and why retention sits upstream of
+everything else.
+
+The corollary is about what compounds. Acquisition you have to keep buying decays the moment
+you stop paying for it; loops you build into the product — word of mouth, referral, usage that
+pulls in more usage — compound on themselves. Pouring acquisition spend into a product that
+leaks just raises your cost per customer on a treadmill. Fix the leak first; a loop on top of
+a product people stay in is the only growth that doesn't decay.
+
+*Diagnostic: compute your ceiling right now — new customers per period over churn rate. If
+that number is smaller than your ambition, retention is your single most important problem, no
+matter what else is on the roadmap.*
+
+*Source: Jason Cohen.*
+
+## Interview Prompt
+
+If you divide the customers you add each month by the rate at which they leave, what's the
+largest you could ever become? And does that ceiling match the size of your ambition?