Transformation Operating Model

Issue, Audience & Provenance

1.1 The Vision — In the Product Owner's Words

I'm teaching Australians how to walk — financially. Right leg, left leg. Active income, passive income. Not hopping on one leg and hoping the other shows up. Walking. Naturally. The way the body was built to move.

That's what Flip 360 is. A way for every ordinary Australian — and eventually every ordinary human — to put a second leg down. To stop hopping. To start walking.

— Mathew Punter, Founder & Product Owner, Flip 360. From the first working session, recorded May 2026.

This is not a software project. It is a movement, with software as its trust engine — and Mathew Punter is its founder, protagonist and the candidate for the theory of change. Two decades operating one of the active legs (mortgage broking) at a level of excellence that has produced multiple successful business exits has given him something rarer than capital: he knows what walking looks like in the financial life of an ordinary Australian, because he has lived both legs of it.

The thesis of Flip 360 — in his own framing — is that ordinary people can be taught the right leg. Passive income through structured business referral, made as natural as putting one foot in front of the other. Paired with anyone's existing active income, the combination is the paradigm shift in how the modern Australian builds a financial life. Two legs. Rhythm. Forward motion. A life that compounds while it is being lived.

1.2 The Theory of Change

Flip 360's theory of change rests on three load-bearing pillars. Each pillar must hold, or the movement collapses.

1.3 Critical Success Factors

The Programme will be measured against seven Critical Success Factors. These are non-negotiable; the absence of any single CSF invalidates the Programme.

1.4 Strategic Reframe

The incumbent platform — HubSpot — is a world-class generalist Customer Relationship Management (CRM) and marketing automation suite. It is not, however, a multi-vertical professional-services commission ledger with forensic-grade integrity. The mismatch is not one of quality; it is one of category. We are using a hammer on a screw.

2.1 Fit Assessment — Objective Scoring

2.2 The Make-vs-Buy Decision

Every Tier-1 transformation interrogates a Make-vs-Buy decision through five lenses. The Flip 360 conclusion is set out below.

Four of five lenses favour Make. Most decisive: forensic integrity cannot be retrofitted into a generalist CRM. It must be in the foundations.

2.3 Decommission Strategy — Parallel Run, Not Cold Cutover

HubSpot will not be unplugged. It will be parallel-run against the custom platform until three exit criteria are met:

1. Three consecutive payout cycles reconcile to zero variance on the custom platform.
2. Member self-service adoption exceeds 80% on the custom platform.
3. The Product Owner formally signs the Decommission Authority at a Steering Committee.

This is standard Tier-1 cutover discipline — never burn the boats until the bridge is load-tested.

The Transformation Operating Model (TOM) is the lattice on which all Flip 360 delivery hangs. It defines who decides, who does, who governs and who assures. At inception we run a lean four-layer TOM, expanding into a full PMO structure as additional workstreams come online (refer Chapter Ten).

3.1 The Four Layers

3.2 Operating Principles

1. Outcomes over outputs. Velocity of story points is meaningless if member entitlements are wrong. We measure value, not effort.
2. One backlog, one truth. Every Flip 360 idea — Mathew's, the squad's, a member's — lands in a single backlog. Triage, prioritise, schedule. Nothing is lost; nothing is duplicated.
3. Pull, not push. The Delivery Squad pulls work into the sprint at Sprint Planning. Work is never pushed mid-sprint by stakeholders, including the Product Owner.
4. Definition of Done is sacred. A story is not "done" until it satisfies the Definition of Done (Chapter Six). Otherwise we accumulate technical debt and reputational debt.
5. Cadence creates trust. Predictable rhythm — sprints, demos, retros — builds stakeholder confidence faster than any status report.
6. Transparency is the default. Backlog, sprint board, burndown, risks — all visible to all participants by default. Privacy is the exception that requires justification.

3.3 RACI at Programme Level

Legend: R = Responsible · A = Accountable · C = Consulted · I = Informed (RACI per RACI matrix conventions, Project Management Institute).

4.1 The Product Owner — Mathew Punter

