# Turning Platform Engineering Work Into Business Value > [!info] Ported from an existing deep-read (Refactor Appendix present). CNCF/KubeCon talk; two Cloud Native Maturity Model maintainers present a repeatable method for translating platform work into funding language, with every specific dollar figure explicitly disclosed as illustrative rather than measured. > [!question] Lingering Questions > - The talk describes the funding-progression success path (provisional → operational → scalable → optimizing) but not what happens when a platform stalls or gets defunded at an early maturity level — a real gap, flagged in the deep-read as a survivorship-bias caveat. > - How often does "who else benefits" actually get asked and answered honestly in real platform proposals, versus asserted without follow-through? > - Do the CNCF's own real (non-illustrative) case studies, if published elsewhere, match the shape of this talk's J-curve, or is the J-curve itself illustrative? > [!tip] Article Ideas > - "Translate before you propose" — the discipline of stating the problem and business goal in non-technical language *before* introducing any technical requirement, applied outside platform engineering (e.g., to DevRel budget requests, which this vault already covers via the devrelshow episode 55 note in the same batch). > [!link] Cross Reference > - [[3. Resources/Literature Notes/devrelshow ep55 -- Gabriel L. Manor, Permit.io]] — same batch; both sources are about translating team-level work into language funders/leadership actually act on > - [[3. Resources/MOCs/Product & Startup Instincts MOC]] — business-case framing for technical investment > [!quote] Vocabulary > - **J-curve** — the pattern where cloud native transformation costs rise before falling, specific to existing enterprises running parallel legacy and new infrastructure (not greenfield organizations) > - **platform maturity funding levels** — provisional (project-funded) → operational (team-funded) → scalable (product-funded, chargeback viable) → optimizing (ecosystem-funded, multiple groups contribute capabilities) ## Bibliographic capsule CNCF/KubeCon conference talk, YouTube. Danielle Cook and Simon Foster, CNCF Ambassadors and Cloud Native Maturity Model maintainers, present a structured method for translating platform engineering work into business-fundable language: the cloud native investment dilemma, a J-curve cost model, three worked business-case examples, and a four-level maturity-based funding progression. Category: video, filed under Podcasts. ## Author's thesis (as synthesized) "Leadership won't fund my platform work" is a translation problem with a repeatable method, not a reason to complain about non-technical leadership: state the problem and business goal in the business's own language before the technical requirement, and scale the funding ask to the platform's actual maturity level rather than pitching full platform-as-product investment prematurely. ## Key arguments (≤3) 1. **The problem and business goal are explicitly not technical.** A funding request starts by articulating the problem and the business goal it serves in language the business already uses — technical requirements and proposals come after, not alongside. 2. **Platform value compounds through who else benefits.** Unlike most technical investments, a platform's value proposition specifically depends on multi-team usability, making "who else benefits" a structurally necessary question, not a generic add-on. 3. **The J-curve is scoped honestly.** Costs rise before falling during cloud native transformation — but the presenters explicitly exclude greenfield organizations from this pattern, an unusually specific limitation for a conference pitch. ## Claim atoms ### The problem is explicitly not a technical problem > [!quote] ID: rw_01kze55qyhrr7z07t2zcg3k8zz > "the first thing we all need to be able to clearly articulate is what is the problem we're trying to solve. And that problem is not a technical problem." Where/why: the organizing discipline of the whole talk — translate before proposing, in that order, not as parallel framing. ### Platform value compounds through who else benefits Where/why: for genuinely shared infrastructure, "who else benefits" is the actual source of the investment's leverage, not a nice-to-have addition — omitting it undersells the real value of a platform specifically (as opposed to a single-team tool). ### Capital trapped in fixed assets is itself a cost Where/why: purchasing infrastructure locks capital on the books for 3-5 years; the resulting inflexibility (inability to redirect that money as business needs change) is a distinct cost beyond the purchase price — the real mechanism behind the capex-to-opex argument, not just "cloud is cheaper." ### Every dollar figure in this talk is explicitly illustrative Where/why: self-disclosed repeatedly — churn rates, release times, HA costs, downtime costs, and capex/opex figures are pedagogical placeholders, not measured data. The presenters' own closing advice is to get real numbers from product ops and revenue teams rather than reuse illustrative ones. ## Permanent candidates - **Shared infrastructure's value case depends on who else benefits** — genuinely uncaptured elsewhere in the vault; promoted below. - Translate-before-propose and the capex/trapped-capital mechanic are solid but narrower/more domain-specific (financial framing tactics) — held for connection rather than promotion this pass. ## Processing checklist - [x] Ported claim atoms from the existing deep-read - [x] Checked existing Permanents before creating new ones - [x] Connected into [[3. Resources/MOCs/Product & Startup Instincts MOC]] ## Links - [[3. Resources/MOCs/Product & Startup Instincts MOC]] — funding and business-case framing for infrastructure/platform investment - [[3. Resources/Literature Notes/Turning Platform Engineering Work Into Business Value]] — source transcript/notes