From Quest Failures to Product Requirements

Context and problem

Renaming a quest could create a duplicate. Links could break during export, media needed manual moves, and template changes could break scripts.

The problem crossed spreadsheets, files, and teams. We needed a way to prepare and publish quests reliably without stopping seasonal production.

My role

Across four production cycles, I owned GAP’s wider program work while moving from hands-on quest production to defining requirements, recommending priorities, and checking readiness for launch with design and engineering. I refined the preparation templates we used, called quest kits.

Engineering and I worked through how quest information was already structured and agreed what needed to change. I used failures I had seen in production to shape requirements and check whether the proposed fixes addressed them. Engineering owned development.

Key decisions

1. Keep one reliable set of records

I proposed one set of quest records with clear owners and checks. Each team could still have a view suited to its work, without maintaining a separate version of the same quest.

• One sheet for everyone Easier to import

  Operations, design, and engineering would have to work in one rigid format.

• A separate sheet for each team Easier for each team

  The same quest could be changed in several places, leaving conflicting versions.

• The requirement I proposed One reliable set of records

  Clear owners and checks, with different views for the people preparing and publishing quests.

2. Turn repeated failures into clear checks

The requirements below addressed known failures. They were not all fully implemented.

Recurring problem	Required response	Status
Duplicate after a rename	Permanent IDs and rules for name changes	Defined · recurring use
Broken exported links	Check formats before import	Defined · extent of development uncertain
Missing or moved media	Clear file-readiness and reference rules	Recurring workflow · automation exploratory
Template changes breaking scripts	Stable field matching and review of transfer problems	Defined · recurring use

Access rules and human checks before release remained partly implemented. The management tool organized content and work; engineering’s publishing process moved checked data into the product.

3. Improve reliability before adding more automation

We introduced changes over several cycles. Fixed rules could check data; people still needed to judge quest quality and readiness.

Engineering estimated a tool for uploading many records at once. The full version needed more time than the release allowed. I asked the team to test a smaller scope and separate urgent reliability work from the larger tool. A partial upload flow would not help if people could not trust its handling of fields, files, and errors. The full tool was deferred.

Outcomes

Quest kits entered recurring use. Internal tools and data-transfer features were delivered by the team and adopted. Other checks remained partial or uncertain; the full upload tool was deferred. Final-cycle publishing changes are unknown because I left before launch.

Across the cycles, we tracked production issues as a team and saw fewer missing files, duplicate records, conflicting versions, and clarification loops.

Delivery status and my contribution

Area	Status	My contribution
Quest kits and workflow	Recurring use	Refined preparation templates across production cycles
Internal management tools	Team-shipped and adopted	Defined workflow, access, and readiness needs
Data conversion and transfer	Team-shipped and adopted	Defined the handover; engineering built it
Checks before import	Defined · partial or uncertain	Defined behaviour and rules for changes
Spreadsheet upload tool	Proposed · deferred	Supported postponing full automation
Final-cycle publishing changes	Unknown	Left before launch

What I would keep and what I would change

Keep the reliability decision. I would again postpone a full upload tool if it could not handle the required fields, files, access rules, and errors accurately. A tool people could not trust would move the manual work rather than solve it. In that release window, smaller reliability improvements were the more useful choice.

Keep a clearer record of what was ready. I would preserve the acceptance criteria and the final decision for each known failure alongside the work itself. That would make it easier to tell which checks were delivered, which were deferred, and where manual review remained necessary. If a complete, reliable upload flow became feasible within the time available, I would revisit the priority.