Anonymised operating model
Regulated product expansion
A readiness model for country expansion.
Country launches become risky when implementation progress, external proof, and customer readiness collapse into one status. This is how I frame the system and the evidence each promise needs.
The situation
The status was too simple for the system.
A new country can look like a bounded delivery project: interpret the mandate, add the fields, configure validation, and ship. The work stops being linear as soon as the same rule touches direct onboarding, shared platform behaviour, partner APIs, operating evidence, and the promise a commercial team can make.
The core problem is language. One team can mean "the code is ready" while another hears "a customer can use it". Both say the country is ready.
Teams need to move implementation forward without turning partial proof into a customer promise.
Direct customers and partner-led journeys
Product direction, readiness framing, evidence, and cross functional execution
Onboarding, platform logic, APIs, operations, and commercial controls
External approval and market status remain unproved until the relevant party accepts them
The operating model
Replace one percentage with four gates.
These gates are not maturity levels. Each answers a different question and needs its own evidence.
Build ready
Can the team implement this safely?
The requirement, product boundary, affected journeys, and ownership are clear enough to build.
Local proof
Does the intended journey work under controlled conditions?
Representative data passes through the product with the expected rules, outputs, and visibility.
External proof
Do the outside dependencies behave as expected?
The journey has been exercised against the network, partner, authority, or system it depends on.
Customer ready
Can the product defend the promise being made?
Onboarding, recovery, support, operating evidence, and the remaining exceptions have owners.
Architecture as product work
The rule has to live somewhere.
The placement of a country rule changes cost, risk, and the journeys that can break. The product decision is incomplete until the team understands that boundary.
Country configuration
Keeps local behaviour isolated, but can create a growing set of exceptions.
Shared platform logic
Creates consistency across markets and increases the blast radius of a change.
Partner contract
Can simplify the product boundary while creating migration work for existing integrations.
Operating evidence
Can bridge a temporary gap, but leaves work the product still has to own.
Decision framework
Make the tradeoff visible.
Where should the rule live?
Keep country behaviour isolated unless the underlying meaning is genuinely shared.
Trace the requirement across existing customer and partner journeys before choosing the boundary.
What counts as proof?
Use evidence from the same journey and layer as the claim being made.
A visible screen, an API response, a raw payload, and external acceptance prove different things.
Who owns the next gate?
Attach one named owner and the next expected artifact to every unresolved dependency.
A status without an owner or a next proof is an observation, not a plan.
What can the commercial team say?
Bind the promise to the strongest completed gate, not the most optimistic forecast.
Candidate dates and passing tests stay separate from approved customer commitments.
The evidence receipt
Keep the proof attached to the decision.
A green status is weak if nobody can reconstruct what changed it. I prefer a small receipt that travels with the decision.
- 01
Source
The rule, request, customer need, or external dependency that created the decision.
- 02
Assumption
What the team currently believes, including the part that has not been proved.
- 03
Test
The journey, payload, environment, or external interaction used to examine the assumption.
- 04
Owner
The person responsible for producing or accepting the next piece of evidence.
- 05
Remaining uncertainty
The promise the product still cannot safely make.
What becomes possible
A clearer promise, without slowing the build.
This model lets engineering progress when the implementation boundary is understood. It also keeps product honest about the external proof, operational ownership, and customer promise that may still be open.
The useful outcome is not a greener dashboard. It is a shared language for what is true, who owns the next proof, and what the product can safely say today.
The strongest status is the one that tells the next team exactly what is true.