Going from Game Designer to Product Owner
Last year I was working with a team of designers on our most recent release, the arena battler Disney Melee Mania, where I was lead designer. This year, I’m still on this exciting project, except now in the capacity of Product Owner. Although I have experience as a Design Lead, this new responsibility has definitely had its challenges. I want to share some advice from my experience as product owner so far.
Please note that I’ve deliberately avoided going into detail about planning or operating in this role — we‘ve actually written various great articles on this! This is about my perspective as a Designer.
The roles aren’t that different
I spent more than 10 years of my career in various Design roles across a variety of different genres and platforms. One constant has been that Design is a hybrid role with a degree of project management — almost like a mini-producer. Designers need to be aware of the responsibilities of different disciplines and their associated dependencies, while making sure that everything goes according to plan for their piece of the game. Some of my most challenging and enjoyable projects have been ones where I needed to take on a lot of autonomy and ownership as a designer, which was tough then, but has paid out handsomely in the long-term because…
It’s very much the same when you look at a project as product owner — you just view things from a higher-level perspective compared to looking at a single feature or systems design. Since I’m now overseeing Disney Melee Mania as a whole, I have to make decisions with the intention of keeping everything on track. If you’d like to lead a project in the future, never say no to any opportunity which involves work on a higher level, be it directional or planning.
Listen to people
One of the most important things I did when I started as the Product Owner was to chat with people from each discipline on the team. I wanted to understand:
- How they’re doing
- What they’re concerned about right now
- What they thought we needed to keep in mind further down the road
…In honesty I didn’t even need to reach out to most people — within my first week everyone was already booking meetings with me. This really depends on the culture of the studio you’re working in, though.
Although I had some understanding of different disciplines’ workload and processes in my dedicated Design role, that turned out to be just the tip of the iceberg. I found that taking the time to go down the rabbit hole and build up more knowledge of everyone’s workload and experiences was extremely useful.
Another reason for doing this was to keep myself approachable — I wanted everyone to know they could come to me at any time with a problem and I’d do my best to help out in any way possible.
I also made it a point to encourage discussion by openly sharing my thoughts with the team. Although I’d become the key decision-maker in the project, i didn’t want to end up thinking in a silo. What if there was something I missed? Discussing the choices I was making helped me to make better decisions in the present, and made future decisions come faster.
Make timely decisions
Don’t fall into the trap of decision paralysis — it is alright to be concerned about making “the right decision”, but you don’t want to get stuck on this point. On live projects, every day is precious, so if you’re in doubt, ask for another opinion, or approach the problem from a different direction. For example if you’re trying to decide how to resolve a technical problem and you need to decide which solution to go with, consider how the player themselves would perceive the different solutions on offer.
As a Product Owner, unnecessarily delaying a decision is harmful to momentum, and current and future workloads.
Trust the team
You can’t be everywhere or do everything… An early piece of advice I was given was to avoid falling into the trap of “Ruinous Empathy”; I can’t be in every meeting or do all the work I used to.
This advice is obvious but still challenging — it is incredibly tempting to stay hands-on with certain tasks or to jump in if you see problems presenting themselves, but realistically you’ll no longer have the time, so promising to do so and failing to would be bad for the project. Also consider this: if you’re holding onto these old tasks while they’re no longer in your scope, you’re preventing others from learning new skills — I would prefer a situation where everyone is always learning something new and having opportunities to improve on themselves. Allowing people to step up benefits everyone.
Trust the team with their responsibilities and remind them you’re always available if needed.
One quick tip: early-on in this role I made a point of noting down all the work I was doing, conversations I was having, and meetings I was attending. I’d then check on this list and think about each point. Did I really need to do that task or be in that meeting?
This approach helped me to successfully delegate work and get out of meetings, leaving more time for my own responsibilities where I could be the most impactful. Use your time wisely and consider how you can have the greatest impact!
Plant seeds — Ask questions, ask more questions.
Early on in my new role, I was given the invaluable advice of making it a point to ask questions rather than simply telling people what to do. The perspective I have means I may be likely to ask something people weren’t already considering, like seeing how tasks have impacts across different departments.
I’ve also made a personal rule to try to avoid asking leading questions. If I catch myself almost asking “Is ___ feature just waiting for ____<other task> to be finished”, I’ll reframe my question to “what else do we need to do for ___ to be finished?”
Asking the prior question might make me feel better in the short term, but the second question could potentially reveal some additional concern or information I wasn’t privy to, and and would allow us to flag any potential problems early.
Another example would be if I asked “is this task almost finished?” and the colleague says “yes”. I’ve not really learned much through asking that particular question — maybe they’re a little concerned about something, but not concerned enough to mention it without being prompted to do so. The better question would have been: “what do we need to finish this task?” or “are there any unexpected problems you’ve noticed while working on this task?” Because maybe there’s an asset they’re waiting on from another team, or they need to resolve a bug or wait for another person to be freed up to assist them. By asking open-ended questions, I’ll get a clearer picture of the situation, which will then let me better tackle it with them.
The 5 whys is also useful when digging into problems — after a few questions you’ll often find the real reason for an issue is not what it seems, then you can take this anecdotal knowledge forward.
Keep track of your concerns
During each milestone, there may be a few features or situations which are particularly concerning — maybe someone has flagged there’s a risk they won’t be finished in-time or that something won’t be “fun”.
I keep a list of these issues and make sure to check back regularly. If a milestone is going well, there are typically less of these as we proceed, but if not, I can see the issues earlier rather than later.
Start the week right
Lastly I’d like to share a piece of advice for everyone regardless of discipline. This has been applicable to any role I’ve worked but is especially true when there’s management required: take the time at the start of the week to plan.
From my experience, I can feel a “trouble snowball” building throughout the week if I haven’t done this. Issues which could’ve been planned or delegated straight away instead crop up throughout the week and there’s a general lack of focus as I interrupt myself to tackle these issues one by one.
Transitioning from leading a single (albeit multi-faceted) discipline into an overall product lead has been challenging but extremely gratifying, and it’s been pretty awesome being able to grow together with the team. I’ve no doubt that many of you game designers out there will someday have to square off against this same challenge, so I hope this article has or will help you out!
If you enjoyed reading this, follow us on our Medium publication, where we post weekly. And of course, don’t forget to drop me some claps!
