Skip to content
Menu
← Operating guidesProduct & Technology · Operating guide

Abrasim operating guide

The Product Adoption, Operability and Scale Gate: Proving Value after Launch

Check adoption, outcomes, reliability, support, costs and operating capability before expanding a launched product.

By · Published · Updated

For
Product Sponsor, COO, CTO
Leadership decision
Decide whether a production-accepted product should improve, hold, scale within a named boundary, contain exposure, stop or retire, using reconciled behaviour, outcome, reliability, support, lifecycle economics, control and operating-capability evidence.
Source cut-off
2026-08-26

After launch, check whether the intended users can adopt the product, whether their outcome improves and whether the team can support it at an acceptable cost. Release approval under the Product Delivery Governance Standard is one part of that evidence. Expansion may still need to wait, change or stop.

1. The Market Connection Context

The recognisable failure begins with a launch announcement and a dashboard of registrations, downloads or transactions. These outputs may show exposure or activity while hiding unsuccessful tasks, assisted journeys, excluded populations, reliability failures, manual exceptions, support demand, consumption cost and capability debt. Teams then scale acquisition or capacity before they know whether more volume will create value or amplify harm and operating burden.

The Product Delivery Governance Standard: From Discovery through Production Acceptance production acceptance
→ observed reach, behaviour and task completion
→ accepted outcome and unintended effects
→ reliability, support and operating capability
→ lifecycle and unit economics within limits
→ improve, hold, scale, contain, stop or retire

By [decision date], the Product Sponsor will assign IMPROVE, HOLD, SCALE, CONTAIN, STOP or RETIRE to a named product, population and operating boundary. The disposition will cite behaviour, outcome, reliability, support, cost, control and capability evidence, state the authorised change or exposure, preserve dissent and define the next review. A scale decision permits only the stated boundary; it is not proof of universal adoption, durable benefit, unlimited capacity or future return.

Use this guide after production acceptance, ownership, rollback and monitoring readiness have been recorded under the Product Delivery Governance Standard. If production was not validly accepted, return to that standard rather than manufacturing post-launch proof. This gate does not reopen problem validation, reselect the technology route, redesign the solution architecture, rebuild the investment case or appoint a delivery partner unless new evidence requires those separate decisions. Emergency incident command, legal determinations and qualified security or privacy responses retain their own authority.

Working files

The UK Government Service Standard is VERIFIED official guidance that live services continue to meet user needs, define success, publish performance data, operate reliably and protect users. The GOV.UK Measuring Success guidance is VERIFIED official guidance on performance, benefits, digital take-up, satisfaction, completion and cost per transaction. The Google Site Reliability Engineering service-level objective guidance is VERIFIED published operational guidance on user-relevant indicators, objectives and action when service behaviour crosses them. The Google SRE practices are VERIFIED published guidance covering monitoring, on-call, incidents, postmortems and reliability testing as continuing operating work. The FinOps Framework 2025 is VERIFIED framework guidance connecting technology usage, financial accountability and unit economics across business, finance and engineering. These sources support disciplines, not universal metrics or targets. The method below is PROPOSED; every population, baseline, threshold, cost, outcome and attribution claim is REQUIRES VALIDATION, and conclusions are INFERRED until controlled evidence and named human authority support them.

2. The Leadership vs. Delegation Boundary

The reader recognises that scale must be earned through behaviour, outcome, reliability, support, cost and capability evidence with explicit improve, hold or stop gates.

BoundaryRequired content
Product Sponsor ownsPopulation and value boundary, outcome accountability, scale exposure, trade-offs and final disposition
COO and CTO ownService capacity, support model, reliability response, operating capability, containment and technical stop conditions
Finance, research, analytics and operations may leadCohort analysis, evidence reconciliation, cost and workload analysis, user research, causal challenge, gate pack and learning record
Cannot be outsourcedSource accuracy, consent and legal authority, security or safety acceptance, affected-person representation, funding, operational ownership or the decision to expose more people

An internal team can lead when it can observe real behaviour, inspect incidents and support work, reconcile finance and product data, include less-visible populations and challenge launch commitments. Independent support is justified where sponsor incentives favour declaring success, suppliers control evidence, metrics are disputed, affected people lack voice, or scaling creates cross-functional exposure. Analysts describe evidence; they do not decide acceptable harm. Engineers describe reliability; they do not alone decide market value. Finance describes economics; it does not reduce all service outcomes to money.

