Process Overview
End-to-end flow at a glance
Strategy & Roadmap
Once / year, reviewed at 6 months
Annual OKRs
L1 → L2 → L3
Quarterly Planning
Prioritise & categorise A/B/C/D
Delivery
Discovery, build, GTM & release
Not a constrictive waterfall — different initiative types need different process weight.
Strategy & Roadmap
Done once per year by domain, reviewed at 6 months
- Ecosystem mapping, market positioning, competitor assessment
- Big blocks of work for the domain
- Links to proactive budgeting
- 6-month review & course correction
Once / year 6-month review
↓ Annual planning timeline
Annual Planning Timeline
.jpeg)
Annual OKRs
L1 → L2 → L3 cascade, tracked quarterly
- L3 gives domain owners strategic guidance for the year
- Initiatives are outcome-driven investments to achieve Key Results
- Each Initiative must link to at least one active Key Result
- Quarterly check: are you on track?
Capacity split
~70% Product Roadmap ~20% Tech Initiatives ~10% KTLO
↓ Quarterly planning cycle & Initiative lifecycle
Quarterly Planning Cycle
.png)
Quarterly Planning
Prioritise initiatives → categorise each one
📋 Prioritisation
- Review initiatives against OKRs
- Assess capacity & dependencies
- Commit to quarterly scope
- Align across teams
🏷️ Categorisation
Each initiative is classified into one of four categories:
A — Backoffice
B — Small Feature
C — Major Update
D — New Product
Category determines the process path →
Initiative Categories
Four types — each builds on the process of the one below
Backoffice / Architectural
- Internal tooling
- Technical debt
- Infrastructure work
- No client-facing impact
Small Feature
- Minimal client impact
- Well-understood scope
- Low risk
- Incremental improvement
Major Product / Workflow Update
- Significant client impact
- Changes existing workflows
- Cross-team dependencies
- Requires stakeholder alignment
New Product / Category
- Entirely new offering
- New market or segment
- High uncertainty
- Needs full GTM
Process by Category
Categories are cumulative — each includes everything below plus its own additions
| Category | Discovery | Gate | GTM | Stakeholders |
|---|---|---|---|---|
| A Backoffice | None — just do it | Arch Review → requirements + UAT criteria | None | Tech Lead |
| B Small Feature | Light discovery | Arch Review → requirements + UAT criteria | Lightweight | Trio |
| C Major Update | Full discovery | Cross-functional requirements gathering with SPOCs | In parallel to delivery | Trio + extended team |
| D New Product | Comprehensive discovery | Cross-functional requirements gathering with SPOCs | Full GTM from day one | Trio + extended team + leadership |
↑ Each row inherits all requirements from the rows above it. ↓ Drill into each category below.
A Backoffice / Architectural
No discovery — just do it
What's expected
- Arch Review with Tech Lead
- Define functional requirements
- Define nonfunctional requirements
- Write UAT criteria
Then go build
- No discovery needed
- No stakeholder sign-off
- No GTM
- Straight to delivery
This is the baseline — every higher category includes these steps.
B Small Feature
Light discovery — minimal client impact
Inherited from A
- Arch Review with Tech Lead
- Functional & nonfunctional requirements
- UAT criteria
Added at B
- Basic solution design with the Trio
- Quick impact assessment on existing clients
- Lightweight GTM consideration
C Major Product / Workflow Update
Full discovery — significant client impact
Inherited from A + B
- Arch Review, requirements, UAT criteria
- Problem validation & solution design
- Client impact assessment
Added at C
- User research & prototyping
- Cross-team dependency mapping
- Cross-functional requirements gathering — get SPOCs in the room
- Functional, nonfunctional & MVP requirements defined together
- GTM planning starts in parallel to delivery
D New Product / Category
Comprehensive discovery — new territory
Inherited from A + B + C
- Arch Review, requirements, UAT criteria
- Problem validation, solution design, prototyping
- Dependency mapping, cross-functional requirements, SPOCs
Added at D
- Market research & business case
- Extensive user research — multiple rounds
- Leadership sign-off
- Full GTM from day one
Delivery
Trio + extended team, cross-functional requirements, named SPOCs
👥 Core Trio
PM, Designer, Tech Lead
🤝 Extended Team SPOCs
Named individuals — physical presence at reviews, not tick-box approval
📄 Cross-Functional Requirements
Functional Requirements
What it must do
Nonfunctional Requirements
Page load 0.3–0.5s, dropout rates
MVP Requirements
Step 1: define minimum scope
UAT Criteria
Step 2: deliver & accept
Stakeholder sign-off with named individuals for C & D categories
GTM & Release
GTM runs in parallel to delivery — not after
A — GTM Planning In parallel
- Starts alongside delivery, not after
- Front-load collaboration with commercial teams
- Customer communication plan
- Training & support readiness
Cat C: GTM in parallel | Cat D: Full GTM from day one
B — Release Management & Launch Sequential
- Release process & deployment
- UAT sign-off & acceptance
- Staged rollout plan
- Monitoring & success metrics
- Post-launch review
Follows delivery completion — managed launch process
Summary
The full flow, end to end
Strategy & Roadmap
Once / year, reviewed at 6 months
Annual OKRs
L1 → L2 → L3 cascade
Quarterly Planning
Prioritise & categorise A/B/C/D
Delivery
Discovery, build, GTM & release
Not a constrictive waterfall — a common-sense approach where different initiative types get the right amount of process weight.