Irina Nikolovska: Supercell, the studio behind Clash of Clans, Brawl Stars, Culture All, has probably the most unique studio structure in the games industry. Its culture revolves around having small autonomous teams called cells, and those cells operate without managers or green light processes and have full creative freedom. But as their game scale and the market evolves, so does the model. In 2023, Supercell went through a transformation stepping slightly away from the classic cell structure. This means that the way they're doing production has been evolving as well. I've been super curious to understand how Supercell operates at the moment. So I talked to Maria. She's a senior producer there and joined the team right when the changes started happening. So she has a very unique perspective. We talked about how they structure sprints, how they run retrospectives, how they build and manage their roadmap. Maria shared very concrete and practical stuff so that others can learn from their production playbook. Let's get into it. I mean, everybody knows kind of the supercells unique structure that teams are divided into small groups called cells and that they're giving lots of freedom to decide how they manage themselves. But then around 2023, the ⁓ company went through sort of a transformation. ⁓ guys split teams into like who working on the new games and then people working in live games. maybe it stepped away a bit from that cell model ⁓ and you joined, I saw which is kind of in the midst of things changing and developing. So I'm curious, like, what did things look like when you arrived in the sense of like how work has been organized and how has that been changing since then?

Maria Maunula: Definitely. I'm the one who usually I'm summoned when the change is happening and teams grow and they realize that, we might actually need some processes and there might be some smarter ways to do a few things. So indeed in the long history of Supercell teams were really tiny, like 10, 6, 12 people. ⁓ In order to cater to their markets, we need to ramp up on every aspect, life of marketing, comedy, all sides of the game. ⁓ And that definitely meant that the teams need to be bigger now. And one thing that we highlight internally that we really want the teams to be in for the game rather than having super many centralized mixed teams. So I'm working on a heyday team and we have been growing a lot. And by the way, we are hiring even still now today. So growth keeps going, but that also means a lot of changes. So basically every old way has to change. there's very little to production processes that used to work when, imagine it so that you have a group of four people and you're trying to decide where you're go to lunch. It's super easy because you just have a little chat. But when you're hybrid global theme with 60 to 100 people, it's just not impossible anymore to do it that way. You have to make a poll who has this food restriction and so on. You have this mental image of how hard it would be to go to a lunch with that many people. So lot of things have to change. through many learnings, pain and not suffering, but fun ways of learning how to do new ways. We have changed pretty much everything from the day I joined. The development, the love and passion for the games is exactly the same. Just how we operate on daily basis is completely different nowadays.

Irina Nikolovska: Can you give me some examples, like maybe what have been the biggest ⁓ kind of shifts or maybe the best changes that you've over saw?

Maria Maunula: There's so many. And just a ⁓ side note, every single game team is operating differently. Their needs, their group, their focus points, everything is super different. So I can mainly vote from this team point of view. But I'll try to speak from a very high level. Every single team I have been working, which is usually on the bigger side, these are the same practices that I love to bring. ⁓ One is to have structure on how we develop, how we focus, how do we stop the context switching. Which is simple thing, sprints. And usually when I come, people are like, ⁓ no, sprints, that means more meetings. But that actually clears the need for multiple mini meetings where you have to explain the same thing over and over again. When you align with your team, you have a systemic way to start your sprint where you agree what is it that we want to achieve. Simple as that. I don't mind if you're doing one week, four week, whatever in between, as long as you have a start point, this is what we want to do. We all agree, all commit. And at the end of the sprint, you look back. How did we do? Is there something we could do better? Did we learn something? Should we stop doing something? Vibe check. How did we actually do? How are we working as a team? So sprints with a clear start and end. ⁓ I have seen so many various ways of teams trying to run this, but there needs to be usually someone who really pushes for this, is waving the flag, is really rallying for it, holding people accountable for it. trying to iterate it to fit for the team's needs. ⁓ Another thing that I'm really, really knowingly known to push for is retrospectives. If you come from very agile production point of view, this is already very butter and bread for you. But a lot of the game themes, unfortunately, there is this stigma that, ⁓ retrospective. Again, someone is bringing me into this room to talk about my feelings. Ew, no. But in reality, That is the point where you actually build your team. That's where you actually build the trust. You create a psychological safety. You hold the team accountable for the actions that they want to improve. So having really good run retros is my pet peeve and that I will try to bring to every single team. But when I said we change everything, we also change everything from meetings to slack practices. So if there's anything specific you would think is relevant for most of game teams, I'm happy to dive deeper.