| Shared | Product, operations, technology, finance, research, data and affected-person representatives reconcile populations, assumptions, evidence thresholds, measures, dependencies, controls and exposure gates; the Product Sponsor retains disposition authority. |

Use a narrower specialist for one bounded reliability, accessibility, privacy, security, safety, workforce, finance or causal-inference question. Stop and escalate when evidence excludes affected people, support or recovery capacity is not credible, a mandatory control fails or proposed exposure exceeds the authorised boundary. Ask providers how they preserve independent measurement, source lineage, incident and recovery evidence, transfer, change control and exit. The Product Adoption, Operability and Scale Gate: Proving Value after Launch is the anchor for post-launch scale; The Product Delivery Governance Standard: From Discovery through Production Acceptance retains production acceptance and The Software Investment Business Case: Scope, Total Cost, Risk and Operating Economics retains changed economic/funding authority. Reuse evidence only with matching boundary and retain one shared decision ID for combined work.

3. The Step-by-Step Execution Standard

Step 01: Charter the post-launch decision

Purpose and decision served Define exactly what may improve, hold, scale, contain, stop or retire.

Accountable owner Product Sponsor.

Delegated lead and contributors Product operations lead, COO, CTO, finance, service, research, data and risk owners.

Preconditions, inputs and access The Product Delivery Governance Standard: From Discovery through Production Acceptance production-acceptance record, product boundary, monitoring access and named operating owners.

Actions

  1. State the product, population, channel, geography, workload and decision period.
  2. Define the six dispositions, authority, maximum scale exposure and prohibited interpretations.
  3. Record source access, conflicts, control authorities, dissent and emergency routes.

Evidence to retain Signed charter, The Product Delivery Governance Standard: From Discovery through Production Acceptance reference, authority map, conflict record and evidence inventory.

Decision or scoring rule Proceed only when scale is reversible or bounded and stop remains credible.

Output and template Charter rows in T01.

Acceptance gate CHARTERED, CHANGE or RETURN TO The Product Delivery Governance Standard: From Discovery through Production Acceptance.

Leadership checkpoint Sponsor confirms launch is an input, not success evidence.

Human control point Sponsor, COO and CTO accept their separate value, operation and technical authorities.

Failure modes and safeguards Reject a charter written only to approve growth already committed.

Change, stop or escalation condition Return to The Product Delivery Governance Standard: From Discovery through Production Acceptance when production ownership or acceptance evidence is absent.

Handoff to the next step The charter controls populations and observation windows.

Step 02: Define populations, cohorts and exposure

Purpose and decision served Prevent aggregate activity from hiding who can and cannot obtain value.

Accountable owner Product Sponsor.

Delegated lead and contributors Research, analytics, accessibility, customer, service and privacy owners.

Preconditions, inputs and access Charter, consent and lawful-use boundaries, user evidence and channel definitions.

Actions

  1. Define eligible, reached, activated, retained, assisted, excluded and harmed populations.
  2. Separate new and existing users, context, channel, accessibility needs and material workload classes.
  3. Record cohort entry, observation period, denominator, overlap and exposure limit.

Evidence to retain Population contracts, inclusion logic, research basis, privacy decision and limitations.

Decision or scoring rule No rate or outcome transfers beyond its defined population and period.

Output and template Population and cohort rows in T01.

Acceptance gate REPRESENTED, VALIDATE, CONTAIN or STOP.

Leadership checkpoint Sponsor accepts material exclusions and exposure limits.

Human control point Privacy, accessibility and affected-person representatives retain their authority.

Failure modes and safeguards Do not allow easy-to-measure users to stand in for assisted or excluded people.

Change, stop or escalation condition Contain exposure when an unrepresented population faces material consequence.

Handoff to the next step Population contracts frame behaviour evidence.

Step 03: Reconcile exposure, activation and meaningful behaviour

Purpose and decision served Distinguish availability and account creation from behaviour that can create value.

Accountable owner Product Lead.

Delegated lead and contributors Analytics, research, service design, operations and data owners.

Preconditions, inputs and access Cohort definitions, telemetry, workflow records, research and source lineage.

Actions

  1. Define exposure, activation, meaningful use, repeat use, abandonment and assisted completion.
  2. Reconcile telemetry with service, transaction and qualitative evidence.
  3. Identify bot, test, duplicate, internal, failed and coerced activity for exclusion or separate reporting.

