Production

Working on Zephyr Drone Simulator as an assistant producer was incredibly valuable to my development as a project manager and team leader. Learning hands-on on trial by fire, the workflows and processes of an agile team, getting my SCRUM master certification, and becoming a change agent myself.

One of the big emphases of my transition from sales to project management was to be the link between the development and sales teams, since I had a background in both. The first major step I took towards shortening the communication gap was reworking how we reported customer feedback and requests. From the time I started at LAS, this reporting was almost entirely word of mouth from sales members about what they were hearing at shows. This led to difficulty in defining the priority of features and the frequency of requests for them.

The solution I came up with was a request tracker that sales members could report customer requests to and would easily show the number of customers who have requested each issue (the taller the request organizer, the more customers have requested it). This makes it far easier for the development team to give it priority and understand the urgency (or lack of) for implementing a new request (see second image on the right).

The other big issue this sales to dev communication gap created was a release schedule that was inconsistent and didn't allow for enough lead time to confidently generate hype around new features and updates. This led to my solution of a quarterly release schedule that incorporates an entire quarter of lead time for marketing and testing of new updates. So if in Q1 we work on Update 1.2, all feature development should be finished before Q2 starts, then in Q2 developers have time for in-depth internal and external alpha testing, and sales can start marketing this new update with confidence to prepare for it's release in Q3.

The most important thing about both of these solutions is that they are flexible. We are constantly slightly altering these processes to make it as frictionless and efficient as possible, not just for us as project managers but for the developers and sales team members who it's meant to bring together.

COG: The Cycle of Growth was an incredibly fun project to work on and manage, and was actually a final for my Game 310 class. We started with a basis of the 2D platformer I made for the mid-term and then formed a team of 5 to add original art, SFX, Music, and roguelite elements. We took a week to design and flesh out our GDD and then had roughly a month before we faced the hard deadline of the end of the semester.

Game jam, school, or personal project, I always shoot for a shippable MVP as early as possible. For a month-ish long project like this, I'll try to make sure we have a fully functional MVP by the end of the first three weeks. This obviously allows us to have a buffer in case of catastrophic bugs or reworks based on feedback. It also allows us to on any project have time for experimentation not just during initial design phases, but also to add cool features and polish to our finished project.

This leads to a few things for the projects I've worked on. First, more complete finished projects even on tight deadlines. Second, less stressful development cycles and higher overall morale and satisfaction with finished projects. Third, unique and interesting features with added juice and polish are sometimes overlooked in short-term projects.

In COG, this approach helped to make the game the most fun personal project I've made to date (05/2025). We had so much fun developing and playing the game and getting lots of positive feedback, we briefly considered further development and had some big ideas for improvements.

Affectionally named the "Biannual Birmingham Double Bubble Bubble Ball Bubble Bowl", this game was created for the Global Game Jam 2025 in person at George Mason University. For this game, I used the same approach of getting an MVP done as early as we could, but with a bit more difficulty. This was a great example of a big downside to this approach and the friction it can create in a team.

This Jam started Friday night, and we needed a finished product by Sunday night, so not a lot of time to work with. For 3-Day jams like this, I usually will try to shoot for an MVP by Saturday night, and with a team of 11 people, I was in a full producer role to help us stay on track.

Part of this MVP was simple art like a single sprite for the character that looks like an air hockey "pusher". We wanted this so that we could have a great MVP for the work-in-progress presentations Saturday night. We had some unexpected absences on Saturday, and the Character Artist had decided to work from home. This artist also didn't see why we couldn't just create the final multi-sprite seals as they could have them done by the MVP deadline. The issue with this was that even if the art was done, we didn't have time to implement the spritesheet as it required additional functionality from the programmers. We eventually came to a solution, but this highlights the importance of buy-in and trust from your developers.

When making a goal of a robust MVP significantly before a deadline, you need buy-in from your developers. Without it, this goal can easily seem like an unnecessary time constraint and lead to conflicts within teams. But with any team and any goal, trust is one of the most important things you need to create and earn as a producer and project manager. In my experience, this is earned through clear communication, patience, and understanding, some of the most important qualities and skills a project manager needs.