From Quest Operations to Product Systems

Context and problem

Seasonal quest production depended on planning documents, spreadsheets, asset folders, manual checks, and engineering handoffs. Each tool solved a local need, but together they created recurring problems: unclear source of truth, missing assets, version conflicts, duplicated records, repeated clarification, and dependency on a small number of operators.

The product problem was not simply “replace the spreadsheet.” It was to create a more durable interface between operations and software without breaking the seasonal cadence or pretending every judgment could be automated.

My role

Across Seasons 6–9, I drove the productization of GAP’s seasonal quest-production workflow. I shaped the working form of quest kits and requirements for QMS and admin workflows, standardized content and asset handoffs, defined validation, permission, and migration needs, and coordinated product decisions with design and engineering.

I owned problem framing, requirements, sequencing, launch readiness, and product QA inside the GAP perimeter. Product leadership retained roadmap authority, design owned prototypes, and engineering owned technical design and implementation.

Role evolution 01 A transition through work, not a title swap

1. 2023 Understand the system Program Manager

   Operate GAP close to users, workflows, rules, and failure points.

2. 2024 Diagnose limitations Program Manager

   Frame fragmented logic, weak sources of truth, and manual handoffs.

3. 2024 Define the product work Program → Product transition

   Own problem framing, requirements, and sequencing recommendations.

4. 2025 Own product execution Product Manager

   Own launch readiness and product QA inside the GAP perimeter.

Constraints

• Different teams needed different working views without creating competing sources of truth.
• Established seasonal habits made a forced tool replacement risky.
• Some checks were deterministic; others required product, partner, fraud, or brand judgment.
• Engineering capacity could not support every desirable workflow in the next release window.
• The initial quest-kit structure and underlying quest model were created by other product, design, and engineering counterparts.

Key decisions

1. Support multiple views without duplicating the underlying truth

Collection-specific templates helped production teams but created variability at the software boundary. One rigid universal sheet would have simplified ingestion while making other functions harder to operate. Separate operations and engineering sheets would have duplicated state and created synchronization risk.

I framed the requirement around controlled inputs and a shared underlying truth that could support different functional views. This moved the conversation from enforcing one artifact to defining data ownership, mapping, validation, and change behavior.

Workflow transformation 02 From operating failure to product requirement

Current state Friction Product requirement

Fragmented quest specifications No single source of truth Controlled source and field ownership

Manual field checks Predictable errors escaped downstream Pre-ingestion validation

Quest names used as identity Renames could create duplicates Stable identifiers and mapping

Manual asset handoffs Missing or incompatible media Explicit asset intake rules

Engineering-assisted publishing Slow changes and fragile handoffs Roles, permissions, and admin workflow

2. Treat the quest as a product object, not content to publish

Operationally, a quest could look like a title, description, deadline, and reward. In the product system it also connected to eligibility, validation, participant state, permissions, programs, partners, publishing state, and claims.

I used the evolving model to define workflow requirements and trade-offs. I did not create the underlying schema: a senior product counterpart and engineering owned that representation and its implementation.

Product anatomy 03 A quest coordinates four product domains

Core product object Quest Not just content to publish

1. 01
   Experience

   What participants see and who can take part.

   • Content & experience
   • Eligibility & access
2. 02
   State & rules

   What the system records and how completion is evaluated.

   • Participant state
   • Validation
3. 03
   Economics & ecosystem

   How external activity connects to value and fulfillment.

   • Reward & claim
   • Partners & external signals
4. 04
   Governance & context

   Who can manage the quest and where it belongs.

   • Ownership & permissions
   • Program context

3. Adopt progressively instead of forcing replacement

The workflow entered recurring use over multiple seasons and evolved as teams learned what needed to remain flexible. I accepted retraining and a staged transition rather than assuming one rollout could erase established habits.

The trade-off was slower convergence in exchange for lower operational risk, more realistic adoption, and clearer evidence about which controls belonged in the product.

4. Automate deterministic checks and retain human gates

Required fields, stable identifiers, mappings, and pre-ingestion rules could prevent predictable failures. Readiness, contribution quality, fraud, partner constraints, and brand fit still required judgment.

The target was not full automation. It was to direct human attention toward decisions that actually needed it.

5. Protect the next season instead of rushing the bulk uploader

Engineering proposed and sized a self-serve bulk uploader. The robust version required complex field handling, media, authentication, error reporting, logging, and interface work. When it exceeded the release window, I tested the minimum useful scope and accepted deferral.

That protected near-term seasonal reliability while preserving a clearer future capability boundary. The uploader was not shipped during the period covered by this case.

Outcomes

The standardized workflow entered recurring use across multiple seasons. Operationally, it reduced missing assets, version conflicts, clarification loops, repeated migrations, duplication, and dependence on one person. These were direct operating observations, not formally measured efficiency claims.

The work converted repeated handoffs into reusable requirements across controlled inputs, validation, permissions, migration, error behavior, and admin workflows. It also clarified a durable ownership boundary: product could define the workflow and readiness requirements without claiming authorship of the model, schema, prototypes, or implementation.

What I would do differently

Instrument workflow quality before changing the tools. Missing-field rates, clarification cycles, rework, readiness lead time, and manual validation effort would have created a stronger baseline.

Force the source-of-truth conversation earlier. The workflow already contained the product model; delaying the decision allowed separate planning inputs and production-ready truth to drift.

Clarify decision rights as scope expanded. More explicit ownership boundaries would have reduced routing pressure and handoff ambiguity as functional product ownership grew.

Operational expertise becomes product management when it turns lived workflow knowledge into systems other people can build, operate, and improve.