Evidence to retain Event contracts, lineage, cohort extracts, research notes, exclusions and reconciliation results.

Decision or scoring rule Activity is adoption only when behaviour meets an accepted user and value condition.

Output and template Behaviour rows in T02.

Acceptance gate DECISION-FIT, VALIDATE, CHANGE or REJECT.

Leadership checkpoint Product Sponsor accepts the meaningful-behaviour definition.

Human control point Data owner accepts lineage; research owner accepts interpretation limits.

Failure modes and safeguards Reject vanity totals, changing denominators and post-hoc event definitions.

Change, stop or escalation condition Hold when measurement defects could reverse the disposition.

Handoff to the next step Behaviour evidence feeds task and outcome assessment.

Step 04: Observe task success, friction and workarounds

Purpose and decision served Determine whether people can complete the intended job under real conditions.

Accountable owner Service Owner.

Delegated lead and contributors Research, customer support, accessibility, operations, product and analytics.

Preconditions, inputs and access Meaningful-behaviour contract, task definitions, support and observation access.

Actions

  1. Measure completed, failed, abandoned, repeated and assisted tasks by cohort.
  2. Observe errors, delays, cognitive or accessibility barriers and off-system workarounds.
  3. Record the burden transferred to customers, staff, partners and support.

Evidence to retain Task records, usability evidence, support contacts, workflow observations and limitations.

Decision or scoring rule A completed transaction is not successful when the intended task or consequence remains unresolved.

Output and template Task and friction rows in T02.

Acceptance gate ACCEPT, IMPROVE, CONTAIN or STOP.

Leadership checkpoint COO accepts material manual burden and service displacement.

Human control point Accessibility and service owners decide whether observed barriers are tolerable.

Failure modes and safeguards Do not remove difficult cases from the denominator merely because support handled them.

Change, stop or escalation condition Contain or stop where the product creates material unmitigated harm.

Handoff to the next step Task evidence is connected to accepted outcomes.

Step 05: Test outcome and unintended-effect evidence

Purpose and decision served Establish whether behaviour corresponds with the market or service value promised.

Accountable owner Outcome Owner.

Delegated lead and contributors Finance, product, research, operations, data and risk owners.

Preconditions, inputs and access Accepted baseline, outcome contract, eligible population and observation period.

Actions

  1. Compare eligible outcomes with the accepted baseline or counterfactual.
  2. Separate revenue, cost, capacity, retention, risk and service consequences without double counting.
  3. Test alternative explanations, lag, selection effects and unintended effects.

Evidence to retain Outcome extracts, metric contract, causal assumptions, reconciliation and dissent.

Decision or scoring rule Outcome evidence supports only the population, period and attribution boundary tested.

Output and template Outcome and effect rows in T02.

Acceptance gate SUPPORTED, INFERRED, VALIDATE, CONTAIN or REJECT.

Leadership checkpoint Sponsor and CFO accept the interpretation and its limits.

Human control point Outcome owner remains accountable for the consequence, not the dashboard.

Failure modes and safeguards Do not attribute every observed change to launch or monetise unlike harms into one total.

Change, stop or escalation condition Hold scale where claimed value remains mainly proposed or contradicted.

Handoff to the next step Outcome evidence is tested against reliability.

Step 06: Assess reliability and failure impact

Purpose and decision served Determine whether the service can meet user-relevant conditions at current and proposed exposure.

Accountable owner CTO.

Delegated lead and contributors Service reliability, engineering, operations, security, continuity and product owners.

Preconditions, inputs and access The Product Delivery Governance Standard: From Discovery through Production Acceptance monitoring baseline, service-level indicators, incident and dependency records.

Actions

  1. Analyse availability, latency, correctness, freshness and durability by critical journey and cohort.
  2. Review incidents, near misses, recovery, dependency failure and manual fallback.
  3. Model capacity and failure consequence at the proposed exposure without claiming certainty.

Evidence to retain Indicator contracts, incident records, postmortems, recovery tests, dependency and capacity evidence.

Decision or scoring rule Averages cannot offset failed mandatory journeys, populations or control conditions.

Output and template Reliability rows in T03.

Acceptance gate RELIABLE WITHIN BOUNDARY, IMPROVE, CONTAIN or STOP.

Leadership checkpoint CTO states current evidence and projected exposure separately.

Human control point Qualified technical and risk owners accept residual conditions.

Failure modes and safeguards Reject uptime without scope, user journey, measurement window and error meaning.