In Scrum, the Product Owner is one of three accountabilities (alongside Scrum Master and Developers) defined by the Scrum Guide (Schwaber & Sutherland). In Tier-1 consulting practice, the Product Owner is treated as a C-suite-grade accountability — comparable in seniority to a business unit head. Mathew, as Founder, is the natural and correct holder of this role.

What the Product Owner does

• Holds and articulates the product vision (in Flip 360's case, the walking metaphor; the active+passive thesis).
• Owns and prioritises the Product Backlog. Single decider on order.
• Defines acceptance criteria with the squad; accepts or rejects completed work at Sprint Review.
• Maximises value delivered per sprint; ruthlessly says "not yet" to lower-value ideas.
• Engages stakeholders (members, brokers, regulators, partners) to bring market signal into the backlog.
• Attends Sprint Planning, Sprint Review, and Backlog Refinement. Attends Daily Standup optionally.

What the Product Owner does NOT do

• Assign tasks to individual squad members. The squad self-organises.
• Dictate technical implementation. The squad owns the how.
• Inject mid-sprint scope changes. New ideas go to the backlog for next sprint.
• Run ceremonies. The Delivery Lead facilitates.
• Manage the team's HR matters or velocity. That's the Delivery Lead's remit.

4.2 The Delivery Lead — Engagement Director / PMO Director (and Scrum Master)

The Delivery Lead role on Flip 360 is me — Carla Oliver, acting as Engagement Director / PMO Director. This is the senior, end-to-end accountable role: I own the delivery of the entire Flip 360 programme — across every workstream — on time, on scope, and on budget. This is the role I have played at Capgemini, Accenture and Deloitte, and it is the role Flip 360 needs at its centre.

Sitting underneath that Engagement Director role is a second, squad-level role: the Scrum Master. That role can be filled by me, or — equally credibly — by Josie from Your Digital Team. Josie has a comparable consulting skill set and delivery experience, and she is a natural systems thinker, which is precisely what a good Scrum Master is: someone who sees the whole system the squad operates in and removes friction from it. Either of us can wear the Scrum Master hat; the Engagement Director hat stays with me.

4.3 The Delivery Squad

Cross-functional, self-organising, accountable for turning Product Backlog items into a working, tested, deployed Increment each sprint.

For Tranche 1 my squad will comprise the following roles. Each is filled by a dedicated Anthropic AI agent, briefed, reviewed and governed by Carla:

4.4 Scrum Master vs Project Manager — A Crucial Distinction

Mathew will reasonably ask: "Aren't you just my Project Manager?" The answer is no, and the distinction matters. As Flip 360 scales we will likely need both, in different parts of the operating model.

For Flip 360 today we run Scrum (continuous product). When we open parallel workstreams — say, a discrete ASIC compliance project, or a one-off member-data migration — we will introduce Project Managers to run those time-bounded efforts under the PMO (Chapter Ten).

The Software Development Life Cycle (SDLC) is the end-to-end discipline of taking an idea from inception to operation. Agile is not a replacement for the SDLC — Agile is the delivery engine that sits inside it. Many founders confuse the two. The distinction is critical because the SDLC contains stage gates that Agile does not.

5.1 The Six Phases

5.2 How Agile Sits Inside the SDLC

Phases 1 (Discover) and 2 (Design) are completed at programme inception and revisited per epic. Phases 3 (Build), 4 (Test), and 5 (Release) recur every sprint — a working increment is built, tested and releasable each fortnight. Phase 6 (Operate) is continuous. Agile, therefore, lives primarily in the Build-Test-Release loop, with Discover and Design feeding it.

5.3 Stage Gates & Value Gates

Between phases sit stage gates — go/no-go decision points that prevent waste. In Tier-1 practice these are non-negotiable.

5.4 Where the Big Five Add Disproportionate Value

Across 25 years of delivery, the consistent observation: Tier-1 firms generate the bulk of their client value in Discover, Design, and the early Operate phases — not in Build. The reason: Build is where the work is most commoditised; Discover and Design are where the irreversible decisions are made. Flip 360 will invest disproportionately in Discover and Design (this document, and Volume 2) and apply industrial discipline to Build through the Agile engine.

6.1 Why Agile for Flip 360

Flip 360 will adopt Scrum, augmented with elements of the Scaled Agile Framework (SAFe) as additional workstreams come online. Scrum is chosen because:

• The Product Owner is a Founder with high-velocity ideation — Scrum's fixed cadence acts as a productive constraint.
• Member needs will evolve as the network grows — Scrum's empirical, iterative loop accommodates change.
• Forensic integrity requires continuous testing and continuous demonstration — Scrum bakes this in.
• Trust must be earned with the Founder through repeated, observable delivery — Scrum's Sprint Review is purpose-built for this.

6.2 Scrum at a Glance

6.3 The Artefacts

6.4 The Ceremonies

6.5 User Stories — The Currency of the Backlog

Every backlog item is expressed as a User Story using the "I am... I need... so I can..." form. This format, popularised by Mike Cohn (User Stories Applied), forces every item to be expressed in the voice of a real user pursuing a real outcome.

Stories must satisfy INVEST (Bill Wake): Independent, Negotiable, Valuable, Estimable, Small, Testable. The squad enforces this at Backlog Refinement.

6.6 Epics, Features and Stories — The Hierarchy

6.7 Story Points, Velocity & Forecasting

The squad estimates stories in Story Points using a modified Fibonacci scale (1, 2, 3, 5, 8, 13). Points are a measure of relative complexity, risk, and effort — not hours. Over the first three sprints the squad establishes its velocity (average points completed per sprint), which becomes the basis for forecasting when future backlog items will land.

This is how we answer the Product Owner's most important question — "When will it be done?" — with mathematical honesty rather than optimistic guesswork.

In immature organisations the backlog is treated as a to-do list. In Tier-1 practice the backlog is treated as a strategic asset — the most valuable artefact in the programme — because it is the single living record of every commitment, every option, and every deliberate deferral the business has made about its future product. For Flip 360, the backlog is the place where Mathew's entrepreneurial energy is converted into structured value.

7.1 The Idea-to-Shipped Flow

This flow is the most important diagram in this document for Mathew. Every idea he has, every member observation, every steering directive — enters at the left and exits at the right. Nothing is lost. Nothing is duplicated. Nothing jumps the queue without explicit prioritisation.

7.2 Prioritisation Frameworks

The Product Owner has three frameworks to lean on. They are tools, not religions — use the one that fits the decision.

7.3 The Definition of Ready (DoR)

A story enters the Sprint Backlog only when it satisfies the Definition of Ready. For Flip 360 we adopt:

• Written in "I am... I need... so I can..." form.
• Acceptance Criteria documented (typically Given/When/Then).
• Sized in Story Points by the squad.
• Dependencies identified and unblocked, or explicitly scheduled.
• Non-Functional Requirements (performance, security, ledger-integrity) noted where relevant.
• Designs (if UX-affecting) sketched or wire-framed.

7.4 The Definition of Done (DoD)

A story exits the sprint as "Done" only when it satisfies the Definition of Done. For Flip 360 we adopt the most stringent variant — appropriate for a financial system:

• Code reviewed by a second engineer (four-eyes principle).
• Automated tests written and passing (unit + integration).
• Ledger-integrity tests pass — no story affecting commission may merge with a single ledger test failure.
• Documentation updated (user-facing and technical).
• Deployed to a non-production environment and exercised.
• Acceptance Criteria demonstrated to the Product Owner at Sprint Review and explicitly accepted.
• No new Critical or High severity defects introduced.

Governance is not bureaucracy. Done well, governance is the minimum set of touchpoints required to keep a programme on its value trajectory, surface risk early, and give stakeholders confidence. Done poorly, it becomes status theatre. Flip 360 will run the leanest defensible governance footprint.

8.1 The Governance Stack

8.2 Reporting Discipline

The Steering Committee will receive a single one-page Programme Dashboard each month, covering:

1. Value Delivered — features shipped, business outcomes enabled.
2. Velocity Trend — story points completed per sprint, rolling six-sprint average.
3. Burndown / Burnup — backlog trajectory against scope.
4. RAG Status — Red / Amber / Green on Scope, Schedule, Quality, Risk.
5. Top 5 Risks & Issues — from the RAID log, with owners and ETAs.
6. Decisions Required — anything blocked pending Steering input.

8.3 The Sprint Review as a Value Demonstration Ritual

If the Steering Committee is the strategic forum, the Sprint Review is the operational ritual that builds founder trust. Every fortnight Mathew sees, with his own eyes, working software addressing real Flip 360 problems. Demonstration beats documentation, every time. Over the course of a year that is 26 such demonstrations — 26 opportunities to course-correct, celebrate, or pivot. No traditional waterfall programme provides anything close to this density of feedback.

McKinsey's research repeatedly puts the transformation failure rate at around 70% — and the dominant reason is not technology, it is the absence of structured change management. Flip 360 is fundamentally a behavioural movement (active+passive walking) wrapped in a software platform. Without a deliberate change layer the platform will be a beautiful, unused asset.

9.1 Prosci ADKAR — The Individual Change Model

The ADKAR model (Jeff Hiatt, Prosci) is the most widely adopted individual-level change framework in the world. Every Flip 360 member moves through five stages. The platform will explicitly track and support each.

Each member's ADKAR stage is a first-class data point in the platform. The system knows who is stuck where, and prompts the right intervention at the right time. This is what makes Flip 360 a capability platform rather than merely a payments platform.

9.2 Kotter's 8 Steps — The Organisational Change Model

Where ADKAR addresses the individual, John Kotter's 8-Step Process addresses the broader movement. We apply it to the Flip 360 network as a whole.

1. Create Urgency — surface the cost of one-leg-only living.
2. Form a Guiding Coalition — early adopters across verticals, championed by Mathew.
3. Form a Strategic Vision — the walking metaphor, codified.
4. Enlist a Volunteer Army — first 100 members become advocates.
5. Enable Action by Removing Barriers — frictionless onboarding and commission visibility.
6. Generate Short-Term Wins — celebrate first commissions publicly.
7. Sustain Acceleration — add verticals, scale, deepen capability.
8. Institute Change — Flip 360 becomes the default operating mode of a generation.

9.3 McKinsey's Influence Model

To shift behaviour at scale, McKinsey's Influence Model identifies four reinforcing levers. Flip 360 must operate all four.

A Project Management Office (PMO) is the organisational function that standardises and supports project, programme and portfolio delivery. Flip 360 does not need a PMO today — the programme has one workstream and one squad. We will stand up a PMO when defined trigger conditions are met.

10.1 PMO Archetypes (Gartner / PMI)

Flip 360's likely path: Directive PMO at first (because we are scaling fast from low maturity), evolving to Controlling as workstream leaders mature.

10.2 Trigger Conditions to Stand Up a PMO

The PMO is established when any two of the following are true:

1. Three or more concurrent workstreams active.
2. Total programme spend exceeds AUD 1.5M annualised.
3. Membership exceeds 500 active businesses on the platform.
4. A regulated workstream (e.g. ASIC / NCCP compliance) is opened.
5. Multiple jurisdictions in play (national rollout beyond a single state).

10.3 Future-State Workstream Architecture

10.4 How Scrum Masters and Project Managers Coexist

In the future state, Scrum Masters run continuous-product workstreams (Platform Build, Analytics) and Project Managers run finite-duration workstreams (Onboarding waves, Compliance projects, jurisdictional rollouts). Both report through the PMO. The Programme Director (today: the Delivery Lead) sits above and orchestrates.

Drawn from the Capability Maturity Model Integration (CMMI) and adapted for Flip 360, the maturity roadmap tells the Steering Committee where the programme sits today, where it is going, and what good looks like at each level.

The 12-month roadmap focuses on moving Flip 360 from Level 1 to Level 2, then on to Level 3. The Delivery Lead will report maturity progression as part of the monthly Programme Dashboard.

This chapter is written directly to Mathew. The first 90 days are formative — they install the rhythm and the muscle memory. If we get the first 90 days right, the next 900 follow.

12.1 Days 1–14 — Orientation & Backlog Seeding

• Read Volume 1 (this document) and Volume 2 (Enterprise Architecture) in full.
• Two-hour Product Owner masterclass with the Delivery Lead.
• Brain-dump session: every Flip 360 idea, observation, and ambition into the Idea Inbox. Nothing held back.
• First Triage: Delivery Lead and PO sort the Idea Inbox into the seeded Product Backlog.
• Establish ceremony calendar; block all sprint events in the diary for the next quarter.

12.2 Days 15–42 — First Two Sprints

• Sprint 1 goal: stand up the immutable event log and first proof of the hash chain.
• Sprint 2 goal: register first business entities; record first referral events end-to-end.
• PO chairs first Steering Committee at end of Sprint 2; presents to himself (and any advisors he brings in) the first demonstrable Increment.
• Velocity baseline begins to emerge.

12.3 Days 43–90 — Velocity, Value, Cutover Planning

• Sprints 3–6 build out the commission engine, leaderboard MVP, and first member-facing dashboard.
• HubSpot parallel-run plan signed off at Steering Committee.
• First three members (friendly pilots) onboarded to the custom platform.
• First commissions calculated and paid through the platform with full evidence pack.
• End of 90 days: PO confidence — Mathew formally states whether he is "ready to scale".

12.4 Success Criteria for the Product Owner

1. The Product Owner has attended every Sprint Review and Backlog Refinement.
2. The Product Backlog contains ≥ 60 well-formed items, prioritised.
3. Zero ideas have been lost — every captured idea is on the backlog or explicitly closed with reason.
4. The PO has accepted ≥ 80% of stories at first Sprint Review (a healthy rate; 100% suggests acceptance criteria were too loose).
5. The PO can articulate, in his own words, the Definition of Done and the prioritisation rationale.

Every Tier-1 programme maintains a RAID log — Risks, Assumptions, Issues, Dependencies. This is the single document the Delivery Lead reviews every morning. It is the immune system of the programme.

Every RAID item has an owner, a status, a target resolution date, and a mitigation plan. Top five are surfaced to Steering monthly.

Plain-English definitions of every acronym used in this Volume. Designed for the Product Owner to skim and absorb. Cross-referenced with the chapter of first use.

The frameworks invoked in this Volume are not invented; they are drawn from the canonical literature of management consulting, agile delivery, and organisational change. The list below is the working library every Flip 360 leader should own.

Agile & Delivery

• The Scrum Guide — Ken Schwaber & Jeff Sutherland. The canonical 13-page definition of Scrum.
• Scrum: The Art of Doing Twice the Work in Half the Time — Jeff Sutherland.
• User Stories Applied — Mike Cohn.
• SAFe Reference Guide — Scaled Agile, Inc. The enterprise-scale Agile playbook.
• The Principles of Product Development Flow — Donald Reinertsen.

Change Management

• ADKAR: A Model for Change in Business, Government and our Community — Jeffrey Hiatt (Prosci).
• Leading Change — John Kotter.
• The Heart of Change — John Kotter & Dan Cohen.
• Switch: How to Change Things When Change Is Hard — Chip & Dan Heath.

Strategy & Operating Model

• The McKinsey Way — Ethan Rasiel. Inside the Tier-1 consulting craft.
• The McKinsey 7S Framework — Peters, Waterman, Phillips. Still the cleanest organisational diagnostic.
• Good Strategy / Bad Strategy — Richard Rumelt.
• Wiring the Winning Organization — Gene Kim & Steven Spear.

Programme & Project Management

• A Guide to the Project Management Body of Knowledge (PMBOK Guide) — Project Management Institute.
• Managing Successful Projects with PRINCE2 — AXELOS.
• Managing Successful Programmes (MSP) — AXELOS.

Team & Leadership

• The Five Dysfunctions of a Team — Patrick Lencioni.
• Turn the Ship Around! — L. David Marquet. Intent-based leadership for self-organising teams.
• An Everyone Culture — Robert Kegan & Lisa Lahey.

A.1 The Flip 360 Walking Metaphor — Formalised

A.2 Programme Org Structure — Current State

A.3 Sprint Cadence — Two-Week Rhythm

A.4 Idea-to-Shipped Journey (Mathew's Lens)

A.5 ADKAR Member Journey on Flip 360