Speak the Same Language:
The CIO & Product Owner Playbook
for Agile Commercial Delivery

Audit every IT report that goes to a non-technical stakeholder. Replace "what we did" with "what changed commercially." "We deployed the API integration" becomes "Sales can now see real-time stock in CRM — reducing lost orders by an estimated £X per month." This applies to external communications only — internal tools, velocity tracking, and burndown charts stay exactly as they are. The dev team's engineering metrics are not being replaced; they are being translated for a different audience.

Create a one-page glossary mapping IT terms to business equivalents — and business terms to IT implications. Co-author it with one business stakeholder; the act of building it together is as valuable as the document. Publish in the shared project space and reference it when misalignment surfaces in meetings. Key terms to include: Sprint → delivery cycle; Technical debt → accumulated business risk; MVP → first testable commercial version; Definition of Done → business acceptance criteria.

Rewrite sprint goals using this structure: "By end of this sprint, [stakeholder] will be able to [commercial action], which means [£/$ or customer outcome]." Example: "By end of Sprint 12, Sales will be able to generate quotes directly in CRM without manual approval — reducing turnaround from 4 days to 4 hours." Write two goals per sprint: an internal one ("what we are building") and an external one ("why the business cares"). Only the external version goes to stakeholders. Invest 30 minutes per sprint in this framing; it pays back in reduced scope creep and faster sign-off. Validate any £/$ estimate with the Sales or Finance lead before it appears in a sprint goal.

Add a standing 5-minute segment to every IT–business meeting: "What did IT deliver last fortnight, in one sentence a CFO could tweet?" The PO drafts it; a business stakeholder reviews before it goes to the CFO. Costs 10 minutes per fortnight. Over time it builds a shared commercial vocabulary that makes prioritisation faster and less political.

Add a Commercial Value Score (CVS) to every backlog item before sprint planning. Score three dimensions 1–5: Revenue Impact, Cost Impact, Risk Impact. Items without a score cannot be prioritised. Takes 15 minutes per refinement session and removes the "loudest stakeholder wins" dynamic. The PO scores it in collaboration with a business stakeholder — a score assigned without business input is a guess. Finance calibrates the baseline figures for scoring before the first session.

For every epic, require a "Connected Metric" field: which business KPI does this move? Revenue per customer, CAC, order processing time, churn rate? Epics with no connected metric are flagged "Unvalidated" and iced — not deleted. Spot a feature factory by counting epics with verbs like "build", "add", "create" with no metric attached. Rename each one to start with the outcome: "Reduce customer onboarding time from 5 days to 1 day." Finance or BI provides the current KPI baseline values to anchor the metrics.

Once per quarter, schedule a joint CIO + CFO/COO backlog review: present last quarter's commercial outcomes, show the proposed backlog with CVS scores, and invite the business to redirect up to 20% of IT capacity. The business leader must present one commercial priority they want IT to solve — not just react to IT's plan. If they arrive without one, ask directly: "What commercial pain would you most like IT to remove next quarter?" Requires an existing CIO–CFO relationship; if the Readiness Check returned amber or red, run a full quarter of commercial sprint reviews first.

Define and publish a simple escalation path: (1) PO identifies conflict, (2) CVS scores compared, (3) if tied, CIO and relevant C-suite sponsor resolve within 48 hours. Makes priority decisions transparent, reduces mid-sprint scope changes, and protects the delivery team from political pressure they cannot navigate alone. Baseline the current frequency of mid-sprint scope changes in the project management tool before launching — you need a before figure to show the improvement.

Add a 15-minute commercial opener before standard sprint planning: the PO states the most important business problem being solved this sprint and what commercial success looks like. Part 2 — the team's technical planning — stays exactly as it is. Features that don't contribute to the stated commercial problem are questioned, not added by default. If the PO cannot clearly answer "what commercial problem are we solving?" — pause for 30 minutes and clarify with the business sponsor before continuing. The SM facilitates the opener for the first 3 sprints until the format feels natural.

Add to the Definition of Ready: "This story has a named commercial outcome confirmed in writing by a business stakeholder." Stories without this field are returned to refinement. Expect pushback for two sprints. By Sprint 4, business stakeholders arrive to refinement with this information ready. Introduce at the start of a new quarter with CIO backing communicated to business sponsors in advance — without top-cover, POs face resistance they cannot manage alone. Co-design the DoR update with the SM and dev team in a retrospective; when the team understands why (to stop building things nobody values), they almost universally support it.

Restructure the review deck: (1) Business goal reminder, (2) What we shipped, (3) What changed commercially, (4) What we learned, (5) What comes next. Keep the traditional demo segment — developers present their work as usual; the change is the commercial framing around it, not the demo itself. Works whether the sprint succeeded or not — a sprint that missed its commercial goal but generated a learning is valuable if communicated honestly. The SM runs the structural redesign; the PO writes the commercial narrative.