Change, stop or escalation condition Contain when increasing exposure could exceed recovery or dependency capacity.

Handoff to the next step Reliability evidence joins support and operating burden.

Step 07: Measure support demand and service burden

Purpose and decision served Expose the human work required to keep the product usable.

Accountable owner COO.

Delegated lead and contributors Support, service operations, product, workforce, finance and engineering.

Preconditions, inputs and access Task evidence, support taxonomy, staffing, escalation and incident records.

Actions

  1. Classify contact demand, repeat contacts, escalations, manual correction and unresolved cases.
  2. Measure workload by cohort, cause and product or process owner.
  3. Identify toil, knowledge gaps, handoff failure, third-party dependency and backlog ageing.

Evidence to retain Support cases, demand taxonomy, workload observations, staffing and cause analysis.

Decision or scoring rule Demand is supportable only when service levels, owner capacity and improvement route are accepted.

Output and template Support and burden rows in T03.

Acceptance gate SUPPORTABLE, IMPROVE, HOLD, CONTAIN or STOP.

Leadership checkpoint COO accepts the burden that scale would add or transfer.

Human control point Support owners can refuse unresourced exposure.

Failure modes and safeguards Do not celebrate low contact volume where access or reporting pathways fail.

Change, stop or escalation condition Hold when support demand grows faster than competent capacity or cause removal.

Handoff to the next step Operating burden is reconciled with economics.

Step 08: Reconcile lifecycle and unit economics

Purpose and decision served Determine whether observed value survives the actual cost of use and operation.

Accountable owner CFO.

Delegated lead and contributors Finance controller, product, cloud or platform, support, procurement and operations.

Preconditions, inputs and access The Software Investment Business Case: Scope, Total Cost, Risk and Operating Economics model, actual commitments, consumption, support and outcome evidence.

Actions

  1. Reconcile internal and external delivery, hosting, licence, support, assurance, incident and change costs.
  2. Define decision-relevant units by eligible outcome or service demand, not convenient transactions alone.
  3. Separate fixed, variable, stepped, transferred and deferred costs and test scale sensitivity.

Evidence to retain Finance actuals, consumption records, allocation rules, unit contract and variance causes.

Decision or scoring rule A unit measure is decision-fit only when numerator, denominator, allocation and value relation are accepted.

Output and template Cost and unit-economics rows in T03.

Acceptance gate WITHIN BOUNDARY, IMPROVE, HOLD, RECASE or STOP.

Leadership checkpoint CFO distinguishes accounting, cash, capacity and service-value consequences.

Human control point Finance determines treatment; product owns outcome-unit meaning.

Failure modes and safeguards Avoid invented allocation precision and unit-cost improvement caused only by denominator growth.

Change, stop or escalation condition Return to The Software Investment Business Case: Scope, Total Cost, Risk and Operating Economics when economics or commitment boundary materially changes.

Handoff to the next step Economics joins capability readiness.

Step 09: Test operating capability and control readiness

Purpose and decision served Establish whether people, processes and controls can sustain the proposed boundary.

Accountable owner COO.

Delegated lead and contributors Product operations, engineering, support, security, privacy, data, accessibility and workforce.

Preconditions, inputs and access Operating model, role evidence, control results, workload and continuity plans.

Actions

  1. Verify ownership, competence, cover, documentation, access and decision rights.
  2. Test security, privacy, accessibility, data, continuity, supplier and change controls at operating scale.
  3. Identify key-person dependency, workaround, unowned risk and capability-transfer gap.

Evidence to retain Role acceptance, training or competence evidence, control results, runbooks and exception log.

Decision or scoring rule A failed mandatory capability or control remains a gate and cannot be averaged away.

Output and template Capability and control rows in T03.

Acceptance gate READY, IMPROVE, CONTAIN, HOLD or STOP.

Leadership checkpoint COO confirms ownership at the proposed exposure, not merely current volume.

Human control point Qualified control owners retain accept, condition and refuse authority.

Failure modes and safeguards Training attendance is not competence and documentation is not operating ownership.

Change, stop or escalation condition Stop where mandatory duty lacks a competent, funded owner.

Handoff to the next step All evidence enters scale-readiness scenarios.

Step 10: Build bounded scale and containment scenarios

Purpose and decision served Compare realistic next exposures and safe alternatives.

Accountable owner Product Sponsor.

Delegated lead and contributors COO, CTO, finance, product, risk, service and customer owners.

