The numbers that matter
What kind of business is PADI?
PADI is a B2B2C ecosystem — meaning every meaningful customer interaction involves three parties: PADI (the organisation that sets standards and owns the brand), dive shops + instructors (the operators who deliver the experience), and divers (the consumers who pay). This is critical to understand, because it shapes every technology decision:
🏢 B2B layer (PADI ↔ Pros)
PADI sells annual membership to ~6,500 dive shops and ~135K Pros. They're the operational backbone. Without them, PADI doesn't certify divers — instructors do, in shops, on dives. PADI provides standards, eLearning, marketing kits, and the eCard system.
🏪 B2B2C layer (Pros ↔ Divers)
Dive shops use PADI's brand and tools to sell courses to consumers. They take the lead, run the course, certify the diver, and PADI gets attribution and royalty. 60% of certifications flow through this channel.
🤿 B2C layer (PADI ↔ Divers)
PADI sells direct to divers: eLearning courses, Club subscriptions, certification cards, and digital products. This is the growing direct channel — and the core of the modernisation programme.
Why this layered model creates the friction we're solving
PADI generates the lead, but the dive shop closes the sale. A potential diver searches Google, lands on padi.com, looks up a local shop, calls the shop, books on WhatsApp, arrives in person, pays the shop. PADI sees the top of the funnel and gets the certification royalty at the end — but everything in between (the conversation, the payment, the relationship) happens off-platform.
This is why PADI can't measure attribution, can't personalise journeys with shop-side data, and can't optimise the funnel in the way a pure DTC company could. The modernisation isn't trying to remove dive shops from the equation — it's trying to give PADI better visibility into and tools for that handoff.
The five strategic pillars from PADI's CEO ("Pillars of Change")
1 · People
Build a global community of "Torchbearers" — divers, instructors, advocates. PADI Club is the consumer arm of this pillar.
2 · Planet
PADI AWARE — conservation arm. Adopt the Blue, Dive Against Debris. Embedded in mission, brand, and content.
3 · Education
Training & certification — the core revenue engine. eLearning, in-person, instructor pathway.
4 · Industry
Pros + dive shops — the network that delivers the experience. Operator tools, business support.
★ The unifying thread
Every digital touchpoint must serve the mission — not just transact. This is why MyPADI matters. It's the moment the diver realises they're part of something bigger.
The three in-scope revenue streams
The acquisition history that shaped today's fragmentation
PADI didn't build this fragmented architecture on purpose — it grew through acquisitions, and each one came with its own tech stack:
- 2019: PADI Club relaunch — consolidated from legacy membership systems. Recurring billing introduced. Migrated Braintree → Stripe in 2025 (lost 10K cards-on-file).
- PADI AWARE — merged conservation non-profit. Has its own foundation entity, separate legal/MSA. Apps: Dive Against Debris, Adopt The Blue.
- 2023: PADI App consolidation — first attempt to unify mobile (Club + log + certs). Three apps remain (Main, Adventures, Training).
- ScubaDiving.com — legacy content acquisition. Editorial + SEO depth. Drupal site, separately managed.
Why this matters for the team: when a stakeholder says "we already have that" — they're often right, but it's in the system PADI inherited from an acquisition. Don't assume an existing capability means it's accessible, modern, or integrated. Ask which acquisition it came from.
Where revenue is leaking today
Top of funnel
20M+ visitors → poor conversion. Sign-up wall, unclear pricing, broken DSL, invisible to AI search. Each 1% conversion improvement is significant.
Cross-sell gaps
OW diver to AOW conversion is ~20%. Cert to Club is even lower. Each lifecycle handoff loses divers.
Operator friction
SSI's tooling is winning operators. 21% of members say SSI is better. Every shop that switches takes their student pipeline with them.
Today: fragmented constellation
📍 padi.com
Drupal 11 / Acquia · Twig · Marketing & content backbone
🛍️ store.padi.com
CommerceTools · Vue.js · B2C merch + eLearning purchases
🏆 club.padi.com
Drupal · Vue.js · Member benefits + subscription
🏫 pro.padi.com
Drupal · SMP · OLPC · Vue.js · Pro tools + dive shop ops
📚 learning.padi.com
DominKnow LMS · Vue.js · eLearning + certifications
📰 blog.padi.com
WordPress · 3,400+ articles · Editorial + SEO
📰 pros-blog
WordPress · Pro-facing editorial content
🌊 padi.com/aware
Conservation arm · Adopt The Blue, Dive Against Debris
scubadiving.com
Drupal · Acquired media property · Editorial
📱 PADI Main App
Native iOS + Kotlin · MyPADI utility · eCard
📱 Adventures + Training
Separate native apps · Being unified Q1 2027
🌏 Regional sites: padi.co.jp · padi.co.kr · padi.co.cn · padi.com.tw · others
Different histories, content, performance. Some on Drupal Domain Access, others on separate Acquia instances. Japan + China require special handling.
🔐 account.padi.com (AWS Cognito) — Identity layer
The only thing nominally shared across all properties. Cross-platform session continuity is what Sprint 0 must validate.
Behind the scenes: enterprise systems
As-Is enterprise systems live today
- Salesforce Sales Cloud — CRM for partners + consumers
- Salesforce Marketing Cloud (SFMC) — email, journeys, segments
- CommerceTools — B2C catalog, cart, checkout
- BirdDog — B2B commerce (separate from CT)
- M2 / Macola / Oracle 9i — Legacy ERP (Macola Americas, Oracle 9i Japan)
- Stripe — 4 regional accounts (Americas, Canada, EMEA, APAC). No global wallet.
- DominKnow — LMS / SCORM player for eLearning
- Cloudinary — current DAM (limited B2B2C support)
- AWS Athena Data Lake — analytical, not real-time
To-Be enterprise systems planned
- NetSuite — replaces Macola + Oracle 9i. Go-live Jan/Feb 2027 (post-year-close).
- CommerceTools (B2B+B2C) — BirdDog retired. Single commerce platform. 2026.
- Salesforce Data Cloud (CDP) — single 360° profile. Phase 1 foundations 2026, activation Q1 2027.
- Snowflake DWH — replaces Athena. Modern analytics + activation. 2026.
- Acquia DAM — replaces Cloudinary. B2B2C-friendly. 2026.
- Salesforce Experience Cloud — instructor portal modernisation.
⚠️ Critical rule: As-Is vs To-Be separation
Many systems referenced across PADI documentation are future-state. Don't assume a To-Be system is live unless explicitly confirmed. NetSuite isn't live. CDP isn't live. Acquia DAM isn't live. When designing integrations, model against what's there today — and architect for what's planned.
Swimlane 1 · Start Diving — Potential diver to first certification
Swimlane 2 · Keep Diving — Certified diver returns
Swimlane 3 · Teach Diving — Dive shop runs a course
How to read these swimlanes
- Each swimlane = a journey. Read horizontally (a row) to see what one actor does end-to-end.
- Each column = a stage. Read vertically to see what's happening at one moment from all sides.
- Red cells = today's friction. They're the customer pain points your team is solving.
- Green cells = future state. Each maps to a confirmed DO epic for 2026 or 2027.
- Hatched cells = no interaction. The actor doesn't appear at this stage today.
1 · Platform & Experience Architecture
padi.com/* + integrated PADI App. Subdomains consolidated under a single experience architecture.2 · Customer Journey & Conversion
3 · Technology & Data Infrastructure
4 · Marketing & Personalisation
The problem in one picture
TODAY · Fragmented
2026/27 · Unified
Property-by-property consolidation plan
padi.compadi.com · Decoupled Next.js, new IA + design systemstore.padi.compadi.com/store · CT backend unchanged. 301 redirects.Q1 2027 FE
club.padi.compadi.com/club · Decoupled Next.js. MyPADI surface.Q1 2027 FE
pro.padi.compadi.com/pro · Operator Dashboard MVP. SMP integration.Q1 2027 FE
learning.padi.comlearning.padi.com kept. APIs feed MyPADI on padi.com.blog.padi.compadi.com/blog · 3,400+ articles migrated to Drupal.pros-blog.padi.compadi.com/pros-blog · Migrated to Drupal alongside main blog.What "consolidation" actually means technically
Phase 1 (Nov 2026): Cloudflare URL rerouting
What changes: URLs like store.padi.com/products/... become padi.com/store/products/.... Cloudflare rewrites at the edge. 301 redirects preserve SEO equity.
What doesn't change: The backend serving padi.com/store is still CommerceTools. Same Vue.js frontend. Same APIs. Just a different URL.
Why this works for the launch: low-risk URL consolidation lets MyPADI feel unified without rebuilding all FE simultaneously. Buys the team Q1 2027 to revamp store/club/pro frontends.
Phase 2 (Q1 2027): Frontend rewrites
What changes: The Vue.js frontends for store, club, and pro are rewritten in Next.js using the unified design system. Now they truly look and feel like part of one product.
What doesn't change: Backends still independent (CT for store, Drupal for club/pro). Just the visual + interactive layer is unified.
Why phased: rewriting four frontends + the core padi.com simultaneously in one launch is high risk. Phasing isolates risk, lets Nov 2026 ship on time, and lets Q1 2027 deliver the visual unification once foundations are stable.
The five things that must be true for consolidation to succeed
- AWS Cognito session must be stable across all properties. Sprint 0 critical. If a user logs in on padi.com and the session breaks at padi.com/store, every other consolidation gain is lost.
- 301 redirect architecture must be airtight. Every URL on every consolidated subdomain mapped to its target. Zero broken chains. Validated via crawl tools 6 weeks before launch. Backlink equity preserved.
- SEO structured data must be in place at launch. If we consolidate domains and don't ship FAQ/Course/Experience schema simultaneously, we lose authority without gaining AEO visibility — the worst possible outcome.
- Cloudflare rules must be deterministic. No regex magic that breaks under edge cases. Every consolidated URL must behave identically across geographies and CDNs.
- Pre-launch crawl + post-launch monitoring. Screaming Frog crawl pre-launch. Search Console + Ahrefs monitoring post-launch. First two weeks are the danger zone — catch ranking drops within days, not months.
What we are NOT consolidating
- Backend systems. CT stays. Club Drupal stays. LMS stays. We're consolidating presentation + URLs, not backends.
- Identity provider. Cognito stays. We're not migrating identity in this programme — we're validating it works cross-platform.
- Translation infrastructure. Crowdin stays. The custom Drupal module gets replaced with the contributed module — that's a refactor, not a consolidation.
- scubadiving.com. Kept as a separate property — its SEO authority is too valuable to risk in a consolidation.
- B2B storefronts (b2bamericas, b2bemea, b2basia). Out of scope. Modernise after NetSuite go-live (2027).
Programme phasing
Foundation phase
Where we are now. Discovery workshops complete. IA strategy delivered. Feature prioritization done (May 2026). Sizing in progress. Sprint 0 starts mid-May with: Cognito cross-platform validation, environments setup, design system foundations, non-functional boilerplate. Critical decisions still pending: blog migration approach, Japan scoping, B2B boundary confirmation, experience taxonomy ownership.
Web modernisation phase
Design sprints (lo-fi → hi-fi, journey by journey). 11 development sprints + hardening. Deliverables for Nov 2026 launch: decoupled Next.js padi.com, new IA + design system, MyPADI dashboard, unified header/SSO, Cloudflare rerouting for store/club/pro/blog, AEO structured data, SEO redirect architecture, accessibility remediation, content migration, marketer experience (Drupal Canvas). DEMA event early November is the hard external deadline.
Mobile unification phase
Mobile discovery + build kicks off in September alongside web hardening. 3 apps (Main + Adventures + Training) merged into 1 React Native app. MyPADI surface inside the app. Smart device sync (Garmin, Apple Watch Ultra, Shearwater). Offline dive log reliability fix. Go-live Q1 2027 — coordinated with NetSuite go-live and post-DEMA stability window.
Scale & optimise phase
NetSuite ERP go-live (Jan/Feb 2027 post-year-close). Store/Club/Pro full frontend revamp aligned to design system. CDP activation (Salesforce Data Cloud). B2B EMEA + APAC store modernisation tied to regional NetSuite roll-outs. Japan localisation (post-scoping). Family account flows (post unique-ID fix). UGC + community features. WhatsApp deep-link cart (if strategy resolves).
Workstream parallelism
Important to understand: this isn't a single waterfall. Multiple workstreams run in parallel. Your team's web modernisation work happens alongside (and depends on outputs from) these other streams:
- Salesforce modernisation — Sales Cloud + Marketing Cloud + Experience Cloud audit + blueprinting. Phase 1 = stabilisation. Q1 2027 = re-engineering. Affects MyPADI preferences integration.
- Data Cloud / CDP — Salesforce Data Cloud baseline in 2026. Connect Snowflake, Salesforce, M2/LMS. Phase 2 (Q1 2027) = activation. Affects personalisation layers 3 + 4.
- Snowflake DWH — Replaces AWS Athena. Snowflake schemas + identity resolution foundation. Affects analytics + multi-touch attribution.
- Acquia DAM — Replaces Cloudinary. B2B2C-friendly. 2026 implementation. Affects content delivery on padi.com.
- NetSuite ERP — PADI's internal initiative. Replaces Macola + Oracle 9i. Jan/Feb 2027. Affects store + B2B frontends.
- PE Pod (KMS scope, separate SOW) — Frontend support for learning/store/club/pro + on-call mobile. Continuous from Apr 2026. Stabilises legacy while modernisation builds.
1 · Personalization
2 · Localization
3 · Unification
padi.com/*. Phase 1: Cloudflare URL rerouting (Nov 2026). Phase 2: Vue → Next.js frontend rewrites (Q1 2027). Mobile: 3 apps → 1 React Native (Q1 2027).4 · Segmentation
The dependency chain
Read this top to bottom — it's the order in which capabilities unlock:
Unification — domain consolidation + single Cognito session
Without this, no logged-in journey works across properties. Sprint 0 must validate cross-platform Cognito stability.
Identity resolution — single source of truth per diver
Email-as-unique-ID is broken (family accounts). Member ID + Cognito ID + CRM ID need to be reconciled in Snowflake before CDP can do its job.
Localization plumbing — translatable strings flow cleanly
Crowdin contrib module migration removes the maintenance tax. JIPT context closes the translator quality gap. Both happen alongside the padi.com rebuild.
Segmentation foundations — Snowflake schemas + consent
Identity stitching + TrustArc consent + DLO/DMO mappings in Salesforce Data Cloud. This is the data backbone segments are built on.
Personalization activation — rules first, AI later
Layer 1 (geo/cookie) + Layer 2 (logged-in profile) ship in 2026 without CDP. Layer 3 (CDP-driven personas) and Layer 4 (AI/LLM real-time) follow in Q1 2027 once data backbone is live.
Personalization — the "black box" that became a 4-layer roadmap
- Kevin Braun (Day 1): "I don't think we have that many actual paths… we don't need to build everything."
- Kristina Bailey (Day 2): "I do think we're going to want to get into things that are going to be a best in class dynamic, personalised experience. It's not going to be day one."
- Vivek Radhakrishnan (Personalization breakout): "I think we need to probably do a session just on the life cycle… personalisation is mapped to the life cycle. Breaking down that would be really helpful to build the personalisation logic."
The 4-layer framework
Each layer has clear data inputs, clear delivery surfaces, and a clear delivery window. This is the framework Vivek committed to producing as an artifact by end of workshop week — it kills the recurring "what is personalisation" debate by making the spectrum explicit.
2026 DO
Behavioural / anonymous
Geo-IP, browser cookies, session behaviour, entry path. No data stored, no CDP needed. Example: user lands from "reef diving Indonesia" → homepage surfaces Indonesia experiences. Falls back to default for VPN/masked traffic.
2026 DO
Data-backed / profile (logged-in)
Certification history (LMS), purchase history (CT), SFMC segments, MyPADI profile data. No new infrastructure — PADI already has this data. Example: logged-in OW diver → surface AOW + nitrox pathways. Uses what exists today.
Q1–Q2 2027
Persona + journey path (CDP-driven)
360° member profile. Dynamic personas. Intent matching. Requires CDP foundations (Salesforce Data Cloud) — the data model that tracks dives, not just certifications. Today PADI looks like divers churn when they're not certifying that year.
2027+
AI / LLM + real-time
Dynamic persona mutation. Real-time intent signals (search queries, browse behaviour). LLM-powered next-best-action. Requires 6–12 months of enriched data from Layer 3 to be meaningful.
What's already in scope vs. what's deferred
✅ Confirmed for 2026
- Geo-IP / cookie-based homepage personalisation (Layer 1)
- Logged-in MyPADI dashboard with cert + order data (Layer 2)
- Post-cert "what's next" pathway tiles (rule-based, Layer 2)
- Cert-to-experience logic on course pages (Layer 2)
- CDP data model foundations (T14) — Sprint 0 schema decision, costs almost nothing now, future-proofs Layer 3+4
⏸ Deferred to Q1 2027+
- Dynamic persona mutation
- Real-time intent signal personalisation
- Cross-BU activation (Club ↔ Learning recommendations)
- Predictive churn modelling
- Multi-touch attribution-based personalisation
- AI/LLM-driven next-best-action
How the breakout discussion actually went (case study in handling ambiguous client requests)
The pattern that worked here is reusable. When a stakeholder topic is ambiguous (everyone uses the word, nobody agrees what it means), follow this sequence:
Surface the spectrum
"Personalisation" can mean Geo-IP cookies or full CDP AI. Make the spectrum explicit. Ask: "when you say personalisation, which end of this spectrum are you thinking of?"
Separate aspiration from constraint
Kevin aspired to dynamic personalisation. Kristina confirmed the aspiration. Vivek introduced the constraint (you need lifecycle data first). All three were right — at different time horizons.
Anchor to what exists
"PADI already has cert history, purchase history, SFMC segments. We can personalise with those today without a CDP." This gave the client something tangible to agree to for 2026.
Future-proof the architecture without over-building
T14 (CDP data model foundations) is a Sprint 0 schema decision — costs almost nothing in 2026, but means Layer 3/4 don't require a rearchitecture. This is the technical "threading the needle."
Produce an artifact to close the discussion
Vivek committed to a personalisation framework document by end of week. Written artefacts kill ambiguity. Without one, the same conversation recurs every sprint.
Risks to watch
⚠ Risk 1: Layer creep into 2026
Stakeholders will keep pushing Layer 3 features into 2026 scope. ("If we have purchase history, why can't we predict churn?") Hold the line: Layer 3 needs CDP to be live, and CDP isn't live until Q1 2027.
⚠ Risk 2: Throwaway work on a rule-based engine
If the team builds a rule-based personalisation engine that gets torn out when CDP arrives, that's pure waste. Rules in 2026 must be in surface code (component logic), not in a separate engine. The CDP comes with its own activation layer.
⚠ Risk 3: Conflating personalisation with content variants
Showing different content to logged-in vs. logged-out users isn't personalisation — it's basic conditional logic. Make sure stakeholders understand the difference, or every PR with an `if (user.loggedIn)` check will get tagged "personalised."
Localization — Crowdin stays. Custom module → contrib. The real fix is context.
- Translation Systems doc: Crowdin Enterprise for padi.com via custom Drupal module built 2022–2023 (before contributed module existed).
- Content Governance & Localisation Discovery: 3-decision proposal — (1) Crowdin remains, (2) Drupal Native Translate as a manual path, (3) close the context gap in Crowdin.
- Translation & Localization Integration Assessment: contributed Crowdin module assessed and "performs reasonably well." Two decisions deferred to planning — custom vs. contrib module, and how to pass context.
- Feature Prioritisation Workshop: Japan/China scoping deferred to separate session week of May 11 (Ralph, Charles, Aref, Ashley, Kevin, Kristina).
The Crowdin Enterprise translation setup
Crowdin Enterprise — for padi.com
Used by: padi.com, Drupal content, global marketing, product teams. Owned by the Worldwide team and managed centrally. Custom Drupal integration module built in 2022–2023 (before contrib existed).
Supports: machine translation + AI + human + human review for sensitive/legal content. Routing rules inside Crowdin, not Drupal. Translators get real-time notifications.
How the Crowdin Enterprise workflow operates today
Author selects "Send for Translation" in Drupal
Content marked as needing translation triggers the workflow.
Drupal pushes content to Crowdin as XML
Job lands in a specific Crowdin group based on content type, system routing, budget owner, sensitivity level.
Translators receive immediate notification
Workflow varies by content sensitivity: machine + optional review for general copy, human-only for legal, human + review for marketing.
Translation completes (MT in seconds, human depends on availability)
Status closes when file hits 100% translated.
Crowdin syncs back to Drupal mapped to job ID
Content automatically reinserts into the page structure. Translators don't see context — that's the gap.
Three localisation decisions for the modernisation
Crowdin remains the translation service
No migration to a new vendor. No retraining. Existing Crowdin Enterprise setup is retained as-is. This was confirmed in the Content Governance discovery.
Drupal Native Translate as a manual path
Not every translation needs a full Crowdin round-trip. For typos, button labels, minor tweaks — Drupal's native Translate gives Translators and Content Managers an in-platform fast path. Reserved for the Content Manager role.
Close the context gap in Crowdin (the real fix)
This is the decision that moves translator experience forward. Today translators see strings without context — they don't see what the page looks like, what's around the string, what the CTA does. The Translation Systems doc proposes evaluating mechanisms during planning to give translators real context without over-engineering the integration. JIPT (In-Context Translation) is a strong candidate.
Custom Drupal module → contributed module migration
Editorial roles + content lifecycle
From the Content Governance discovery, three editorial roles were proposed. Every sensitive transition (publish, archive, delete) is reserved for the Content Manager:
- Content Editor — author. Creates/edits drafts. Moves to Translate state.
- Translator — owns linguistic quality. Adds/edits translations. Moves to Review state.
- Content Manager — accountable publisher. Reviews, sends back to draft, publishes, archives, restores, deletes.
State machine: Draft → Translate → Review → Published → Archived. Archived content lives 30 days then auto-deletes (recovery buffer, not compliance retention — extend per content type during planning if needed).
Regional sites — Japan, Korea, Taiwan, China
~6–9 regional sites: padi.co.jp, padi.co.kr, padi.co.cn, padi.com.tw, others. All sharing padi.com's Drupal instance via the Domain Access module — except China runs on a separate Acquia equivalent.
Decision (from Feature Prioritisation): Big-bang rollout — every regional site rebuilt in Next.js with the new design system and the new IA, simultaneously, in Nov 2026. A/B testing capability built into the platform for ongoing iteration after launch.
Why not "stress-test in Japan only first": creates throwaway design + IA work. Two IA variants for Nov 2026 + the follow-up still requires content reorganisation. The stress-test instinct gets a stronger answer — continuous validation as a platform capability, not a one-shot pre-launch test.
Open scoping: Japan scoping meeting week of May 11 (Ralph, Charles, Aref, Ashley, Kevin, Kristina). Japan has separate payment flows, WeChat-equivalent needs, local data stores not connected to PADI's main systems, local developer preferences. Much more complex than "just translate."
Risks to watch
⚠ Risk 1: Migration scope underestimation
Migrating from custom to contrib module is "non-trivial" — affects thousands of pages and workflows. Engineering time + regression testing must be sized properly during planning.
⚠ Risk 2: JIPT scope clarity
JIPT override scope needs to be sized — bringing the In-Context translation integration onto the contrib base, including PADI's noted corrections. This affects effort sizing for the Nov 2026 window.
Unification — hub-and-spoke around padi.com, phased over 2 launches
- Executive Onboarding (Internal): "Unified, hub-and-spoke ecosystem centered around a consolidated PADI.com and integrated PADI App."
- Web/Mobile Discovery (Oct 28): Customer Journey Modernization — current vs future state across 9 dimensions.
- Digital Experience Platform Discovery Workshop: Experience Layer recommendations property-by-property.
- Unified App Feature Alignment Proposal v3: 8 KEEP + 17 ENHANCE + 2 DROP + 34 NEW features for the unified app.
- Feature Prioritisation Workshop: Phased decision — Cloudflare rerouting Nov 2026, frontend rewrites Q1 2027.
What "unification" actually means
From the executive onboarding doc, the future state is:
- Hub-and-spoke ecosystem centered on padi.com. All journeys (Learn, Dive, Teach) start there.
- Single sign-on (SSO) linking web and app — one session, one identity, no re-logins.
- Single-source content management on Drupal (DXP) for storytelling, education, SEO content. CommerceTools reserved for transactional only.
- Unified PADI Mobile Super App — three apps (Main + Adventures + Training) merged into one React Native app.
- Single design system across web and mobile, shared component library.
- Cross-device attribution via SSO + CDP integration.
Property-by-property unification map
The 2-phase technical approach
Phase 1 — Nov 2026: Cloudflare URL rerouting
What changes: URLs like store.padi.com/products/... become padi.com/store/products/.... Cloudflare rewrites at the edge. 301 redirects preserve SEO equity.
What doesn't change: backend serving padi.com/store is still CommerceTools. Same Vue.js frontend. Same APIs. Just a different URL.
Why this works for the launch: low-risk URL consolidation lets MyPADI feel unified without rebuilding all FE simultaneously.
Phase 2 — Q1 2027: Frontend rewrites
What changes: Vue.js frontends for store, club, pro rewritten in Next.js using the unified design system. Now properties truly look + feel like one product.
What doesn't change: backends still independent (CT for store, Drupal for club/pro). Just the visual + interactive layer is unified.
Why phased: rewriting four frontends + the core padi.com simultaneously in one launch is high risk. Phasing isolates risk, lets Nov 2026 ship on time.
Mobile unification — 3 apps → 1 React Native app
From the Unified App Feature Alignment Proposal (v3), the unified app is a material step up — not a relabelling of today's app.
Feature counts across 8 functional areas: 8 KEEP · 17 ENHANCE · 2 DROP · 34 NEW.
Five non-negotiable design principles:
- One identity, one wallet. Single AWS Cognito session across padi.com + MyPADI + app. Certs become first-class identity, not documents.
- In-app commerce where platform economics allow, web hand-off where they don't. Club + eCards + learning bundles in-app; large physical merch links to store.padi.com.
- Verify once, dive anywhere. Diver-side QR + shop-side QR + wallet pass are three halves of the same verification architecture.
- Don't carry the sins of three codebases. Feature parity at launch is harder than feature union. If it can't migrate cleanly, drop + rebuild, not lift + shift.
- Push-first, messaging by exception. App-native push + in-app inbox are near-zero marginal cost. Cuts transactional SMS/email volume materially.
Five things that must be true for unification to succeed
- AWS Cognito session must be stable across all properties. Sprint 0 critical. If a user logs in on padi.com and the session breaks at padi.com/store, every other consolidation gain is lost.
- 301 redirect architecture must be airtight. Every URL on every consolidated subdomain mapped to its target. Zero broken chains. Validated 6 weeks pre-launch. Backlink equity preserved.
- SEO structured data must be in place at launch. If we consolidate domains and don't ship FAQ/Course/Experience schema simultaneously, we lose authority without gaining AEO visibility.
- Cloudflare rules must be deterministic. No regex magic that breaks under edge cases. Every consolidated URL behaves identically across geographies and CDNs.
- Pre-launch crawl + post-launch monitoring. Screaming Frog pre-launch. Search Console + Ahrefs monitoring post-launch. First two weeks are the danger zone.
What we are NOT unifying
- Backend systems. CT stays. Club Drupal stays. LMS stays. We're consolidating presentation + URLs, not backends.
- Identity provider. Cognito stays. We're validating it works cross-platform, not migrating it.
- Translation infrastructure. Crowdin stays (custom module → contrib).
- scubadiving.com. Kept as separate property — SEO authority too valuable to risk in consolidation.
- B2B storefronts. Out of scope. Modernise after NetSuite go-live (Q1 2027+).
Segmentation — from manual filters to AI-powered with Salesforce Data Cloud
- CDP Discovery Workshop (Oct 9): Limited Personalization and Segmentation — manual filters, generic campaigns, SFMC can only target known contacts, no anonymous tracking, no predictive targeting.
- Executive Onboarding (Internal): Targeting today is "rule-based and limited to demographic or course-level data." Future: AI-driven segmentation within Salesforce Data Cloud.
- Salesforce Requirements doc: 90+ renewal segments across 13 languages — content creation bottleneck on small creative team.
- Subscription Discovery (Oct 10): 4 isolated Stripe accounts, fragmented systems, no global wallet for portability across regions.
Today's segmentation reality
What's broken (current state)
- Manual filters in SFMC — certification level, region, email activity
- 90+ renewal segments × 13 languages, all maintained by hand
- Segments don't account for cross-channel behaviour (email + web + app)
- SFMC can only target known contacts — no anonymous tracking
- No predictive scoring (churn, upsell propensity, LTV)
- No exclusion logic across journeys → one user got 27 emails in 60 days
- Translations + asset updates take 1+ week per email localization
- Last-click attribution misses multi-touch engagement
What's planned (future state)
- Unified 360° profile in Salesforce Data Cloud
- Identity resolution: deterministic (CRM Contact ID, Email) + probabilistic (Name+Email+Phone+Membership ID)
- Dynamic audiences activated to MC, Sales Cloud, Service Cloud, web/app
- Calculated insights: CLV, RFM, Engagement Index, Churn Predictor
- Multi-touch attribution models (linear, U-shape)
- Self-serve segmentation for marketers — no engineering dependency
- Frequency capping + suppression rules across journeys
- Regional data spaces (EU, APAC, US) + TrustArc consent management
The 3-phase CDP roadmap
2026
Foundational
Data ingestion + 360° profile creation. Identity resolution across platforms. Unified email segmentation + suppression logic. Reactivation journeys for inactive divers. Initial CDP ↔ Salesforce Marketing Cloud integration.
Q1 2027
Personalization & Activation
Post-certification + cross-sell recommendations. Predictive scoring for Club upgrade and AOW conversion offers. Multi-channel orchestration (email + web + app). Multi-touch attribution dashboards.
2027+
Advanced Optimization
Real-time personalization across web + app. Machine learning-based journey adaptation. Cross-BU personalization (Club ↔ Learning). Churn modelling and proactive retention campaigns.
What gets segmented (data sources feeding the CDP)
B2C data sources (direct-to-consumer)
- Web & App Behaviour: Drupal CMS, GA4, GTM, VWO, TrustArc — browsing, search, consent, A/B test events
- Learning: PADI LMS — course enrollment, completion, certifications
- Commerce: CommerceTools + Stripe — orders, renewals, discounts
- Membership/Club: PADI Club, Salesforce Loyalty — subscriptions, points, redemptions
- Marketing Engagement: SFMC, Meta, Google Ads — email + campaign + ad performance
- Mobile: PADI App, Adventures — sessions, bookings, location
B2B2C data sources (partner-mediated)
- Partner CRM: Salesforce Partner Module — dive shop profiles, instructor lists, partnership tiers
- Membership Mgmt: Macola (legacy), Oracle 9i (Japan)
- Partner Portals: Salesforce Experience Cloud, Instructor Portal — course submissions, leads
- Learning Attribution: LMS / Instructor feeds — which instructor certified which student
- Marketing Enablement: SFMC B2B Journeys, Asana — co-marketing, incentive tracking
- Regional Operations: Japan, EMEA, APAC HQ systems — localization, legal, currency
Calculated insights the CDP will produce
📊 CLV / RFM
Customer lifetime value + Recency/Frequency/Monetary scoring for value-based segmentation. Used to prioritise outreach and design tier-specific offers.
📈 Engagement Index
Composite score derived from email, web, mobile, and service activity. Distinguishes active divers from lapsed at the right granularity.
⚠ Churn Predictor
Leverages declining engagement signals + lapsed certifications. Today PADI looks like divers churn when they're not certifying that year — churn predictor disambiguates real churn from cyclical activity.
🎯 Attribution
Linear + U-shape models linking Marketing Cloud engagement to opportunity conversion. Replaces last-click attribution.
Activation destinations
Dynamic audiences from the CDP get activated to:
- Marketing Cloud → Journey Builder audiences (email + push + SMS journeys)
- Sales Cloud → Campaign Members, High_Value flags (sales-led outreach)
- Service Cloud → proactive outreach for at-risk customers
- Web/App → personalization via Data Cloud Web SDK + VWO (this is what activates Layer 3 of the personalization framework)
Risks to watch
⚠ Risk 1: Snowflake is a prerequisite
Per the proposal: "Snowflake Implementation by AIT is a prerequisite for Data Cloud/CDP implementation to ensure we have clean data in the CDP." If Snowflake slips, CDP slips. Track this dependency explicitly with AIT data team.
⚠ Risk 2: Identity resolution depends on the unique-ID fix
Email is the only unique identifier today. Probabilistic matching (Name+Email+Phone+Membership ID) needs the unique member ID work to be complete first. The 2026 unique ID fix unblocks segmentation as much as it unblocks family accounts.
⚠ Risk 3: Consent & compliance gating
TrustArc consent integration is required for all segmentation activation. Regional data spaces (EU, APAC, US) must be configured before any cross-region segments are activated. GDPR/CCPA retention and erasure flows must be operational at activation.
⚠ Risk 4: Marketing team capacity
"Self-serve segmentation by marketing teams without technical dependency" is a future-state goal — it requires marketing operators to learn the new tooling. Without enablement + governance + templates, marketers will keep filing tickets and the segmentation work doesn't scale. Build training + governance into Phase 1, not Phase 2.
Cross-pillar dependency matrix
How they connect (worked examples)
What if a logged-in OW diver in Japan visits padi.com?
Unification ensures their MyPADI session persists across padi.com → padi.com/club → padi.com/store (one Cognito session). Localization serves Japanese-translated content via Crowdin. Personalization Layer 2 recognises they have an OW certification and surfaces AOW + nitrox pathways. Segmentation activates them to the "OW divers in Japan, 6 months post-cert" audience for a Marketing Cloud journey. None of these work in isolation — and removing any one of them collapses the experience.
What if you launch unification without identity resolution?
The user lands on padi.com, sees a personalised hero (Layer 1, geo-based), logs in — and discovers their cert history is incomplete because the LMS-to-CRM record matching never happened. Personalization Layer 2 fails. The user concludes "PADI doesn't know who I am." The unification gain is wiped out by the data gap.
What if you ship segmentation without consent infrastructure?
Marketing creates a "lapsed AOW divers in EU" audience and activates a re-engagement journey. TrustArc isn't fully integrated. A subset of those users have unsubscribed in the new MyPADI preferences UI but the change hasn't synced to SFMC. They get the email anyway. GDPR complaint. Brand damage. Sender reputation hit. The segment performed perfectly — the consent layer didn't.
What if you delay localization plumbing to 2027?
Every regional site (Japan, Korea, Taiwan, China) launches with Nov 2026 Big Bang. Translators are still on the custom module. Every Drupal core update breaks workflows. Translation quality stays poor because JIPT is delayed. Regional teams revert to manual workarounds. The unification gain is undermined by the localization gap. The 2026 launch can't ship without the localization plumbing being ready.
Programme-level focus areas
Your seven focus areas
1 · Sprint 0 gates — don't skip them
Cognito cross-platform validation, AEO redirect mapping, LMS webhook capability, CommerceTools API confirmation, Drupal Canvas marketer test. If any of these don't validate cleanly in Sprint 0, every downstream sprint is at risk. Resist the temptation to start "doing real work" before Sprint 0 closes. The whole programme depends on these foundations being solid.
2 · Decision velocity with PADI stakeholders
Kevin's decision speed is the #1 documented programme risk. Story approval bottlenecks will compound into sprint slippage. Establish sub-committees for story approval. Use Kristina as escalation when Kevin blocks. Set a 48-hour SLA on decisions and escalate anything older. Diana (AIT) is your partner in this — she has weekly 1:1s with Kristina.
3 · Design process — lo-fi before hi-fi, always
Kevin agrees verbally and reacts differently to screens. Gillian and Dheeraj jumped to hi-fi too fast. Mandate lo-fi narrative walkthroughs before any pixel-perfect design. One journey at a time. Working sessions, not async reviews. Component reusability is the litmus test for every design decision.
4 · Pre-launch SEO + redirect rigour
The single highest-risk activity at launch. A broken redirect chain wipes domain authority. Make your QA engineer the redirect owner — not a side task. Crawl 6 weeks pre-launch. Validate backlink equity. Structured data validated via Google Rich Results. Rollback plan tested in staging. PADI SEO team (Nathan Roach) signs off in writing.
5 · Q3 2026 resourcing reality
Membership renewal season (PADI's biggest revenue period) + DEMA prep + summer holidays compress availability for the most critical UAT window. Build the Q3 stakeholder availability gap into the plan now. Identify backup approvers for every key PADI role. Don't schedule UAT critical path through August. PADI side will tell you they're "fine" — assume they're not.
6 · Scope discipline — protect the 2026 boundary
The biggest risk is scope creep disguised as "while we're at it." Family onboarding. Japan localisation. UGC. Pro Club/Store full revamp. CDP-driven personalisation. WhatsApp cart. Each is a worthy ask. Each is parking lot for 2026. Your job is to keep saying "yes, and that's 2027" without making PADI feel rejected. Use the As-Is/To-Be table as your evidence.
7 · The dependency map between modernisation and PE Pod
Two SOWs are running concurrently. Your team is building the future (this programme); the PE Pod is keeping the present alive (Learning/Store/Club/Pro frontends + mobile on-call). Coordinate weekly with PE Pod PM to avoid duplicate work, conflicting deploys, and missed handoffs. The PE Pod's stability work directly affects your team's ability to integrate cleanly.
Three questions to ask yourself every Friday
1. What did we learn about a stakeholder this week?
This programme is more about people than technology. Track what you learn about Kevin's decision style, Theresa's pragmatism, Kristina's strategic priorities, the AIT team's working preferences. These insights compound.
2. What technical decision did we make that we'll regret?
Every sprint, the team makes architectural decisions under time pressure. Some will be wrong in retrospect. Surface them now while they're cheap to fix — not in October when they're expensive.
3. What's the one thing that, if it slipped, kills the launch?
Force yourself to name it. Cognito? Redirect architecture? Kevin's design approval? Whatever it is, that's where your attention belongs Monday morning. The other 80 things wait their turn.
Four-pillars focus areas
1 · Sprint 0 must validate the foundations of all four pillars
Personalization: agree the 4-layer framework + commit to the artifact. Localization: evaluate contributed module + JIPT migration plan. Unification: validate Cognito cross-platform session. Segmentation: Snowflake schema decision (T14) + identity resolution rules. Don't move on until each has a green light.
2 · Identity resolution is the linchpin between segmentation and personalization
You can't segment what you can't identify. You can't personalise to a profile that's split across 4 systems. The unique member ID work in 2026 is what unlocks both Layer 2 personalization and Phase 1 segmentation. Don't let it slip — it's the most boring and most consequential workstream.
3 · Crowdin module migration must be sized properly
The Translation Systems doc explicitly calls this "non-trivial — affects thousands of pages and workflows." Engineering time + regression testing must be sized during planning, not assumed. JIPT override scope is the open variable.
4 · Hold the line on personalization Layer 3 in 2026
Stakeholders will keep pushing CDP-dependent features into 2026 scope. Have the 4-layer artifact handy. Layer 3 needs CDP. CDP isn't live until Q1 2027. The conversation ends when you can point to a written framework — without one, it recurs every sprint.
5 · TrustArc + consent is on the critical path for segmentation
Easy to deprioritise because it's "boring infrastructure." Don't. Every segment activation in Phase 1 requires consent infrastructure to be operational. Regional data spaces (EU, APAC, US) need to be configured before any cross-region audience is activated. Surface this with the AIT data team early.
6 · Japan + China are scope wildcards, not just localization
They span all four pillars: separate payment flows (segmentation/activation), separate data stores (segmentation/personalization), local content variants (localization), separate Acquia instance for China (unification). Japan scoping meeting (week of May 11) is critical — pin them down before committing to anything.
7 · Mobile parity bar is harder than mobile feature union
From the Unified App Feature Alignment Proposal: "feature parity at launch is a harder bar than feature union." Three current apps + 34 new features = a lot of surface area. Sequence the feature alignment session early — KEEP/ENHANCE/DROP/NEW decisions across 8 functional areas need to be locked before mobile design starts.
8 · Snowflake is the silent prerequisite
"Snowflake Implementation by AIT is a prerequisite for Data Cloud/CDP implementation." If Snowflake slips, CDP slips, Layer 3 slips, Phase 2 segmentation slips, Layer 4 personalization slips. The chain is long and the dependency is owned by AIT, not Axelerant. Track this in your weekly governance — it's the single biggest external risk to your Q1 2027 commitments.
Three questions to ask your team every sprint
1. Are we accidentally building Layer 3?
Watch for personalization PRs that introduce a "rules engine" or assume CDP is live. Layer 1+2 should ship as component-level conditional logic, not a separate engine.
2. Are we underestimating the localization migration?
Custom → contrib module migration affects thousands of pages. Has anyone actually run the regression test plan against a representative content sample yet?
3. Have we validated identity resolution end-to-end?
A diver logs in on web → certs appear correctly in MyPADI (Layer 2 works). They open the app → certs appear correctly there (cross-device works). They get an email → segmented correctly (CDP works). All three need to be green before we claim "done."
📍 The moment you'll know if this is working
When Sprint 0 closes, you'll have signal on all four pillars. Cognito validation = unification gate. Crowdin module evaluation = localization gate. CDP schema decision = segmentation gate. Personalization framework artifact = personalization gate. If any of these don't land cleanly in Sprint 0, the dependency chain collapses. Capture the actuals against each gate — that's the moment the programme transitions from "what we believe is true" to "what is actually true" across all four pillars at once.
The four artifacts and what each is for
📘 Knowledge Base
Use when: someone joins the programme mid-flight, you need to brief an exec in 15 minutes, or you're checking what's actually in scope vs. parked.
Don't use for: daily operational decisions. It's a reference, not a checklist.
👥 Team Onboarding Guide
Use when: onboarding the 3 BE / 3 FE / 1 QA. The Customer Pulse and Personalization tabs are the most powerful — but only if narrated, not read cold.
Don't use for: client-facing conversations. It's internal context.
🎯 Customer Pain Points
Use when: a stakeholder pushes back on scope ("why are we building this?"), or your team forgets why they're doing the work. Real verbatims from real divers carry weight.
Don't use for: formal stakeholder presentations. It's a working tool — quote from it, don't present it.
🌐 Business Concept (this doc)
Use when: you need the strategic context for a tactical decision. The swimlanes especially — they translate "user pain" into "system change" in one visual.
Don't use for: sprint-level execution. It's calibration, not direction.
Practical playbook for the next 6–8 weeks
1 · Walk the BE/FE/QA folks through the Team Onboarding Guide in their first 1:1, not as a doc dump
The temptation is to email the link and say "read this before our 1:1." Don't. Most engineers will skim it, miss the nuance, and arrive without the context you needed them to have.
Instead: open the Customer Pulse tab in your 1:1 and walk through 2–3 verbatim quotes that map to what they'll be building. For the BE engineer working on bulk code management, surface Kerrie's "hideous... millions of different lines of entries" quote. For the FE engineer working on MyPADI, surface Mariana's "verify once, dive anywhere" quote.
For the Personalization tab, narrate how the conversation evolved from "black box" to a 4-layer model. The deep-dive reads cold as theory; with your narration it becomes a case study in handling ambiguous client requests — which is a skill they'll use on every sprint.
2 · Use the swimlanes in stakeholder conversations
The swimlanes work surprisingly well when Kevin or Kristina pushes back on scope. Pointing to a red cell and saying "this is what we're solving — see how the diver re-enters their information at every shop?" anchors the conversation in evidence rather than opinion.
Specific scenarios:
- When Kevin questions why MyPADI is P0 → walk through the Keep Diving swimlane, show the 4 logins, point at "session breaks" red cells.
- When Theresa asks why operator dashboard scope is so big → walk through the Teach Diving swimlane, point at the 5-tab manual workflow.
- When Kristina asks about commercial priority → use the Start Diving swimlane to show the funnel leakage between PADI's lead generation and the dive shop's close.
Don't email these in advance. Open them live in the meeting. The evidence works better when discovered together than when sent for review.
3 · Keep the "Where You Focus" tab visible at every retro
The seven focus areas (Sprint 0 gates, decision velocity, design process, SEO/redirect rigour, Q3 resourcing, scope discipline, PE Pod dependency) are calibrated to where programmes like this typically slip. They're not prescriptive — they're warning lights.
Retro routine: at the start of each retro, scroll through the seven focus areas. Ask the team: "any of these slipping this sprint?" Honest answers surface programme-level risks while they're still cheap to fix. Without this routine, those risks only become visible in October when they're expensive.
Treat this like a flight checklist — boring, repetitive, and the reason you don't crash.
The Sprint 0 milestone — what to ping me about
📍 The moment a lot of assumptions get tested
When Sprint 0 closes, ping me with the actuals from the AWS Cognito cross-platform validation. That's the moment the programme transitions from "what we believe is true" to "what is actually true."
Specifically, share:
- Did Cognito session persist cleanly across padi.com → store → club → pro?
- How did token refresh behave at boundary windows?
- Any edge cases with mobile session handoff?
- Did PADI Engineering (Ralph, Aref) flag any architectural surprises?
If Cognito validates clean, the programme is on the rails. If it doesn't, we re-plan immediately — MyPADI, domain consolidation, and personalisation all depend on it.
Other moments worth a check-in
🎨 First design review with Kevin
The first lo-fi → hi-fi handoff with Kevin will tell you whether the design process is working. Surface what worked and what didn't — adjust the cadence before patterns calcify.
📋 First sprint demo to PADI
The first time PADI sees actual working software in their UAT board. Watch what they react to vs. what they ignore. That tells you what they actually care about vs. what they say they care about.
🚦 Pre-Q3 capacity check (mid-July)
Before membership renewal season + summer holidays compress availability. If you don't have backup approvers identified by mid-July, the August/September UAT cycle will stall.
One last thing
These artifacts are a starting point, not a destination. They'll be wrong about something — that's expected. When you find the wrong bits, update them. When you learn something new about a stakeholder or a system, add it. The artifacts that get used are the ones that get maintained. The ones that don't get updated turn into shelfware within a month.
Good luck with the kickoff. The hard part isn't the technology — you have a strong team and a clear plan. The hard part is keeping people aligned, decisions moving, and scope honest over the next 6 months. The artifacts help. The discipline of using them is what matters.