Irina Nikolovska: Yeah, I would love to dive deeper, maybe starting with sprints, because I'm very curious. said teams can decide how long and how they're structured. So I assume that every team has a bit of a different approach to it. But I mean, you've overseen different teams. You've also overseen different studios dealing with it. What's your kind of, maybe let's say ideal setup. How do you deal with your team when it comes to structuring a sprint? How does it look? Maybe what's the... duration which people add to it, when do you iterate, stuff like that.

Maria Maunula: A lot of the times I see teams running sprints in a way that they don't actually agree on the time or the time changes constantly. And constant change is very challenging and building up in your mind and taking your focus away. I don't mind how long it is, as long as it's usually always the same. So we're building a habit at the same time. I personally prefer two weeks. One of the reasons is that if your sprints are too long, let's say some people do it by really cycle that can be month, maybe three months. ⁓ That's super long time for people to remember what happened. Like if you already are in a practice of daily standups, people struggle to remember what did I do actually yesterday? What did I achieve yesterday? So imagine asking, hey, how did you feel about this thing three months ago? No, I'm not gonna lie. weeks is something that we can still manage. We still somewhat remember. And it's enough that the meetings are not interrupting your work or switching the context. Also, you usually at that time, this is very much mobile focused. So our iteration speed is really, really fast. We build, we prototype really, really quickly. Within two weeks, you usually should be able to have something playable in your hands. This might be awkward difference if you're building a... AAA, MMO with all these things. But even on there, you should be able to break it down into smaller, smaller pieces. And two weeks, it's kind of the standard. I really always try to go back to that. With some teams, if sprints are completely new, I maybe start from four weeks just to give them time enough. It doesn't feel like the meeting master is coming. It's only two hours from your whole month. But oftentimes I find that teams actually ask for faster cycles. So two weeks seems to be the sweet spot most of the times. Not always, not for all teams, but most of times.

Irina Nikolovska: How does the planning then go? you the person then, or is the producer the person then they initiate or gets the information and puts in the structure or everybody chips in? How does that go?

Maria Maunula: ⁓ that is so different in every company. ⁓ I would say in all the other companies in the world, feels like it has been the producer, yes. Those who come from maybe IT world, producers, your scrum master, your product owner, all of that in one package, in games. We do run the show. Especially here at Supercell, it is different because we are truly bottom up. So there's no scenario where I would come and say, team, you need to do this. There's spring planning where I can suggest those things. I can prompt this, hey, I think we should prioritize these. And the team can always challenge it back. They may propose something that they want to do or they feel is important. And of course, there's sometimes time critical legal compliances that we just have to prioritize, but everybody knows why is this happening. Mainly for me, running the show is in a way making sure that we have a place where we can look at what do we have in the backlog? What do we have? as options, the pool of options that we could and should pick. Being able to show which of these are actually critical, important, really good ideas for us to do. ⁓ Then having and enabling the team to actually talk about them, why are we doing this, why this would be a good time, is this a good time to do this? And making sure that I can kind of overlook that the team doesn't have too much work to do, but has enough and relevant work to do. That is of course, comes with the accountability for the team themselves as well. But there should be someone who can spend that extra couple of minutes to look at, you person X, chose to do these 50 items in a two weeks. Do you think it's possible? Are you gonna do some overwork? Are you gonna crunch? That's not a good thing. So maybe let's agree on a sensible workload. And for me, I feel like it's my responsibility to make sure that the commitment that we are doing is clear and something that we all agree. So making sure that we agree on that meeting, this is what we want to achieve by the end of the sprint, we have this in our hands. And I make sure to communicate that forward after the sprint planning for the rest of the team, rest of the stakeholders and making sure that we follow up. And this comes back to the retrospective. So I often see in the retros that teams use it mainly for kind of ranting sessions, which can be healthy as well, but ideally, your retrospective results, you having an action, you want to change something. It might be something that you learned during the sprint. ⁓ Maybe there's an iteration that needs to happen because of the work that you did on the sprint. So the retrospective would follow up on that and take an action that you will commit in the next sprint. And at the end of the sprint, you again look back, did we do this? And it's this continuous loop that keeps you guys improving and improving and improving.

Irina Nikolovska: So the retrain itself has a structure or like an agenda by itself. It's not just like a free meeting where people can offload.