Preconditions, inputs and access Accepted evidence from behaviour, outcome, reliability, support, economics and capability.

Actions

  1. Define improve, hold, bounded scale, containment, stop and retirement options.
  2. State eligible population, exposure, resources, dependencies, expected evidence and reversibility for each.
  3. Test downside and response capacity without inventing adoption or failure probabilities.

Evidence to retain Scenario definitions, assumptions, constraints, sensitivity and dissent.

Decision or scoring rule Scale is eligible only when every mandatory gate is accepted at the proposed boundary.

Output and template Scenario rows in T04.

Acceptance gate COMPARABLE, VALIDATE, REDUCE EXPOSURE or STOP.

Leadership checkpoint Sponsor confirms containment and retirement are credible choices.

Human control point Executives choose exposure; analysts do not produce an automatic score.

Failure modes and safeguards Do not compare detailed scale with vague hold or retirement options.

Change, stop or escalation condition Reduce exposure when evidence cannot support the proposed cohort or load.

Handoff to the next step Scenarios enter independent reconciliation.

Step 11: Challenge evidence and causal claims

Purpose and decision served Test whether the scale pack is reproducible, balanced and decision-fit.

Accountable owner Product Sponsor and CFO.

Delegated lead and contributors Independent challenger with research, data, technology, service, finance and risk responders.

Preconditions, inputs and access Versioned source extracts, metric contracts, scenarios, model and exception logs.

Actions

  1. Reproduce material behaviour, outcome, reliability, cost and burden claims.
  2. Test survivorship, selection, denominator drift, hidden support, double counting and contrary evidence.
  3. Record corrections, limitations, dissent and matters requiring more observation.

Evidence to retain Reconciliation report, challenge log, corrected versions and unresolved findings.

Decision or scoring rule Unresolved material defects remain visible and block only the decisions they affect.

Output and template Challenge rows across T02, T03 and T04.

Acceptance gate READY FOR DISPOSITION, CORRECT, VALIDATE or CONTAIN.

Leadership checkpoint Sponsor confirms adverse evidence has equal access to the decision pack.

Human control point Challenger signs the work performed, not product success.

Failure modes and safeguards Do not close contradiction through consensus without evidence.

Change, stop or escalation condition Hold or contain where a material claim cannot be reproduced.

Handoff to the next step The reconciled pack goes to human disposition.

Step 12: Make the executive operating disposition

Purpose and decision served Choose one bounded action from the complete post-launch evidence.

Accountable owner Product Sponsor and designated authority.

Delegated lead and contributors CFO, COO, CTO, risk, service, customer and decision secretary.

Preconditions, inputs and access Reconciled gate pack, scenarios, dissent, authority and stop routes.

Actions

  1. Review each mandatory gate separately before any aggregate view.
  2. Assign IMPROVE, HOLD, SCALE, CONTAIN, STOP or RETIRE with evidence and reason.
  3. Record population, exposure, resources, conditions, prohibitions, owner and review date.

Evidence to retain Signed disposition, gate states, source versions, dissent and resource authority.

Decision or scoring rule Scale requires accepted behaviour, outcome, reliability, support, economics, control and capability gates; other dispositions need the evidence relevant to their safe execution.

Output and template Executive disposition rows in T04.

Acceptance gate DISPOSITION RECORDED.

Leadership checkpoint Authority reads limitations, affected populations and reversal conditions before signature.

Human control point Only named authorities change exposure or accept residual risk.

Failure modes and safeguards Do not treat scale as permanent success or stop as permission to abandon affected users.

Change, stop or escalation condition Contain first when immediate exposure exceeds evidence or response capacity.

Handoff to the next step The bounded disposition transfers to operating owners.

Step 13: Execute, learn and renew or close

Purpose and decision served Keep the disposition conditional on current evidence and protect people through change or exit.

Accountable owner Product Sponsor.

Delegated lead and contributors Product operations, finance controller, service, technology, support and change owners.

Preconditions, inputs and access Signed disposition, accepted resources, measures, triggers and receiving owners.

Actions

  1. Transfer the exact boundary, evidence, controls, obligations and prohibited actions.
  2. Monitor decision measures and record changed evidence without overwriting the prior decision.
  3. Renew, improve, hold, contain, stop or retire at the trigger; protect data, continuity, support and affected people during closure.

Evidence to retain Handover acceptance, learning log, trigger record, renewed decision and closure evidence.

