Vision to Value · 14 / 16
Appendix C: Function-Specific Decision Interface Charters
The Charter Meta-Pattern
The Charters in this appendix are worked examples of one underlying artifact: the canonical Decision Interface Charter introduced in Appendix B. Readers arriving here from the Glossary or directly into Appendix C should read the Appendix B template first; it is the master Charter every instance below specializes.
Three Charter instances are written out below. The PM-Director Charter governs cohort-altitude tradeoff decisions inside the Product Management chair on the Product Leadership Team. The PMM Charter governs positioning-before-build-lock decisions from the Product Marketing Director's seat at the PMM-PM interface. The Value Realization Charter governs cohort-outcome decisions from the Value Realization Director's seat at post-launch altitude. These three contrast maximally on what kind of decision the Charter is built around and on where it lands in the Vision to Value flow: a cohort tradeoff at Strategic Decisions altitude (PM-Director); a positioning commitment at Strategic Commitments altitude (PMM); a cohort-outcome read at Business Outcomes altitude (Value Realization). The other four PLT-side functions (Business Development, Competitive Intelligence, Business Operations, Product Operations) operate Charters of the same shape. They are not written out individually because the architecture generalizes; the recipe at the end of this intro is the path a reader follows to derive them from the same nine-field template.
Product-side authorship is the framing the appendix holds throughout. Every Charter here is written from the Product Organization's seat. The counterpart appears in the Inside / Outside boundary, the gating inputs, and the co-decision rights, never as the Charter's author. This is the book speaking from the seat it claims: the CPO altitude, the Product Leadership Team, the Product cohort. A Charter authored from any other seat would be a different artifact under a different decision system.
What makes a Decision Interface Charter a Charter, and not a process document, is that it declares the same nine fields every time. The fields are the discipline; the seat is the variable. The nine fields every Charter declares:
1. Scope (the Product-side seat that authors the Charter, the altitude it operates at, the accountabilities it carries, and the inside-versus-outside boundary against the adjacent seats most likely to absorb it).
2. Decision rights (what this seat decides without escalation, what this seat co-decides with which counterparties, and what this seat surfaces but does not decide).
3. Pre-commitment artifacts required (the inputs the seat brings to the decision before the decision is taken, distinguished from the inputs that would arrive too late to gate the decision).
4. Cadence and forum (where the Charter runs, how often, and on what pre-read deadline).
5. Escalation paths (when the Charter escalates, to which counterparty, against which trigger, with which artifact in hand).
6. RACI (who is responsible, accountable, consulted, informed, named at the role level rather than the person level).
7. Success metrics (how the seat's performance against the Charter is measured, separated from how the decisions the Charter governs are measured).
8. Re-decision triggers (the named conditions under which a decision the Charter has already taken returns to the formulation surface, drawn from outcome-evidence, market-evidence, and counterparty-specific signal classes).
9. Charter amendment process (how the Charter itself is revised when the conditions it was authored under change, who signs the amendment, and how the amendment is recorded).
Decisions are the unit of product leadership, and the Charter is the artifact that makes a recurring decision legible, reconstructible, and re-decidable from the seat that owns it.
The discipline does not scale to non-Product seats. A Director of Engineering Charter, a Director of Design Charter, a Director of Data Charter, a Director of Customer Success Charter, a Director of Operations Charter, a Director of Sales Charter, a Chief Marketing Officer Charter, these are not absent from this appendix by oversight. They are absent because this book speaks from the Product Org's seat, and a counterpart organization's Charter would be authored from a different seat under a different operating-system head. The CTO authors the Engineering Decision Interface Charter from the Engineering Org's seat; the Chief Data Officer authors the Data Org's; the Director of Customer Success authors the CS Org's at the CCO or CRO interface; the COO authors the Operations Org's; the CRO authors Sales's; the CMO authors Marketing's. This appendix shows the Product half of every interface the Product Org owns. The counterpart half is the counterpart's to author, and inviting them to author it is the right structural move; absorbing their authorship into this appendix would be the wrong one.
Derivation Kit
How to derive your function's Charter
Step 0. Name your function's archetype. Before naming the seat, name the archetype your function operates under. The worked Charters in this appendix call this load-bearing. An unnamed Charter defaults to one archetype implicitly, almost always the high-touch shape, and misreads the seat's operating surface. State which archetype applies to your installation from the named set your function carries: for PM-Director, single-product-line vs. multi-product-line vs. functional; for PMM, category-creator vs. demand-gen-led vs. brand-led; for Value Realization, high-touch enterprise vs. tech-touch scale vs. hybrid commercial; for Business Development, partnership-architecture-led vs. channel-led vs. ecosystem-led; for Competitive Intelligence, category-defining vs. window-watching vs. deal-support-led; for Business Operations, business-case-led vs. portfolio-pricing-led vs. financial-modeling-led; for Product Operations, cadence-and-record-led vs. install-led vs. cohort-operations-led. The nine fields hold across archetypes; input weighting and cadence will shift. Hold the archetype declaration as a one-paragraph header above the nine fields.
Step 1. Name the seat. Write down the exact Product-side seat that will author the Charter (for example, Director of Product Marketing; BD Leader; Director of Data and Analytics; Director of Product Operations). One seat per Charter.
Step 2. Name the decision class the Charter governs. Write one sentence naming the recurring decision this Charter is built around (for example, positioning-before-build-lock; partnership-architecture commitments; metric-integrity calls at the Data interface; cadence-and-record decisions in the operating layer). Not a process. A decision class that recurs and currently absorbs upward, sideways, or into the wrong room.
Step 3. Write your nine fields now, in order. Open Appendix B's template and fill out scope, decision rights, pre-commitment artifacts required, cadence and forum, escalation paths, RACI, success metrics, re-decision triggers, and Charter amendment process. One field at a time, from the seat you named in Step 1, against the decision class you named in Step 2, weighted for the archetype you named in Step 0. If a field is empty, the Charter is not yet ready; do not skip the field by writing 'TBD.' Either name the content or name the counterparty whose input you need to fill it. When you write the cadence-and-forum field, name where the Charter runs AND where its decisions are recorded, who maintains the record, and the findability standard (the 30-second reconstructibility rule from Chapter 4 applies).
Step 4. Name the counterparty roster. For every field that has a counterparty in it (decision rights co-decided with whom; gating inputs supplied by whom; escalation paths to whom; RACI consulted and informed positions; re-decision triggers signaled by whom), name the seat the counterparty holds. Not the person. The seat. If a counterparty appears in three or more fields, mark them as a primary interface for this Charter; primary interfaces get a named pre-alignment cadence in field four.
Step 5. Test the Inside / Outside boundary against the three nearest seats that could absorb the decision. Name the three nearest seats, Product-side or peer-function, most likely to absorb the decision by altitude, accountability, or relationship (for example, the PM-Director for a PMM Charter; the VP Product for a Director-altitude Charter; the CPO for any Director Charter; the CRO or Head of Corp Dev for a BD Charter where peer-function absorption is the real risk). For each, write one sentence naming what would absorb upward, sideways, or downward if the Inside / Outside boundary were not declared. If you cannot name what absorbs, the boundary is not yet specific enough; revise field one (scope) and field two (decision rights) until the absorption pattern is named.
Step 6. Name your Bounded exit. Write down the named condition under which you, the seat that authored this Charter, will withdraw from the decision and return it to formulation. The Bounded exit is the safety valve that prevents the Charter from being theater. Examples from the worked Charters: 'I withdraw when the positioning lock is reopened after build-lock without a re-decision trigger firing'; 'I withdraw when the partnership-architecture decision is reversed by the CPO without consultation'; 'I withdraw when the realized-value signal confirms the bet's continuation threshold across three cohort cycles.' If you cannot name the Bounded exit, the Charter is not yet installed; it is aspirational, and the next operator who sits in this seat will inherit a Charter they cannot leave.
Step 7. Lock the Charter against your CPO before the first decision runs through it. Take the seven filled fields, plus the Bounded exit clause, plus the named archetype, to the CPO seat as a commit, not a proposal. The CPO signs the amendment process (field nine) so that future revisions follow a known path. Run the Charter against three live decisions in the next quarter before you revise it.
The PM-Director Decision Interface Charter
Written from the Director of Product Management's seat. The PM-Director holds the Product Management chair on the Product Leadership Team (per Chapter 3), owns hiring authority across the PM function, runs the cross-team tradeoff forum among peer PM-Directors, and operates the day-to-day decision system the rest of this appendix's Charters interface against. This Charter is the seat-authored instance of the Appendix B template, declared from the inside of the Product Management function rather than from a peer-Director's interface to it.
Archetypes. Three archetypes shift Charter weight. Single-product-line PM-Director runs the Charter as a within-line discipline: the cross-team tradeoff forum is bilateral with the platform-engineering Director and one or two adjacent product-line PM-Directors, and PM leveling calibration runs against a small Director cohort. Multi-product-line PM-Director runs the Charter at the cohort altitude: the cross-team tradeoff forum is the primary surface, the PM-Director chairs by rotation, and the load-bearing question is how scope contention across lines resolves without escalation to the VP-Product. Functional-PM-Director (a PM-Director whose span is a domain rather than a product line — platform PM, growth PM, internal-tools PM) runs the Charter against shared infrastructure surfaces, where every adjacent product-line is a counterparty and the platform-intake handshake is the recurring decision surface. Inputs, cadence, and record hold across all three. Adjust input weighting to match the archetype that fits your organization.
Load-bearing wall. This interface protects against three failures that compound at the Director altitude. The first is cross-team tradeoffs being absorbed upward to the VP-Product when they should resolve at the Director cohort: tradeoffs that escalate by default deplete VP-Product attention on calls the Director cohort is structurally positioned to make, and the Director cohort never builds the muscle the next altitude depends on. The second is PM craft drifting into super-PM-in-Director-clothing — the failure mode the Chapter 6 Hardest Evolution sidebar names — where the PM-Director resolves PM-altitude tradeoffs in the room and the PM cohort stops growing. The third is hiring-and-leveling decisions being made in private and absorbed into HR administration, the Principle 2 failure the Chapter 6 talent-architecture passages name. What I bring is the cross-team tradeoff forum as a Director-altitude decision surface, the PM-leveling calibration as a quarterly forum signed against evidence, and the hiring rubric as a pre-commitment artifact authored at requisition open. What I do not bring is the strategic intent (CPO and VP-Product), the portfolio sequencing (VP-Product chairs), or the executive-altitude interfaces (Chapter 7).
Inputs (six classes I supply, gating unless marked consultative): the Cross-Team Tradeoff Pre-Read, a one-pager per PM-Director per cycle naming my product line's three live cross-line tradeoffs, my proposed resolution, my counterparty Director, and my escalation trigger if not resolved at the forum (gating); the PM performance record per PM in the cohort, four input classes (decision-quality evidence against the PM's bets, shipped-work evidence against committed windows, customer-evidence synthesis quality, peer-calibration signal from structured 360s), maintained against the Chapter 6 talent-architecture passages and audited by the Chief People Officer (gating at calibration); the platform-intake handshake artifact, a per-cycle commitment from the platform-engineering Director on which PM-line requests will land in which window, with a "not this cycle" list explicit (gating at intake); the PM cohort hiring rubric per open requisition, signed by the hiring manager and the PM-Director before sourcing opens, naming the level, the ambiguity the role absorbs, the dependencies the role resolves, and the comp band (gating at requisition); the decision-record findability sweep against the cohort's last twelve months of PRDs, launch-readiness memos, and bet-level decisions, audited against the thirty-second reconstructibility test from Chapter 4 Toolkit (gating at quarterly review); the Director-cohort engagement read against PM attrition, PM-to-PM-Director one-on-one cadence, and Director-cohort meeting hygiene (consultative).
Inside / Outside. Inside this interface, decided by the PM-Director or co-decided with the named counterparty: cross-line scope tradeoffs that do not require capital reallocation; sequencing tradeoffs against shared platform capacity, co-decided with the platform-engineering Director; PM-team-to-PM-team handoff disputes; PM cohort leveling calibration, co-decided with peer PM-Directors and the People Business Partner; hiring rubric and interview-loop design, co-decided with the recruiter; the cross-team tradeoff forum's cadence, ritual spec, and decision-record convention. Outside this interface — surfaces I bring inputs to but do not decide: portfolio sequencing across product lines (VP-Product chairs at the Portfolio Review); strategic intent and bet portfolio shape (CPO-altitude); positioning and message-hierarchy lock (PMM-Director's Charter); reliability posture and architectural-debt retirement (Engineering Charter); pricing exceptions and commercial-motion mix (CPO-CRO interface); comp-band methodology and enterprise-leveling framework (Chief People Officer); cross-functional program management at the executive altitude (COO or program-management function). The boundary against the VP-Product seat is the load-bearing one, and it lands on three distinctions: I run the cross-team forum at the Director cohort altitude, the VP-Product runs the Portfolio Review at the executive altitude; I own PM cohort hiring and leveling, the VP-Product owns Director-altitude hiring and the function's executive interfaces; I install Charters at the Director altitude, the VP-Product authorizes the cadence the Charters live inside.
Decision rights. Six classes of decision are mine to take without escalation: cross-line scope tradeoffs that do not affect committed bets or capital envelope; PM-leveling calls inside the comp-band (a promotion within an established band; a hire at the band the rubric named); cross-team tradeoff forum decisions taken inside the forum's named decision rights; PM-to-PM-team handoff resolutions; decision-record hygiene calls (re-decision-record format, archive convention, findability standard inside the cohort); ritual spec for forums I chair (cadence, pre-read deadline, attendee roster). Three classes are co-decided: platform-intake commitments, with the platform-engineering Director per the platform-intake handshake; promotion-band exceptions, with the People Business Partner and the comp committee; Charter amendments to this Charter, with peer PM-Directors and ratified at the next cross-team tradeoff forum. Three classes I escalate: any tradeoff requiring capital reallocation (escalates to the VP-Product); any tradeoff affecting a committed bet's continuation threshold (escalates to the Portfolio Review); any tradeoff that crosses the PMM positioning lock or the Engineering reliability floor (escalates to the PMM-Director's or Engineering Charter forum, not absorbed unilaterally).
The Cross-Team Tradeoff Forum. This Charter installs the cross-team tradeoff forum as the standing surface where cross-line and platform-contention tradeoffs at the PM-Director altitude resolve. The forum is the single most-named-but-least-walked PM-Director artifact in the decision system the book describes; this Charter walks it.
Convening rule. The forum is chaired by the PM-Director with the largest cross-team dependency footprint in the cycle, rotated quarterly to distribute the load and prevent the chair from becoming a permanent owner the cohort routes around. Seats include peer PM-Directors at adjacent product lines (decision-makers); Engineering-Director peer per affected platform (gating input on platform capacity); Product Operations observer for cadence telemetry and decision-record archive (informational, not decision-making). The forum convenes bi-weekly minimum at Director cohort altitude; weekly during high-conflict periods (post-portfolio-review, pre-launch, post-architecture-debt-retirement). A forum that misses its scheduled window twice in a cycle triggers a Charter review per the operating-calendar discipline from Appendix A, not a calendar slip.
Decision rights of the forum. The forum decides cross-product-line scope tradeoffs that do not require capital reallocation; sequencing tradeoffs against shared platform capacity; PM-team-to-PM-team handoff disputes; cross-line decision-record convention. The forum does not decide: anything requiring capital reallocation (escalates to VP-Product); anything affecting committed bets' continuation thresholds (escalates to Portfolio Review); anything affecting PMM positioning lock (escalates to the PMM-Director's Charter); anything affecting Engineering reliability posture or architectural-debt retirement sequencing (escalates to the CPO-CTO interface). The forum's decision rights are bounded explicitly because an unbounded cross-team forum becomes a quasi-Portfolio-Review the VP-Product cannot trust and the cohort cannot rely on.
Pre-read discipline. Each PM-Director arrives with the Cross-Team Tradeoff Pre-Read in hand: a one-pager naming my product line's three live cross-line tradeoffs, my proposed resolution, my counterparty Director, and my escalation trigger if not resolved at the forum. Pre-reads land twenty-four hours before the forum convenes; a pre-read that arrives at the forum is not a pre-read. Product Operations maintains the pre-read archive as part of the cohort's decision-record set.
Re-decision triggers for forum decisions. A tradeoff resolved at the forum re-opens automatically if any of three conditions fire: the underlying assumption named in the Charter changes (a roadmap shift, a customer-evidence revision, a platform-capacity revision); the counterparty Director surfaces material new information within thirty days of the resolution; either side's bet changes its T+2 indicator past the threshold the Charter named. A re-decision is a named event against the documented trigger, not an ad-hoc reopen. The forum that runs re-decisions cleanly is the forum the cohort trusts; the forum that quietly re-confirms is the forum the cohort routes around.
Cadence and record. Written decision per tradeoff, archived per the Decision Record convention from Chapter 4 (Decision Interfaces and the Architecture), maintained by Product Operations, findable in thirty seconds, auditable by the chairing PM-Director for cohort-coherence integrity. A rolling roster of which Director chaired which tradeoff in which quarter is maintained by Product Operations; the roster is the load-distribution evidence the cohort uses to confirm the chair-rotation rule is holding. Quarterly read by the VP-Product confirms the forum is making decisions versus running status — the Anti-Pattern 4 failure mode the book names. If the quarterly read finds the forum drifting into status, the Charter reopens at the next cross-team tradeoff forum convening.
Cadence (this Charter, broader than the forum within it). The cross-team tradeoff forum runs bi-weekly minimum (see above). PM-leveling calibration runs quarterly, anchored to the Chief-People-Officer-CPO talent charter cycle from Chapter 6. Hiring-rubric review runs at requisition open (event-triggered) and at quarterly cohort review. Decision-record findability sweep runs quarterly. Director-cohort engagement read runs quarterly. Charter amendment review runs annually unless a re-decision trigger fires.
Record. This Charter artifact plus the cross-team tradeoff forum's decision-record set, the PM cohort's leveling-calibration record (with comp-band rationale per leveling call), the hiring rubric per open requisition, and the decision-record findability audit log, all maintained by Product Operations, findable in thirty seconds per the hygiene rule, auditable by the PM-Director for cohort-coherence integrity, by the Chief People Officer for leveling and hiring discipline, and by the VP-Product for cross-team tradeoff forum decision-quality.
Re-decision triggers. Outcome-evidence (cross-team tradeoff resolution time exceeds the Charter's threshold across two consecutive cycles, or PM cohort attrition breaches the band the Chief-People-Officer-CPO talent charter named); market-evidence (a competitor's product organization shape shifts the cross-line dependency surface the cohort operates against, or a platform-vendor change reshapes the platform-intake handshake); counterparty-specific (the platform-engineering Director's intake handshake degrades across two cycles, or the VP-Product's quarterly read on the cross-team tradeoff forum surfaces drift into status across two consecutive quarters).
Bounded exit. The PM-Director withdraws from the cross-team tradeoff forum when the forum's decision rights are overridden by VP-Product calendar accommodation without a re-decision trigger firing, or when the chair-rotation rule is suspended without ratification at the cohort level; the withdrawal is recorded and the Charter returns to the cohort for re-authoring. The PM-Director withdraws from a hiring decision when the rubric is overridden post-source without an exception logged; the requisition is paused and returns to requisition-open with the rubric corrected.
RACI summary. Responsible: PM-Director, for the Charter's operation and the forum's running. Accountable: PM-Director, for cohort-altitude decisions; VP-Product, for executive-altitude ratification of the cohort's decision boundary. Consulted: peer PM-Directors (forum members); Engineering-Director peers per affected platform; PMM-Director on cross-line positioning interactions; Chief People Officer on leveling and hiring; Product Operations on cadence and record. Informed: CPO (quarterly summary); affected Group PMs and Lead PMs in the cohort (per-decision); functional partners (PMM, Engineering, Design, CS) outside the forum's decision rights but inside the decisions' downstream impact.
Success metrics. Cross-team tradeoff resolution time at the cohort altitude (median time from tradeoff surfacing to written decision); cross-team tradeoff escalation rate to VP-Product (proportion of tradeoffs the forum decided versus escalated; high escalation rate signals forum decision-rights too narrow or cohort capability gap); PM cohort decision-record findability score (proportion of last quarter's PM-cohort decisions reconstructible in thirty seconds); PM cohort leveling-calibration drift (exceptions-per-cycle against comp-band, audited by the Chief People Officer); Director-cohort attrition and engagement signal. These measure how the seat performs against the Charter; how the decisions the Charter governs perform is measured by the bets and Charters those decisions feed (Portfolio Review, Product-line Review, the per-bet Decision Records).
Charter amendment process. Material amendments to this Charter (changes to decision rights, the forum's convening rule, the pre-read discipline, the re-decision trigger set) require ratification at the next cross-team tradeoff forum convening with peer PM-Directors present, recorded against the Charter's amendment log, signed by the chairing PM-Director, and surfaced to the VP-Product at the next quarterly read. Non-material amendments (cadence adjustments inside the named bands, ritual spec refinements, attendee roster updates) are recorded by the chairing PM-Director and the amendment log; the cohort is informed at the next forum. The Charter is read end-to-end annually at the Director-cohort altitude; the annual read is the anti-decay discipline the cohort owes itself.
The PMM Decision Interface Charter
Written from the Director of Product Marketing's seat. PMM is inside the product organization's decision system regardless of reporting line.
Archetypes. Three archetypes shift Charter weight: category-creator (positioning upstream of scope), demand-gen-led (T+2 window dominates), brand-led (CMO brand-calendar gates launch-tier). Inputs, cadence, and record hold across all three. Adjust input weighting to match the archetype that fits your organization.
Load-bearing wall. This interface protects against positioning elaboration after build-lock, where the category story is retrofitted to scope rather than authored against the market the product will enter. What I bring is the positioning artifact before scope commits; what I do not bring is scope negotiation through positioning.
Inputs (five classes I supply): positioning artifact (category frame, three-tier message hierarchy, named-alternative competitive frame); pricing and packaging constraints against segment willingness-to-pay; target-segment definition (ICP, buyer persona, evaluator-versus-champion read); launch-narrative brief and launch-tier classification (T1/T2/T3 per Chapter 5); sales-enablement readiness signal.
Inside / Outside. Inside this interface, co-decided with PM: positioning lock before build-lock (PMM accountable for the positioning artifact, PM accountable for the scope that carries it), pricing and packaging commitments, launch-tier classification, message-hierarchy ownership. Outside: product scope on committed bets (PM-Director), engineering sequencing (Chief Architect), corporate-brand calendar (CMO, informational).
Cadence. Weekly pre-launch T-6 through T-0 on T1 launches; monthly positioning review against Competitive Intelligence (CI) category-motion signals; quarterly message-architecture re-read at portfolio review.
Record. The PMM Charter artifact plus the Launch Narrative Brief per T1 bet, maintained by Product Operations, findable in thirty seconds per the hygiene rule, auditable by Director of Product Marketing for positioning integrity and by the CMO for brand-calendar coherence.
Re-decision triggers. Outcome-evidence (pipeline or activation miss against the T+2 window); market-evidence (CI-fired category motion: a new entrant redefines the category, a competitor launches a substitute, a pricing move compresses the premium); counterparty-specific (scope drift against positioning commit across two consecutive bet reviews).
Bounded exit. PMM withdraws from the decision when the positioning lock is reopened after build-lock without a re-decision trigger firing; the withdrawal is recorded and the decision returns to formulation.
The Value Realization Decision Interface Charter
Written from the Value Realization Director's seat. The Value Realization Director holds the Value Realization chair on the Product Leadership Team and operates at cohort-outcome altitude: the surface where the promise the strategic bet made to the customer at commit time meets the outcome the cohort actually realized after launch. This Charter governs the cohort-outcome decisions Value Realization carries: the realized-value read against the bet's continuation threshold, the continue-pivot-retire call at the T+6 and T+12 checkpoints, and the promise-to-outcome gap signal that gates portfolio review. This Charter is the Value Realization instance of the Appendix B template; the seat that authors it sits inside the Product Organization and reports through the CPO to the PLT, like every other Charter in this appendix.
Seat-clarity note. Customer Success is the adjacent peer function outside the Product Organization's boundary, on the same wall as Engineering, Design, Operations, and Sales. CS reports through the CS organization to the CRO or COO and owns account-level health and retention: does THIS named customer stay, renew, expand. Value Realization reports through Product to the CPO and the PLT and owns cohort-outcome decisions: does the bet this product carries deliver the customer-outcome it promised at strategic-bet commit time, across the cohort. The two functions read the same customer-outcome surface at different altitudes: CS reads accounts, Value Realization reads cohorts against the bet's success criteria. The Charter is the surface where Value Realization brings its read, and the CS account-level read appears in the gating inputs and re-decision triggers as a counterpart-supplied signal, never as the Charter's co-author. The boundary against the PM-Director seat is owner-of-the-execution vs. measurer-of-the-outcome: PM-Director owns whether the product execution shipped; Value Realization owns whether what shipped actually moved the customer-outcome the bet was committed to. The boundary against Business Development is the partnership analogue of the same split: BD owns the partnership architecture and the joint-motion call; Value Realization owns whether the partnership delivered the joint customer-outcome the architecture was committed to.
Archetypes. Three archetypes shift the read: high-touch enterprise (named-account cadence; quarterly read), tech-touch scale (segment cadence with in-product signal; continuous read), hybrid commercial (value-tier gate between the two). Naming the archetype is load-bearing; an unnamed Charter defaults to high-touch and misreads the scale surface. Inputs, cadence, and record hold across all three. Adjust read mechanics to match the archetype that fits your organization.
Load-bearing wall. This interface protects against outcome absorption, where the realized-value signal is absorbed into the adoption dashboard, QBR narrative, or expansion forecast, and the customer-outcome loop silently closes against self-report. What I bring is the promise-to-outcome gap by cohort as a gating input to the portfolio review; what I do not bring is pricing exception, product scope, or contractual concession.
Inputs (seven classes CS-Value Realization supplies): account-health score with segment cut; cohort adoption-depth trajectory; realized-value signal (promise-to-outcome gap by cohort); expansion and contraction leading indicators; churn-risk signals against named thresholds; customer-promise register from sales handoff per the Chapter 7 CPO-CRO interface; onboarding time-to-first-value. Value Realization is the sole author of these inputs; the CS account-altitude read threads as a gating-input source for the account-health, expansion-and-contraction leading indicators, and churn-risk signal classes through CS Ops as a counterpart-supplied data feed.
Inside, decided by the Value Realization Director: the cohort-altitude calls, realized-value gap surfacing, cohort-outcome cadence definition, the continuation-threshold call against the bet's success criteria, and the promise-to-outcome gap signal as gating input to portfolio review. The account-altitude calls (named-account renew, expand, reference, escalate) are decided by Customer Success at the CSM altitude as a peer function; CS account-altitude reads surface to this Charter as gating inputs to the cohort-altitude read, threaded through CS Ops as a data feed. Outside: pricing exceptions (Director of Product Marketing and Finance), product scope and execution-shipped calls (PM-Director and Engineering: Value Realization measures the outcome of what shipped, but does not decide what gets built or shipped), partnership architecture and joint-motion calls (Business Development: Value Realization measures whether the partnership delivered the joint customer-outcome, but does not own the partnership-architecture decision), contractual concessions (Legal and Sales).
Cadence. Weekly account-health review at the CSM altitude; monthly cohort-outcome read feeding the Product-line Review; quarterly CPO-COO-CCO forum; T+6 and T+12 checkpoints threaded to each bet's Business-Case artifact.
The cohort-outcome record owned by the Value Realization Director, with CS Ops supplying the account-altitude data feed, threaded to each bet's Decision Record by bet-ID, maintained by Product Operations, findable in thirty seconds, auditable by the CPO for continuation-threshold coherence.
Re-decision triggers. Outcome-evidence (realized-value gap exceeds the Charter's threshold across two consecutive cohorts); market-evidence (a competitor introduces a substitute outcome the promise cannot match); counterparty-specific (sales-handoff promise register drifts against the customer-outcome record across two cycles).
The Value Realization Director withdraws when the realized-value signal confirms the bet's continuation threshold across three cohort cycles, or when a re-decision trigger fires and the bet returns to formulation; where the horizon is mis-specified, the withdrawal escalates to the CPO-CFO interface for threshold recalibration.