Maria Maunula: Yes, Maybe to give a bit more context for, especially if you have listeners who have never evident retros. many, many ways to do it, but on a high level, simplified version, on a sprint planning, you agree what is it that you want to achieve, you work on it, you work on it during the sprint, you probably have stand-ups, checking points where you just talk, we ⁓ on the right track, are we heading to the right direction. At the end, when you have your retrospective, usually run it ⁓ at Miro. I love the tool called Miro if you have never used it. It's free for small teams, decent pricing for bigger teams. It's virtual whiteboard and we are hybrid teams. We have to have a virtual way to work on it. I use a team if I to feel and look like the game so it doesn't feel exactly like yet another charts, Excel sheet, exercise meeting, but a place where you can come and share your opinions. And I started from the sprint goals. So, guys, what happened in the last two weeks? Did we actually nail this? Did we achieve this? If not, let's talk about it. Why didn't we? If yes, feel good, feel proud. This is great. This is exactly what we wanted to achieve. Then I go back to the actions we chose last time. Classic example. At one point, teams often choose a ticket management tool, let's say Jira, that everybody keeps hating. Often it comes up, we don't find Jira useful because we don't... update enough information in the tickets, we don't tell keyway where to test, we didn't update the status, you know this as well. And the team can choose to then actually, hey guys, we actually need to do better tickets and we have to commit to that. And I'm holding the account accountable asking them, so how did it go? Did you actually remember to do this? Did you update your tickets? you add the relevant information? Often they feel a little pinch in their heart. Maybe we don't solve this in a one sprint. If not, I'll keep it there. If yes, we feel, hey, we actually nailed this. We did improve. Then we can take that out from the board. After those initial start points are done, I go through the very usual practice of ⁓ three minutes, ten minutes, X amount of time for silent working. Here's an area, stick your notes, go write, what went well? What did you feel good about? What made you proud? Did you learn something new and exciting? What was fun? What made you feel good in general? We write them up, time goes out, we talk about them. There's different opinions, some people love to do anonymous, retros. I hate them. Just kill them. If I'm there to build trust with the team, anonymous, that just doesn't work with. You want to hear and see that feedback coming from the people, then it feels meaningful. So I will make sure that everyone in the room actually talks out loud and it's easier to start from the good things, of course. We got through the good things, then we moved to the challenging part. What made you frustrated? What did you slow down? What did you... What really annoyed you during the sprint? What blocked you during the sprint? What made us fail on those goals, for example? And again, we spend a little bit of time writing those. Then we talk about the challenges. And then we go to the most important part that often people kind of rush through or skip completely. So now we know the good and the bad. What are we going to do? Are we actually going to do anything? What could we solve? Is it something that we as a team can actually change our behavior? Is it tooling that we need to add into the backlog? Is it IT technical solution that we need that would help your life? Whatever it is, we talk about the actions, we commit to a few of them. One mistake I have often seen is people try to commit to hundreds of actions at the same time, not going to work. Or even worse, They talk about the right things and they choose really good actions, but they don't assign anyone to own it. And then that doesn't happen. So I want to make sure that there's clear, simple actions. There's a clear owner, person who's going to drive these things. And then I make it public. I write those up. I put them somewhere and I keep following back to those. In addition, I have this tiny, this is completely optional, but I have found it very useful. People love data. I have this super simple one to five rating. How did you feel in the last print? Just your vibes. And it's just two seconds thing, people track the sticky note with the name on the scoring and I count the average from that sub-cell or team. How are they actually feeling? And by the time I can see, are we heading to right direction with all these changes? ⁓ Or maybe something big happened in the company. Someone made a really stupid decision somewhere that impacted all of the team. I can use that data to show the consequences to the people making those things. That was a lengthy answer, but I hope that gave you details.

Irina Nikolovska: I know this is great. Thanks for being as detailed because this is something that people can actually take over, which I love a lot more than if it was vague. I'm wondering, like, I mean, it's quite elaborate and it gives a lot of learnings. Do you do this then after every sprint? So for instance, if your sprint is every two weeks, like every two weeks you do then the retro.

Maria Maunula: every two weeks and I promise you everything will first feel like ⁓ this is so time consuming and annoying but in the end actually quite a lot of the teams asked more time for the retros they saw the value they learned the impact and they want to do it more because they see that it actually changes their lives so it just takes a bit of a pushing and sticking to it and then then it will reveal wonders