Decision or scoring rule An expired or materially changed gate does not inherit earlier scale authority.

Output and template Learning, renewal and closure rows in T04.

Acceptance gate TRANSFERRED, RENEWED, CHANGED or CLOSED.

Leadership checkpoint Sponsor reviews material evidence changes and residual obligations.

Human control point Receiving owners accept duties; affected-user and control authorities retain escalation.

Failure modes and safeguards Do not erase unsuccessful cohorts, incidents or prior dissent from the learning record.

Change, stop or escalation condition Reopen for material population, outcome, reliability, burden, cost, control or capability change.

Handoff to the next step Continue the accepted operating cycle or close with explicit service, data, support and knowledge transfer.

4. The Evidence & Measurement Checklist

Preflight and authority

  • The Product Delivery Governance Standard: From Discovery through Production Acceptance production acceptance is linked and valid. Evidence: production-acceptance record. Owner: Product Sponsor.
  • The decision names product, population, exposure and period. Evidence: signed scale charter. Owner: Product Sponsor.
  • Improve, hold, scale, contain, stop and retire remain available. Evidence: disposition contract. Owner: Product Sponsor.
  • Operating, technical and control authorities are explicit. Evidence: authority register. Owner: COO.
  • Launch is explicitly excluded as proof of success. Evidence: charter exclusion. Owner: Product Sponsor.

Evidence access and quality

  • Cohorts have stable entry, denominator and observation rules. Evidence: cohort contract. Owner: Data Owner.
  • Telemetry traces to event meaning and source lineage. Evidence: event specification. Owner: Analytics Lead.
  • Research, support, service and finance evidence is accessible. Evidence: evidence inventory. Owner: Product Operations Lead.
  • Excluded, assisted and harmed populations remain visible. Evidence: population register. Owner: Research Lead.
  • Material evidence has status, owner, period and limitation. Evidence: proof-state ledger. Owner: Proof Owner.

Method execution

  • Exposure, activation, meaningful use and outcome remain distinct. Evidence: behaviour contract. Owner: Product Lead.
  • Failed, abandoned, repeated and assisted tasks are represented. Evidence: task ledger. Owner: Service Owner.
  • Reliability is measured by critical journey and population. Evidence: service-level indicator contract. Owner: CTO.
  • Support demand and manual burden are classified by cause. Evidence: burden register. Owner: COO.
  • Actual lifecycle and unit economics reconcile to sources. Evidence: economic reconciliation. Owner: CFO.

Governance, privacy, security and risk

  • Population analysis respects lawful-use and consent boundaries. Evidence: privacy determination. Owner: Privacy Owner.
  • Accessibility conditions retain qualified human authority. Evidence: accessibility gate. Owner: Accessibility Owner.
  • Security and incident exposure is not hidden by aggregate availability. Evidence: risk and incident record. Owner: Security Owner.
  • Mandatory controls remain separate gates. Evidence: control readiness register. Owner: Risk Owner.
  • Emergency containment can override planned scale exposure. Evidence: containment authority. Owner: COO.

Deliverables and acceptance

  • The gate pack contains behaviour, outcome, reliability, support, cost and capability evidence. Evidence: pack index. Owner: Product Operations Lead.
  • Every scenario states population, exposure, resources and reversibility. Evidence: scenario record. Owner: Product Sponsor.
  • Contradictions and dissent appear beside the affected claim. Evidence: challenge log. Owner: Independent Challenger.
  • Receiving operating owners accept the bounded disposition. Evidence: handover acceptance. Owner: COO.
  • Closure includes affected people, data, support and continuity. Evidence: retirement plan. Owner: Service Owner.

Measurement

  • Meaningful adoption uses an accepted behaviour definition. Evidence: adoption measure contract. Owner: Product Lead.
  • Outcomes use an accepted baseline and eligible population. Evidence: outcome measure contract. Owner: Outcome Owner.
  • Reliability thresholds identify response actions. Evidence: service objective. Owner: CTO.
  • Support burden includes unresolved and transferred work. Evidence: support measure contract. Owner: COO.
  • Unit economics does not use denominator growth as value proof. Evidence: economic guardrail. Owner: CFO.

