Customer and User Obsession Questions

90‑Day Plan — Summary (senior game developer perspective)

Days 0–14: Discovery

• Run rapid accessibility triage: collect crash/error logs, analytics (session length, drop-off), controller/input telemetry, platform-specific accessibility settings.
• Remote and in‑lab user tests with 8–12 players representing vision, hearing, motor, cognitive disabilities; tasks: launch, navigate menus, play tutorial, complete 3 levels.
• Output: ranked issue list (severity, repro rate, platform), short video clips, reproducible test cases.

Days 15–60: Prioritized engineering fixes

• Triage by severity: P0 (game‑blocking: input, unskippable sequences, no subtitles), P1 (major UX: color contrast, focus order), P2 (nice‑to‑have).
• Parallel sprints across platforms (Unity/Unreal):
  • P0 examples: remappable inputs + hold/repeat thresholds, alternative camera/control schemes, keyboard navigation for UI, subtitles + captions, adjustable audio cues.
  • P1 examples: UI scale, colorblind palettes, focus/aria roles for web/launcher, reduce required precision for actions.
• Estimate: 6 engineers (4 gameplay/UI, 1 audio, 1 platform), 8–10 engineer‑weeks for P0 across platforms; additional 8–12 engineer‑weeks for P1.

Days 61–80: QA & validation

• Create automated accessibility test harness: synthetic input replay, contrast checks, subtitle rendering tests.
• Regression suite + manual accessibility checklist run by 2 QA engineers including users with disabilities.
• Accessibility acceptance criteria for each bug (repro, fix, user validation).

Days 81–90: Documentation & community

• Publish patch notes detailing fixes, accessibility settings guide, in‑game tutorial for remapping.
• Create in‑game accessibility panel with explanations and presets.
• Community communication: developer blog + targeted outreach to affected players and advocacy groups; open beta for validation.

Resources

• Engineers: 6 FTEs (2 sprint cycles), QA: 2 FTEs (full 90 days), UX/research: 1 (part‑time), Localization/Docs: 1 (part‑time), Community manager: 0.5 (part‑time).
• Tooling: analytics dev time, automated test framework, accessibility testing hardware (eye‑tracker, switch devices).

KPIs

• Playability: increase successful session starts from affected cohort by >= 60% in 30 days post‑release.
• Bug metrics: close 90% of P0 and 70% of P1 within 90 days.
• User satisfaction: accessibility NPS +30 points from baseline among testers.
• Regression: 100% passing automated accessibility suite in CI.
• Compliance: meet WCAG AA for web/launcher surfaces; platform-specific guidelines acknowledged.

This plan balances urgent fixes, parallel delivery across platforms, validation with real users, and clear KPIs to measure impact.

Top two pain points (evidence)

1. Matchmaking imbalance — telemetry C: average-matchmaking-skill-delta ↑ 22% and player feedback (1).
2. Stability / crashes — telemetry A: crash-rate 0.3% → 1.8% and feedback (3).
   (Feedback 2 + telemetry B: day‑1 retention fell 35%→28% suggests tutorial issues but secondary to crashes and unfair matches.)

Sprint priorities (next 2 sprints)

Sprint 1 — High priority (stability & quick matchmaking mitigation)

• Tasks:
  • Roll back suspect commit(s) from last patch if identifiable; run smoke test build. (Impact: immediate crash reduction; Effort: 2 dev-days)
  • Add server-side guardrails for matchmaking: cap allowed skill-delta per match and add soft fallback queue extension to reduce extreme mismatches. (Impact: reduces mismatched games quickly; Effort: 3–4 dev-days + 1 QA day)
  • Hotfix telemetry: enable finer crash logs and tag matchmaking events for root-cause analysis. (Impact: better diagnostics; Effort: 1–2 dev-days)
• Expected outcome: crash-rate drops ~50%+ quickly; match skill-delta reduction measurable next day; stabilizes day‑1 retention trend.

Sprint 2 — Medium priority (longer-term fixes & tutorial)

• Tasks:
  • Root-cause fix for crash classes identified from improved logs; full regression tests and platform QA. (Impact: target crash-rate <0.5%; Effort: 1–2 sprints depending on complexity)
  • Tune matchmaking algorithm: introduce ELO smoothing, regional latency weighting, and player-skill buckets to balance fairness vs wait time. (Impact: sustainable reduction in mismatches and better match quality; Effort: 2–3 dev-weeks)
  • Improve tutorial flow retention: shorten tutorial, add “skip to match” option, and milestone rewards to encourage first match. A/B test changes. (Impact: recover day‑1 retention; Effort: 1–2 dev-weeks + design/UX)
