Public commitments guide the roadmap
Once a roadmap is shared with customers, prioritization is no longer an internal exercise. New opportunities must be evaluated against the trust attached to existing promises.
Product OpsPrioritizationTeam LeadershipMulti-Platform Delivery
Chromatic Games
Restarting Product Delivery at Chromatic Games
Product Operations, Prioritization, and Multi-Platform Delivery
I led product and delivery work within a 28-person game studio, with 11 employees and one contractor reporting directly to me. The feature pipeline had effectively stopped, while public Kickstarter commitments and missed dates created an urgent need to restore delivery and rebuild player trust.
- Role
- Producer, reporting directly to the CEO
- Management scope
- 11 employees and one contractor reporting directly, within a 28-person organization
- Ownership
- Product and delivery operations, people management, and financial accountability
- Platform scope
- Ongoing PC operations, plus XBOX and Nintendo Switch launch coordination
My contribution
What I personally owned
- Product ownership
- Shaped product work, rebuilt delivery operations, managed budgets and KPIs, and owned customer-facing schedule commitments.
- Design ownership
- Hands-on redesign of the in-game interfaces shown here and creation of a reusable Unreal Engine 4 UI system.
- Leadership and delivery
- Direct management of 11 employees and one contractor, ongoing PC product operations, and launch coordination for XBOX and Nintendo Switch.
I personally designed the product interfaces shown in this case study. The broader studio and external platform partners contributed to implementation and launch.
Ambiguity
A Stalled Pipeline with Public Promises Attached
“How could we restart feature development while creating a schedule the team could execute and players could trust?”
When I stepped into the role, the art-to-engineering pipeline had slowed to a near standstill. Engineering was cycling through reactive bug work, new feature development was not progressing, and teams lacked a dependable path from an idea to an implementation-ready feature.
This was not a blank-slate product. Players had funded Dungeon Defenders: Awakened through Kickstarter and received public commitments about features and release timing. Some of the original dates had already been missed.
Pipeline
Feature work had stalled
Engineering
Reactive bug cycles dominated
Roadmap
Patch and console releases had already been delayed
Trust
Earlier dates had been missed
Investigation
Separating Team Performance from System Failure
I began by tracing how work moved, where it stopped, and what information each discipline needed before it could move forward.
- 01
Interviewed team members and department leads
- 02
Reviewed the backlog and active feature work
- 03
Observed sprint planning and execution
- 04
Mapped handoffs and identified roadblocks
Diagnosis
The individual work was strong. The larger problem was the operating system around it.
Engineering capacity had shifted heavily toward reactive bug cycles. Features did not always reach implementation with clear product direction and resolved dependencies.
Upstream teams had limited visibility into when their work would enter development, while engineering lacked a stable queue of implementation-ready features.
By treating the situation as a delivery-system failure rather than a team-performance failure, I could address the pipeline without undermining the people working inside it.
Structure
From Shape Up to Waterfall to Agile
The model gave each kind of work a clear home, then moved approved bets through creative preparation and iterative engineering.
Decision layer01
Shape Up
Frame the problem, set boundaries, and agree on a product bet before committing delivery capacity.
Learn about Shape UpCreation layer02
Waterfall
UX and art followed a sequenced production plan so assets and dependencies were ready before engineering.
Delivery layer03
Agile
Engineering pulled prioritized work into sized sprints, with QA and platform feedback informing each cycle.
Prioritization
Turning Public Commitments into Executable Bets
The initial order was constrained by features already laid out publicly. My responsibility was to turn those commitments into work the organization could execute without allowing attractive new ideas to displace existing promises casually.
Schedule reset
The project inherited Kickstarter dates that were no longer achievable. After rebuilding delivery, we reset the customer-facing schedule and met every date communicated to players from that point forward.
Roadmap constraint
Public Player Commitment
Once a feature appeared on the public roadmap, completing it became part of maintaining player trust.
Collaborative shaping group
Mario, ProducerCo-producerCEOTechnical producerArt directorCommunity manager
Shaped output
Executable Feature Bet
A feature with the major product, technical, and art decisions resolved before implementation.
Product decision
Treat public commitments as roadmap constraints
Shape each commitment into a buildable scope before the organization commits engineering capacity.
Tradeoff
Accountability reduced flexibility
The public roadmap strengthened player trust, but limited the freedom to pursue new opportunities before existing promises were addressed.
Alignment
Building a Schedule the Team Could Defend
I aligned leadership and discipline leads around ownership, capacity, and handoffs so revised dates came from a plan the team could explain and execute.
01 · Ownership
Agree on who owned what
I aligned with the co-producer, CEO, and Art Director on departmental ownership before we changed how work moved.
02 · Capacity
Estimate in the right cadence
Art estimated maps and character packs while Engineering sized implementation work and split oversized tasks.
03 · Dependencies
Make the release path visible
An Art inventory, reorganized Jira, and Episode-level Gantt plan showed what was ready and what came next.
Operating cadence
Sprint reviews and retrospectives gave the team a recurring place to surface problems, evaluate the process, and adjust how work moved between departments.
Execution
Running the PC Roadmap and Coordinating Console Delivery
Once the pipeline and revised schedule were in place, I supported DDA as an evolving PC product and coordinated XBOX and Nintendo platform delivery, each with distinct storefront, submission, and communication needs.
01
PC
Steam and Humble Bundle
Ongoing product operations, Episode delivery, storefront optimization, and player communication
02
XBOX
Microsoft
Launch planning, storefront setup, submission assets, and communications
03
Nintendo Switch
Nintendo
Platform meetings, submission support, launch communications, and remediation coordination
Additional partnersEpic GamesXsollaExternal public-relations agency
PC required continued roadmap and commercial operations after 1.0, while XBOX and Nintendo added launch timing, submission, and partner constraints.
Across all three workstreams, I coordinated the disciplines responsible for product readiness and player communication.
Outcome
Feature Delivery Restored and Revised Dates Met
Schedule result
Every customer-facing date established after the delivery reset was met.
3
Platform workstreams supported
Ongoing PC operations plus XBOX and Nintendo launch coordination
7
External partners coordinated
Platform, distribution, technology, and communications organizations
4
Operating practices retained
Sprints, story points, rotating bug ownership, and reorganized Jira
The project did not meet the dates originally proposed during its Kickstarter campaign. The result reflects the schedule established after I helped restart delivery and reset expectations with players.
Feature delivery restarted
A stalled pipeline returned to forward-looking product development.
Repeatable delivery path
Shaped ideas moved through a visible concept-to-release operating model.
Cross-functional visibility
Teams and leadership shared a clearer view of priorities and readiness.
Player commitments fulfilled
Revised dates and public roadmap work became dependable commitments.
Supporting Execution
A UI System Built for Cross-Platform Delivery
Alongside my production responsibilities, I redesigned the in-game interface and created a reusable UI system for Unreal Engine 4. The scalable vector assets and shared patterns removed implementation ambiguity and reduced the need to recreate screens independently for each platform.
UX/UI design
I designed each interface shown below as part of the reusable cross-platform UI system.
Lessons
What I Reused Later
Work must be shaped before it is scheduled
Engineering capacity was not the only constraint. Features needed clear product direction and resolved cross-discipline dependencies before entering delivery.
Ownership creates work people champion
A technical artist took ownership of a small reusable environment asset, delivered it quickly at exceptional quality, and kept pointing to it afterward. It reinforced that my role was not only to assign work, but to give specialists room to exercise their expertise and take pride in the result.
Continuing impact
The model worked well enough that I continued developing it at Magic Button Labs, where it influenced the operating approach used for the Klutch offering.