Irina Nikolovska: It also becomes, I guess, a habit and people notice the value, so it's easier to convince.

Maria Maunula: Exactly. And that comes down to the habit thing. So oftentimes I've seen teams setting up sprints, but first they're like one week, the other one is like six weeks, and then there might be skipping some sprints and then we get back and just have it systematic. It's a bit of pain in the first, but then you make it a habit. Everybody knows when it's going to happen. They can prepare mentally. Even if it's a really good setup, ⁓ in a practice, for example, I set the sprint board in advance. So when people have those moments during the sprint, if they want, can immediately go and ride it up when their feeling is the strongest, like, I fucking hate this day to day. Something went really bad because of X, Y thing. Maybe I should talk about this in the retro. Or I can immediately go push it there and it's out of my head, but I know we will get back to it and nothing gets lost. So plenty of tiny little things that you can do to make it a good habit.

Irina Nikolovska: That makes sense. Also, like, since you're having like the retro after every two weeks then, how many touch points do you have in between? Do you have like a daily standup? Do you have like a weekly check-in like Monday, Friday or something like that? How does that work?

Maria Maunula: This depends a lot, and I can completely admit that. When I was a junior producer, I was following the book to strict. was like, we need stand-ups every single day and they need to be this way structured. Nowadays, after many teams, I asked the team, how often would you like to talk about this? How often do you think we need to see? If it's completely new team with a lot of variation from seniors to junior, I try to encourage touch points quite often, perhaps even daily stand-ups. ⁓ With this senior routine here, we have two in a week. There are 15 minutes time box, super clear, sharp. Do you have any blockers? And people know basically that if I have a blocker, I don't need to wait until they stand up. I can just ping it in Slack immediately. And I'll also use those standups as a communication point to inform or repeat some of the news and info that might come because within new teams we have so much information. that it just might easily get lost. So that's a good like a little check-in comms, anyone having issues, back to work kind of thing. But that also means we are super active in Slack and super communicative outside of those meetings. So might not work for everyone. In addition, we do have a Slack thread every day where people can share what did they achieve. For example, if I did something that's not ready. I achieved it yesterday and it might impact on someone else's work. It's good for me to let it know on the daily thread. ⁓ same with the blockers if I'm really stuck somewhere and need someone to help me, it's better to share it on daily basis.

Irina Nikolovska: Yeah, makes sense. How do you actually plan out the sprints in themselves? Do you have maybe like a longer roadmap that you build out? Do you plan the whole year? Do you plan half a year? Do you plan quarterly? Do you do some other type of big picture planning? What's approach there?

Maria Maunula: There's many things that connect to that, but yes. ⁓ First of all, I want to make always sure that we do have one source of truth, one big roadmap for all team, even if you have multiple sub-cells or bots or however you want to call them. There needs to be a place where anyone in the team can go, this is where I know information. That information includes all the release dates, all the meaningful dates, holiday dates, holiday seasons, anything that might impact our work timeline, ⁓ as well as the months. the days and the sprints along with them. And I tried to look at the whole year. It will be a living document. It might change, but at least the sprints I tried to look in already throughout the year. So everybody knows what is the sprint number, where are we heading, which sprint it is now. And there are some special cases, for example, those who work from Nordic countries, especially Finland, we are notoriously known for summer holidays. So when July hits, everybody's out basically. So during that period, I might skip a sprint or make it super long special case. Not happening all the time, but for certain reasons and ⁓ needs and wants, sometimes there needs to be a little bit of a difference.

Irina Nikolovska: How do you do that pretty planning more granularly? you just like add everything to JIRA? Do you build like a different, ⁓ like a, I don't know, a master document or something? Is there like a big meeting where everybody's briefed and then they can just like toggle there and just read notes?