• Expected outcome: lasting stability, improved match fairness, and gradual recovery of day‑1 retention.

Trade-offs: temporary queue widening vs wait times; prioritize stability first to avoid compounding UX damage.

Summary goal
Reduce time-to-match (TtM) P90 from 90+ s to <30 s while keeping fair skill balance (MMR spread) and acceptable ping (<150 ms) for small-region populations.

Short-term (0–4 weeks) — quick wins

• Relax strictness: widen acceptable MMR window incrementally (e.g., +10% every 10s) so matches form faster while tracking MMR spread.
• Cross-region merge with ping caps: allow neighboring regions only if estimated ping <150 ms; show player notification and opt-out.
• Fill with temporary bots/AI for low-pop queues to avoid long waits; mark bot substitutes clearly and weight outcomes appropriately for MMR.
• UX improvements: show ETA, queue size and offer incentives (XP/coins) for queuing during off-peak to boost population.
• Monitor in real time: TtM median/P90, average ping, post-match MMR delta, abandonment rate.

Long-term (1–6 months) — robust solutions

• Dynamic time-based matchmaking: predictive pools that relax constraints based on queue age and player reliability.
• Regional edge servers & relays to reduce cross-region latency and enable safe merges.
• Skill-bucket hybrid: combine soft MMR ranges + percentile seeding so low-pop players still see balanced matches.
• Machine-learning predictor to forecast queue fill times and proactively adjust search strategy.
• Community/marketing: schedule events to increase active users in weak regions.

Metrics & experiments

• Primary: TtM P50/P90, match acceptance rate, average ping, MMR standard deviation, 7-day retention.
• Run A/B tests per change, compare control vs treatment over 2 weeks, ensure no >5% negative delta on retention or perceived fairness (survey/NPS).

I’d start with short-term config changes and monitor metrics, then iterate toward long-term infra and ML solutions.

Definition — Customer obsession vs customer-centric

Customer obsession means obsessively prioritizing player outcomes: constantly studying player behavior, removing friction, and making trade-offs that maximize long-term player delight and retention — not just satisfying metrics. Customer-centric is broader: designing with the customer in mind but balancing many internal goals (schedule, tech debt, revenue) without the same single-minded focus.

Concrete engineering examples for a live multiplayer game

• Prioritizing a hotfix pipeline: ship a targeted rollback/patch within hours for a matchmaking bug causing long wait times rather than waiting for the next sprint.
• Instrumentation-first design: add fine-grained telemetry (latency per region, drop rates after specific levels, social-queue abandonment) before launching a new mode so you can measure real player impact.
• Rollouts and feature flags: launch matchmaking changes to 1% of players in affected skill brackets, monitor churn and fairness metrics, then iterate — not full release.
• UX friction removal: invest engineering time to persist controller mappings and quick-reconnect logic so players return to session in <10s after a disconnect.
• Fairness prioritization over monetization: delay a paid feature that unbalances competitive play until proper anti-exploit and matchmaking adjustments exist.

Why these show obsession

Each decision sacrifices short-term convenience or revenue for measurable player experience improvements, uses real player data to guide choices, and closes the loop quickly with telemetry and rapid iteration — hallmarks of customer obsession.

Situation / Task
At my last studio I owned a new matchmaking UI for our 6v6 shooter. Internally we preferred a quick “auto-accept” shortcut to skip confirmation popups to speed sessions, but community posts and telemetry showed rising match abandons and complaints about unintended joins.

Action

• Feedback channel: combination of forum threads, Discord reports, and telemetry (match abandon rate and time-to-first-action).
• Validation: correlated spikes in abandon rate (+18% week-over-week) with timestamps of auto-accept triggers; watched a 10-player playtest and logged qualitative frustration.
• Change: replaced auto-accept with a two-second animated confirm that allowed cancel; added an optional “remember my choice” setting.
• Persuasion: presented data and playtest video to design and product, proposed A/B test to reduce risk; emphasized retention gains and UX goodwill.

Result
A/B test showed a 12% drop in match abandons and a 6% increase in 7-day retention for exposed cohort. Stakeholders approved rollout; player sentiment improved on forums within two weeks. Learned to let player signals override convenient shortcuts when KPIs and qualitative feedback align.