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 reliable rules for preparing and publishing quests without stopping seasonal production.

My role

Across four production cycles, I moved from running the process to defining requirements, recommending priorities, and checking readiness for launch. I refined the shared preparation templates, called quest kits; colleagues created their initial structure.

Product leaders set priorities. Design owned prototypes; engineering owned software design and development. A senior product colleague and engineering owned the underlying quest model. My responsibilities changed through the work, not through one clean title change.

Key decisions

1. Keep one reliable set of records

I proposed one set of quest records with clear owners and checks, while giving each team a view suited to its work.

• 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 the urgent reliability work from the larger tool. The full tool was deferred; I cannot say it shipped later.

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.

I observed fewer missing files, duplicates, conflicting versions, and clarification loops. These are operating observations, not measured time savings or revenue gains.

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; no retained record confirms delivery

The specifications, task records, and acceptance criteria are no longer available. My account is firsthand, but those details cannot be independently checked from retained documents.

What I would keep—and 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 partial tool that people could not trust would move the manual work rather than solve it. The fixed release window made smaller reliability improvements the more useful choice.

Change the proof of readiness. 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 later 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.