Decision and handover

  • Each mandatory gate has a separate state. Evidence: scale gate matrix. Owner: Product Sponsor.
  • The disposition states reason, exposure, conditions and owner. Evidence: signed executive record. Owner: Decision Authority.
  • Scale authority is limited to the accepted population and load. Evidence: exposure boundary. Owner: Product Sponsor.
  • The Product Delivery Governance Standard: From Discovery through Production Acceptance production authority remains historically distinct. Evidence: route-control record. Owner: CTO.
  • The Software Investment Business Case: Scope, Total Cost, Risk and Operating Economics is reopened for material investment-case change. Evidence: recase trigger. Owner: CFO.

Review, change and stop controls

  • Review triggers cover population, outcome, reliability, burden, cost and control. Evidence: trigger register. Owner: Product Sponsor.
  • Expired evidence cannot renew scale automatically. Evidence: evidence-expiry record. Owner: Proof Owner.
  • The prior decision and dissent remain immutable. Evidence: version history. Owner: Decision Secretary.
  • Containment has an owner, scope and release condition. Evidence: containment record. Owner: COO.
  • Stopped or retired products retain residual obligations and lessons. Evidence: closure and learning record. Owner: Product Sponsor.

Measurement contracts

Measure A: Meaningful adoption by eligible cohort

FieldRequirement
Outcome or decisionDecide whether intended people repeatedly perform the accepted value-related behaviour
MeasureMeaningful adoption by eligible cohort
TypeLeading
DefinitionEligible people meeting the accepted meaningful-behaviour condition divided by the eligible exposed cohort in the accepted period; report counts, assisted use and exclusions
Baselinebaseline required
SourceBehaviour outcome and adoption evidence ledger
OwnerProduct Lead
CadenceAt the accepted operating review cadence
ThresholdProduct Sponsor sets improve, hold or scale condition after baseline validation
GuardrailRegistration, exposure or one event is not meaningful adoption
AttributionCampaign, access, product, service and market contributors remain visible

Measure B: Accepted outcome by population

FieldRequirement
Outcome or decisionDecide whether the product contributes to the intended market or service consequence
MeasureAccepted outcome by population
TypeCommercial outcome
DefinitionEligible outcome units meeting the accepted definition divided by the eligible population and period, with contrary effects and uncertainty reported separately
Baselinebaseline required
SourceAuthoritative product, customer, operating and finance records
OwnerOutcome Owner
CadenceAt the accepted outcome review cadence
ThresholdProduct Sponsor sets improve, scale, contain or stop condition after validation
GuardrailCorrelation, usage and delivery completion are not causal proof
AttributionMarket, price, product, service and operating changes remain visible

Measure C: Critical-journey service attainment

FieldRequirement
Outcome or decisionDecide whether the service remains reliable for the journeys and people that matter
MeasureCritical-journey service attainment
TypeOperating
DefinitionEligible service events meeting accepted correctness, availability, latency, freshness or durability conditions divided by eligible events for each critical journey and cohort
BaselineThe Product Delivery Governance Standard: From Discovery through Production Acceptance production baseline required
SourceReliability Support Cost and Capability Register and monitoring system
OwnerCTO
CadenceContinuous monitoring with accepted human review cadence
ThresholdCTO and service owner set improve, contain or stop conditions
GuardrailAggregate uptime cannot offset a failed mandatory journey or population
AttributionApplication, dependency, data, network and operating causes remain separate

Measure D: Supportable demand and toil

FieldRequirement
Outcome or decisionDecide whether support and operations can sustain current or proposed exposure
MeasureSupportable demand and toil
TypeOperating/adoption
DefinitionSupport demand, repeat contact, escalation, manual correction and recurring toil by eligible use or service unit, with backlog and competent capacity shown separately
Baselinebaseline required
SourceSupport system, workflow observations and workforce records
OwnerCOO
CadenceAt the accepted service review cadence and before scale
ThresholdCOO sets improve, hold, contain or stop condition
GuardrailLow recorded contact is not good performance when reporting access fails
AttributionProduct, process, policy, training, supplier and user-context causes remain visible

Measure E: Accepted lifecycle unit economics

FieldRequirement
Outcome or decisionDecide whether observed value remains supportable at current and proposed exposure
MeasureAccepted lifecycle unit economics
TypeInvestment efficiency
DefinitionAccepted lifecycle cost categories related to a defined eligible outcome or service unit, reporting fixed, variable, stepped, transferred and deferred cost separately
BaselineThe Software Investment Business Case: Scope, Total Cost, Risk and Operating Economics case and validated operating baseline required
SourceFinance actuals, consumption records and operating-burden register
OwnerCFO
CadenceAt finance review and before scale or material commitment
ThresholdCFO sets improve, recase, hold or stop condition after allocation validation
GuardrailFalling unit cost caused only by denominator growth is not value proof
AttributionVolume, rate, architecture, supplier, support and allocation changes remain visible

