The first 90 days should produce one working player journey, evidence about its mechanism and an operating method the team can repeat.
Key Thesis
A 90-day pilot succeeds when it closes one complete loop — from player signal to recognised outcome — under real operating conditions.
Begin with a decision, not a destination
The pilot should answer one consequential question: Can we reactivate a dormant payer cohort? Can we reduce unresolved payment failures? Can we increase repeat participation in a seasonal event? A broad goal such as “launch DTC” or “build a GameHub” is not testable. Choose one cohort, one behaviour, one primary outcome and one decision the organisation will make when evidence arrives.
Six phases across 90 days
Days 1–15
Write the pilot contract
Output: A one-page pilot contract and baseline evidence pack. Document the player problem, intended mechanism, eligible cohort, primary metric, economic measure, guardrails, owner and stop conditions.
Days 16–30
Design the minimum closed loop
Output: Journey map, state model, event schema and exception paths. Remove features that don’t help close the loop; add recovery states that prevent the pilot from becoming a demo.
Days 31–45
Make ownership executable
Output: Responsibility map, launch checklist and decision thresholds. Define keep, modify, scale and stop thresholds while the team is still neutral about the result.
Days 46–60
Launch inside boundaries
Output: Controlled live journey with verified telemetry and recovery. Daily checks on identity errors, eligibility, fulfillment delays, duplicate actions and support volume.
Days 61–75
Diagnose the mechanism
Output: Mechanism review, guardrail assessment and explicit keep/modify/stop decision. Separate channel shift, timing effects, genuine reactivation and operational leakage.
Days 76–90
Standardise what deserves to survive
Output: Reusable operating package, next-scope proposal and retirement list. If the mechanism didn’t work, preserve the evidence and close the pilot cleanly.
Four decision gates
Gate 1
Ready to Build
Problem, owner, baseline and intended decision are clear
Gate 2
Ready to Launch
Identity, eligibility, state transitions, measurement and recovery tested
Journey runs without hidden manual dependency; knowledge is documented
Figure 8. The first 90 days build a repeatable learning system around one working player journey — from pilot contract to operating standard. Conceptual framework; not measured data.
What success looks like at day 90
The team can describe what changed player behaviour and what did not. The player journey has a known owner. Transaction and entitlement states can be reconciled. Evidence is strong enough to support a decision. Manual work and exceptions are visible. The next pilot can reuse part of the operating package.
Success is not a completed transformation. It is a smaller but more valuable capability: the organisation can operate one direct-player journey deliberately and improve the next one with evidence.
Reasonable Objection
Ninety days is arbitrary. The calendar is a forcing function, not a universal implementation promise. A title may need less or more time depending on integration, policy, data and team constraints. The important structure is the sequence: contract, closed loop, ownership, controlled launch, mechanism review and standardisation.
Thought leader in Direct-to-Consumer (DTC) strategy for the gaming industry and Applied AI. As Head of SEA at Aghanim, he helps gaming companies build direct player relationships — growing revenue without platform intermediaries. With over 15 years of experience in digital transformation and business analytics, and a Master's degree in Digital Transformation & Business Analytics, he actively writes and speaks about gaming DTC, LiveOps, player identity, AI-powered personalization, and how LLMs reshape game operations.http://trietphan.com
Do you like Triet Phan's articles? Follow on social!