Maria Maunula: A bit on a different topic. So the roadmap I mentioned was more on the timelines and release cadence and all that. If you take about the roadmap itself, what features are going to go into what release planning in general, patches, live content, and so on, so on. That is a way ⁓ bigger, vast topic with a lot of variation. So it depends a lot how the teams work, what is your game, what is your cadence. For us, because we have these subcells and many other game teams I've been working for, we dictate what is it that we want to deliver basically. And depending, of course, on many, many things. If it's, let's say, a feature, innovative new feature, you want to build something new, we talk about it as a team, we look into the design. Once we have committed to this feature, we estimate and break it down into smaller milestones. By that, we can kind of have a good guesstimation when could we release this. ⁓ This is also heavy emphasis on the roadmap being a living document. I've seen companies trying to force features going out on certain dates and this is now very much a free-to-play mobile world. This might not work at all for different kind of games but we in a way have the luxury to iterate. So even if I say okay guys now we're gonna work on this feature we think it's gonna take this time. During the development, we constantly playtest, iterate, maybe do user testing as well with our creators or tools like Playtest Cloud and so on. And if we need the time to iterate, we'll iterate until it feels good and polished enough to go out. So that might mean changes in the roadmap. That's why it's super living document constantly. In our case, every sub cell needs to then update constantly if there's going to be changes on the roadmap. We do of course have bigger meetings together with leads and other stakeholders that may have input thoughts and forecasting and all this. it's not something I can easily explain in a few sentences. from this point of view, from developer point of view or smaller teams point of view, if you have the autonomy and ownership, you are accountable of planning to release timeline. You probably should break it down, estimate it and then commit.

Irina Nikolovska: I know it's a big topic, as you just said, ⁓ but forecasting has been something that we keep on hearing from studios. That's maybe one of the biggest challenges. Like everybody knows like what they want to build, but really defining timelines and dates and budgets. It's always difficult, especially when you start doing it on a more granular level, like trying to understand how much time and effort and budget is needed per maybe asset, ⁓ which people can be allocated where. So kind of this like... whole forecasting thing tends to become a bit, yeah, pretty big challenge. ⁓ Again, I know it's a huge topic, but maybe can you give me a bit of like a glimpse of like, how do you guys deal with it?

Maria Maunula: Hmm. There's some parts I cannot open or touch, but how would I break it down? For us to look forward, we always try to look at it from the point of the player. We are going to have these windows of opportunity, so every release we can ship something out. We should ship something that's relevant, fun, meaningful, interesting for the player. Every release should bring, of course, ideally results fast as well. Every feature exists there for different reasons. ⁓ We would not commit to those features unless we know what is it that we want to achieve by doing this feature. So if that setting is done in advance, you have an idea why is it this feature, what it will do, what is the outcome out of it. That's actually what you're building into the roadmap. Not really, ⁓ in this release, we are going to release this feature X. But in this release, we actually expect this outcome during this time, especially because in the free-to-play world we do lot of A-B testing. So even if we would in this release roll something out, it might not be at the full truth of the outcome because we might be releasing it to 5 % of the players or maybe 90 % of the players. The forecast should look into when this is actually 100 % out. So when all the players have this, if everything went well, no issues found, we can roll this out. What is the outcome then? And that should be already planned way before we even come to the feature. If that is done the right way, then you can start to build this idea of, by this time, this outcome should happen. How would that impact into our numbers? Where should we be at this point? And that's why we constantly, every month, look at, we heading towards the right direction? Maybe there's curveballs, maybe there's risk, maybe there's legal issues, maybe something didn't work out. And that's why it's kind of, it is forecasting. It's not the truth. It's not how it's going to always go, but it gives us direction, goal, guardrails. This is where we're heading. This is where we should be heading basically. That of course comes down to many, many, many things from user acquisition to the game and teams needs once, technical capability, market appeal, all of those things. So it is guessing, but it's very much educated guessing. based on all those variants from data to gut feeling to all of those bits and pieces.

Irina Nikolovska: Do you also use any specific tooling to help you sort through all this data out?

Maria Maunula: Oh, I would say every single mobile studio at least have data tools. Ideally, you would have a really brilliant data people to work on this as well, who would build you dashboards that would reflect the truth. So let's say we would do a feature. We have expectations of this feature. We should have a way to look into the data. ⁓ you're building something new and unknown, you might not even have that data, but you still should have a way to validate it afterwards. So as part of your development, you might need to build a data pipeline for it. ⁓ you are iterating existing features, that's of course way easier because you probably already have data coming. ⁓ a very classic thing that a lot of the free-to-play games are optimizing is a tutorial, the onboarding experience. You probably should have data every single step. How do your players come in? Where are they churning? And maybe your goal is, we just want to fix this churn point, for example. So then you already have a data point where to look at how to improve it. What would be a good result? Only what would be a good result? It's also a bit of the studio's ambition, the team's ambition, the risk taking capability. There's no one ⁓ way to fit for all, kind of. situation.