Measure F: Operating capability readiness

FieldRequirement
Outcome or decisionDecide whether people and controls can own the proposed product boundary
MeasureOperating capability readiness
TypeGuardrail
DefinitionMandatory operating obligations with named competent owner, capacity, access, funding and accepted control evidence divided by all mandatory obligations; report each failed gate
Baselinebaseline required
SourceReliability Support Cost and Capability Register
OwnerCOO
CadenceBefore scale and at material operating change
ThresholdQualified owners set ready, improve, contain or stop conditions
GuardrailA total readiness score cannot compensate for one failed mandatory duty
AttributionProduct, engineering, support, security, data, supplier and workforce gaps remain separate

Evidence classifications used in this guide

  • VERIFIED: authoritative retained evidence supports the fact within its population, period and limitation.
  • INFERRED: an interpretation is traceable to evidence but remains distinguishable from observed fact.
  • PROPOSED: a cohort, threshold, scenario, improvement or scale boundary awaits human acceptance.
  • REQUIRES VALIDATION: a material behaviour, outcome, reliability, support, cost or capability claim is not decision-fit.

Controlled source record

SourceExact useApplicability limitCurrency and review trigger
GOV.UK Service Standard; GOV.UK Measuring Success; Google SRE service-level objectives; Google SRE practices; FinOps Framework 2025Live-service measurement, reliability, incident response and technology-finance disciplinesGeneral guidance; not proof of local adoption, causal impact, reliability, cost, capacity or scale fitnessRecheck source editions and local evidence, controls and exposure boundary at every post-launch gate or material change

Use the method with AI

A prompt to help you work through this guide

Use this prompt to organise your analysis. Share only evidence you are authorised to provide to that model. A person must remain responsible for the decision, privacy limits and final action.

Copy and adapt

You are helping me apply the Abrasim operating guide: “The Product Adoption, Operability and Scale Gate: Proving Value after Launch”.

Situation: A product is declared successful at launch despite weak adoption, supportability, economics or operating evidence.
Decision to make: Reconcile one production product's real behaviour, task, outcome, reliability, support, cost, control and capability evidence, then issue an improve, hold, bounded scale, contain, stop or retire disposition with owned operating and learning conditions.
Scope boundary: A post-launch operating gate covering populations and cohorts, meaningful behaviour, task success, accepted outcomes, unintended effects, service reliability, support burden, lifecycle and unit economics, operating capability, controls, bounded scale and containment scenarios, independent challenge, disposition, renewal and responsible closure.

Use only the evidence I provide. Do not invent facts, benchmarks, sources, outcomes, customer research or legal conclusions. Keep VERIFIED, OBSERVED, INFERRED, PROPOSED and UNKNOWN separate. Ask focused questions when the evidence or authority is missing.

Help me work through this method by returning:
1. An evidence table with claim, source, date, confidence and limitation.
2. The strongest competing explanations, including what would disprove each one.
3. Decision options with trade-offs, dependencies and the cost of waiting where evidence supports it.
4. The next smallest evidence-gathering action, its accountable owner and acceptance test.
5. A proceed, change, validate, defer or stop recommendation that a named human decision-maker can review.

Treat the attached Abrasim working pack as a blank working record. Do not fill missing rows with plausible data. Flag privacy/POPIA, security, accessibility, safety and authority issues. Cite primary sources for external claims and show uncertainty. End with the conditions that would make us change course or stop.

My organisation-specific evidence and constraints:
[Paste evidence, links, dates, decisions and limitations here]

Working rule: AI can help organise evidence and expose questions; it cannot establish truth, approve risk, make the business decision or replace qualified legal, privacy, security or accessibility review.

Next decision

Decide whether a production-accepted product should improve, hold, scale within a named boundary, contain exposure, stop or retire, using reconciled behaviour, outcome, reliability, support, lifecycle economics, control and operating-capability evidence.

Use the product opportunity sprint to assess one defined product or platform idea, its feasibility, MVP boundary and operating considerations before separately governed production acceptance and post-launch scale work; it does not deliver a scale decision. A capable internal team or narrower specialist may be sufficient when the decision, evidence boundary, authority and required competence are narrow and independently challengeable.