Add a 20-minute optional extension to the standard retro: "Did our delivery move a business metric this sprint? If yes, which one and by how much? If no, what stopped it?" Include one business stakeholder. Run it as an optional extension — invite volunteers from the dev team first; attendance will grow as the format proves its value. Facilitated by the PO, not the SM. Kept separate from the technical retro to avoid conflating delivery quality with commercial impact.

Set up a standing 45-minute monthly meeting between CIO and CFO — agenda owned by the CIO, framed entirely in commercial language: (1) What IT delivered last month in £/$ terms, (2) What IT is delivering next month and its commercial target, (3) What IT investment is at risk without business clarity. Prepare a one-page "IT Commercial Impact Summary" for the first meeting and let the CFO's reaction guide the format for all future sessions. Use the Finance system for IT cost allocation, the project management tool for delivery output, and match the CFO's existing reporting format wherever possible.

Redefine the PO role: accountable for commercial outcomes, not feature delivery. The PO has authority to say no to requests that cannot be connected to a commercial goal, and attends commercial planning meetings alongside sprint ceremonies. This requires the CIO to back the PO publicly and the business to accept that the PO can push back. New accountability line: "Responsible for ensuring every sprint delivers measurable commercial value — not just working software."

The SM is the ceremony owner and the most important person in this playbook who is not the CIO or PO. Brief them first — before any ceremony is redesigned, before any business stakeholder is invited, before any language shift is announced. Start with a 1:1 between CIO and SM: present the commercial alignment vision and ask: "What's your biggest concern about this?" Their answer tells you exactly where to build safeguards. The SM's role: (1) co-design all ceremony changes, (2) facilitate the first 3 iterations of any new format, (3) protect the dev team from commercial pressure that bypasses agreed process, (4) give the CIO honest feedback when something is not landing. "The SM and I designed this together" is the sentence that makes ceremony changes stick.

Restructure squads around commercial journeys — Quote-to-Cash, Customer Onboarding, Renewal & Retention — rather than IT systems (the CRM squad, the ERP squad). Each squad owns an end-to-end business outcome, not a technology component. Before reorganising, map current squad structure to commercial journeys — often the structure is right but naming and accountability are wrong; fix those first. Use HR/org chart, service desk data, and Sales or CS ops to map the journeys accurately.

Send a weekly 5-bullet digest to all C-suite and business leadership — what IT is delivering this week, one sentence per item, commercial language only. No ticket numbers, no story points. Example: "(1) Sales can see customer order history in CRM without switching systems — saving ~20 min per rep per day. (2) Finance automated month-end reconciliation for product category X — 8 hours of manual work removed." Costs 30 minutes per week. Have a business stakeholder validate time-saving estimates before they go to the CFO.

Time-to-Commercial-Value (TtCV) measures how quickly IT turns a business problem into a live outcome — from "problem identified in sprint planning" to "commercial outcome confirmed live by business stakeholder." A team with low velocity but fast TtCV outperforms a high-velocity team shipping features nobody uses. Report TtCV alongside velocity initially; within 2 quarters it becomes the metric business stakeholders track. Introduce it to the dev team as an addition, not a replacement — some teams find it motivating; others find it adds pressure. Run a retro discussion first: "What does this metric mean for how we work?" before adding it to any stakeholder dashboard. Initially manual — log until a pattern is established using the project management tool and stakeholder sign-off dates.

Create one dashboard for business stakeholders showing: Revenue impact this quarter (£/$ estimate), Cost savings confirmed, Customer outcome improvements (NPS delta, onboarding time, support reduction), and Risk items resolved. Exclude uptime %, incident counts, and deployment frequency — those are IT operations metrics. Build it with the CFO's input: "If you could see one IT-driven commercial metric every week, what would it be?" Build that first. Use Finance ERP, CRM, Customer Success data, and the BI tool the CFO already trusts — match their existing format.

For each major debt item, calculate: what is the likelihood of a business-facing failure in 12 months, and what would that cost in downtime, lost revenue, regulatory fine, or churn? Present the top 5 as a business risk investment case, not an IT modernisation request. Data required: Finance for downtime cost model and revenue-per-hour-of-unavailability; Legal/Compliance for regulatory fine exposure; Service desk for historical incident data; SLA contracts for customer churn penalty clauses. CFOs approve risk mitigation budgets far more readily than "platform upgrades."

Business OKRs are set first; product team OKRs are written as contributing sub-goals. If the business OKR is "Increase customer retention by 15%," a product team OKR should be: "Reduce time-to-onboard from 5 days to 1 day — supporting retention target." Block 2 hours of joint CIO and business planning time in the first week of every quarter for OKR alignment — not the last week when OKRs are already drafted. IT must receive the business OKR document before setting its own. Use Finance for KPI baseline values and whatever OKR tracking tool is already in place.