Irina Nikolovska: You mentioned that this is also quite like defined on a cell level. We've talked about kind of the structure differing, but also the tooling differing. So you mentioned Jira and Miro and Flac and so forth. Does it mean that at Supercell, like every team can decide what they use and how they use? And if so, like how do you congregate all of that?

Maria Maunula: Yes, ⁓ every team can pick the tools that they need and want and thinks this will help us going forward. ⁓ Sometimes it's just because people are used to having some tool and it's just easy to pick up the same tool. Sometimes your team is growing and scaling, perhaps you need a tool that can support that a lot more. ⁓ Sometimes it's just the best practices learned. Sometimes you just want to try new tools, for example. ⁓ There is no easy answer or solution to figure it all out. ⁓ It comes definitely a lot of by the experience. For example, I'm not always known as the JIRA person, whether I like it or not, ⁓ but I'm the one who brings JIRA in. And for me personally, I've chosen that tool for various reasons. One is the scalability. when your teams are big, you have a lot of external partners as well. have to think about security. How do you share things out? How you manage? hundreds if not thousands of tickets across multiple subsells. So just one of those things why I chose this specific tool. But within the company we have so many different tools in use. Even within our teams we have multiple different tools for different use. Yes, honest answer is it is sometimes pain to manage all these tools. I'll try to systematically kill as many as I can to have a little bit smaller pool of those tools, but not always so successfully.

Irina Nikolovska: I get it, I mean it's a challenge across almost any studio and yeah there's always the Jira, everybody hates it but then we stick with it, point.

Maria Maunula: I'll try to make it not so hated, more usable.

Irina Nikolovska: Fair enough. A bit like maybe, ⁓ yeah, high level. ⁓ You have quite a vast experience, so like different types of studios, different contexts. ⁓ So you've built kind of your production know-how and toolkit from all of those experiences. If you had to name like one production habit or framework that has had the highest impact regardless of the studio context, what would it be? Where would you start?

Maria Maunula: There's pretty much four apps and systems that pops immediately out of my head. So Slack, Slack, Slack, all the way, Slack, please, Slack, always. Slack is one of the best communication tools I have ever, ever used in my life. And I've been there for a long time for various uses and tried all of them, Discord, Outlook systems, all of that. Slack is the king. In addition, for ticket management, as mentioned, Jira, it's a so... ⁓ Modifiable, there's so many plugins, it can connect all of your tools, it can use AI, it has built-in AI as well. It's scalable, it's very secure, it connects to a lot of different apps outside of it like Confluence and so on. ⁓ Miro, 100%. Miro is so multi-use system. It can be a design board, it can be a brainstorming board, it can be a retro board, it can be anything and everything you want it to be. It is my roadmap as well. And then the classic king of it all. Sheets, Excel for some, Google Sheets for me. It's so easy to share, easy to use. Everyone in this industry has the basic how to use it. And you can use it as easy as you want, as complex as you want. It's great for math, data, even roadmaps, even sprint planning sometimes. I have used Sheets. I'd not to, but it's a very versatile tool. So, Myro, Chira, Sheets, Slack.

Irina Nikolovska: Fair enough. You just mentioned AI. I'm wondering, because it's such a big topic and everybody talks like, yeah, AI is changing everything and things are never gonna be the same. But I feel like a lot of it comes from kind of talking about AI for code assistance or maybe a bit of art generation or brainstorming. I wonder, like from your point of view, or from a production point of view, what are you seeing AI changing in terms of game production that hasn't been kind of done before and where do you think it will go towards?

Maria Maunula: ⁓ Good question. I would say I'm a little bit, I'm very practical person and I'm more on the side of I execute. So I'm not the visionary person who could foresee all the things AI can do. So I'm happy to see where it goes and I'm happy to use it where it makes sense. I personally hate the AI bubble where everybody's like, let's just use AI for AI sake. And I'm like, so what is the outcome you want from this? Why would we use it? What does it help you? So as long as AI is there to help you with something, it makes things faster, easier, great. ⁓ On the actual production, code, art, so on, on, absolutely helpful. There's plenty of ways to use it. Production, we just had a good chat about this with my fellow producers. We were thinking, is there something we could solve with AI? For us in this current situation, we actually ended up that a lot of our challenges are actually automation, not AI. We don't need AI to infuse this. With automation we can solve a lot of the things for us. So I'm curious what AI will bring on production craft specifically. There's been only like super minor things I've seen for example let's say the retrospectives. Classic thing is that as producers we'll need to go through the individual sticky notes, write down notes. At Miro AI you can just clutch the template topic, have your automated notes out of it. Jira, you get your release notes automated with... Even that is automation, it's not AI really. ⁓ I'm sure there will be more, but so far I haven't seen anything super peculiar or something that would really, really make my life easier on that side. That being said, I am having a virtual sparring friend with my dear Chat GPT Claude. ⁓ The skills that I'm... I'm not saying I'm lacking, but I'm not the best because I'm truly a producer. I'm not a product owner, for example. But I often want to think about product owner things. I do spar with this. It's not even a personality. It's this entity that I have been training with our data, our context, our team structure, our ways of working. And I use it to, funnily enough, actually to roast me. So whenever I'm making a decision, I'm tossing it back to this AI and ask it to ask me the questions that I may have forgotten. But that's more personal practice rather than a production craft thing.

Irina Nikolovska: Yeah, I have, I do that too with Claude. My CEO actually, Riad he wants to set up an AI for our team that would kind of be not mean, but would kind of be the devil's advocate for everything we're saying. So yeah.

Maria Maunula: I literally made my really evil because of that like it throws me, damn

Irina Nikolovska: I feel you, I just get very sensitive at one point, I'm like, why are mean to me?

Maria Maunula: Perfect.

Irina Nikolovska: But yeah, I get the whole, I feel like as well, like for a lot of things it ends up being, it's great for summaries, it's great for challenge until a certain level, but yeah, where it will take us, it's a big question. But yeah, I'm very curious because I feel like for production, ⁓ it's still kind of a bit of a question mark, I suppose. You mentioned automation. What are like the bigger ⁓ automation things that you work in terms of like trying to simplify or? manage your production work.

Maria Maunula: There's a lot of tiny, tiny nibbles and knobs that we could easily do, even on JIRA level. Automations, like what happens when your ticket is in a status ready for testing? Could it automatically be assigned to someone? Yes. What happens when you have release coming and on JIRA you have your fixed version? What if you would have automated release notes, for example? So just all that manual little work that teams have been doing manually, painfully, slowly. that probably can be automated. One of the ⁓ pains that, for example, production craft has is the summer holidays. So ⁓ you have people in a different location, different country versions of running holidays, ⁓ want to be able to predict ⁓ would we have a bottleneck, if I would have a bottleneck. ⁓ on how your teams have set up a way to see your holidays, maybe a holiday calendar, maybe you have a tool for it. ⁓ there I would I kind of want it to have, for example, flags where it tells me that, by the way, you have now 10 out of 10 people in your team requesting a holiday. This is a red flag situation kind of thing. So these super tiny examples that would just make my life easier, basically.

Irina Nikolovska: Fair enough. I have maybe one last question. So, I mean, you've had years of experience in production. So imagine you have one in your hand and you can wave it and fix just maybe one thing about how the game industry does production. Maybe it's something that doesn't exist yet or something that can be done better or a standard that nobody has agreed on or a tool nobody has built or a practice. that the whole industry should maybe adopt, something like in that direction, what would it be for you?

Maria Maunula: The one thing I hope every single game team in this planet, no matter if you're free to play, you're AAA, if you're indie, if you're big studio, it all starts from your core alignment. What is your North Star? What is it that you want to achieve? That is often not clear. Even if you think we just want to build this great game, we want to this next big thing, everybody's so excited, everybody's super senior, ambitious, if you don't align on that one simple thing, you're screwed. your roadmap will not hold on, your team motivation will not hold on, your timelines, your workload, none of that will hold on. So make it super clear. What is it that we want to achieve? The why of it all. I love Simon Sinex why how what? If the why is not clear, you're simply screwed. So make sure that that is always crystal clear, documented, shared, repeated like 800,000 times for your team and everybody's committed to the same thing. I don't know whatever tools or AI magic or practices you need to have for that, but make sure that that is clear. That's where I see most of the teams fail in the end. If they are not aligned, what is it that we want to get out?

Irina Nikolovska: Nice, that's a really nice words to wrap this up. Thank you so much, I really appreciate it. It also gave me a lot of things to think about. Nice!

Maria Maunula: Perfect.