From Building Features to Owning Outcomes: How Game Design Is Changing

Katya Sabirova

Mobile games are becoming increasingly complex, while the ability to develop and validate new ideas quickly is more important than ever. As a result, the role of the game designer is evolving. Strong specialists are increasingly expected not only to design individual mechanics but also to understand the product as a system, independently identify growth opportunities, formulate hypotheses, and make data-informed decisions.

So where does game design end and production begin? And how can a game designer move from developing individual features to taking ownership of an entire product area?

We spoke with Pavel Lysak, Producer at SayStudio, who has made this transition himself and now helps other specialists develop broader product ownership.

"I joined SayGames hoping to be a producer, but I was still thinking like a game designer"

Pavel, you had extensive experience as a Lead Game Designer before joining SayGames. Did you join as a producer?

I'd say I joined hoping to be a producer. But looking back, I realize I was still thinking more like a game designer.

I'd previously managed a team of game designers and worked closely with producers, translating their vision into actionable tasks. When I joined SayGames, I initially worked as a Feature Owner, taking individual features from concept to release.

What I lacked was a broader product vision. Instead of asking why conversion to a second purchase was low, for example, I'd think, "Let's add this offer."

I was good at finding solutions, but I wasn't always looking at the underlying problems. And that's a fundamental difference between feature-level and product-level thinking.

What helped you move from that approach towards broader product thinking?

I learned to look beyond individual features and understand how different areas of the product affect one another.

Take monetization, for example. You might design a great offer, but if a LiveOps event gives players too many coins, they have no reason to buy it. So the real question isn't how to make a better offer, but what's happening across the product and what actually needs improving.

That's the shift towards producer-level thinking: understanding the product as a system, identifying its weaknesses, and making decisions based on data rather than isolated ideas. A strong game designer needs to understand analytics beyond individual features — and connect their decisions to the performance of the whole product.

"We want someone who comes to us and says: I believe in this idea, here’s why"

You're now hiring game designers yourself. How have your expectations of the role changed?

Today, I see a game designer as a co-producer of an area of the product: someone who helps shape its direction, set priorities, and understand how their decisions affect the game as a whole.

I don't want to tell an experienced specialist which tasks to tackle next. I'd rather have someone come to me and say, "Let's discuss our priorities. I believe in this idea, but not that one. Here's why."

Of course, we provide plenty of support, especially during onboarding. But ultimately, we expect people to take ownership of their area, make decisions based on data and experience, and bring their own vision to the table.

I enjoy working with professionals who challenge ideas and contribute to discussions rather than simply execute tasks. That's how we learn from each other and grow as a team.

How do you assess whether a candidate truly thinks like a product owner, rather than just an experienced feature developer?

We go into detail about what the person worked on and, more importantly, how they approached it. For example, if they developed a particular feature, I'll ask why they worked on it. Whose idea was it? Why did the team decide to develop it in the first place?

We also discuss how they manage the backlog for their area and how frequently they review it.

You might plan a backlog for the next year, but given how quickly the market changes, you need to revisit it far more frequently than once every six months. You may need to reconsider priorities and rearrange features. You need to keep your finger on the pulse, stay deeply connected to the market, and genuinely care about what you're doing.

"You need to know which questions to ask the data"

What level of analytical expertise do you expect from a game designer? 

For me, it's important that someone can do more than simply look at metrics. They need to connect those metrics to their own product decisions.

For example, if a game designer worked on an offer, I want them to understand why it performed well or poorly. Not just speculate that perhaps we put the close button in the wrong place, but explain the results through data. Did we place the offer at the right point in the player journey? Did the player actually need it at that moment? Perhaps it was only relevant to a particular segment of players? Was the balance right? Was the price appropriate for the target cohort? All of these questions — and many more — can be explored through analytics.

For me, a game designer's work shouldn't end when a feature is released. They need to understand what happened afterwards, how it affected the product, and what we should do next.

How is working with analytics organized within SayStudio and the whole SayGames ecosystem?

Our approach might be a little different from what some specialists are used to.

After a feature is released, an analyst doesn't come to us with a detailed, ready-made performance report. Instead, they prepare the dashboards that you've requested in advance.

I think that's an important distinction.

When you independently define which data you need the analyst to prepare, you're essentially defining the objectives of your feature. Once it's released, you have access to all the necessary dashboards. You can work with filters, select the data you need, and examine the results from different perspectives.

At companies where I worked previously, the analyst would usually prepare a report. In most cases, that was probably sufficient. But when additional questions came up, the analyst might already be busy or might not consider those questions a priority.

When you have direct access to the data, you can investigate the results yourself and discover new patterns. The most important thing is knowing which questions to ask the data to understand how well your feature actually performed.

"Today, you can spend half a day building a prototype instead of weeks writing documentation"

Looking at the industry as a whole, what's changed most significantly in a game designer's work over the past five years?

Speed. Today, you need to develop and test ideas quickly before investing time in polishing them. There's no point spending months building something players might not even enjoy.

AI has accelerated this even further. A game designer can now prototype an unusual feature or gameplay mechanic independently, test it, and only then hand it over for full development.

Previously, you might spend days writing documentation, describing different scenarios, and explaining how you imagined a feature would work — only to change your mind once you saw it in action. Today, you can use AI to build a prototype in that same time and actually experience the idea.

This is especially valuable for unique concepts without existing references. Instead of spending weeks developing them or trying to convince the team that they might work, you can spend half a day on a prototype, let everyone try it, and see whether the idea has potential.

Does that mean traditional skills, such as writing good technical documentation, are becoming less important?

Not really. The way we use these skills may change, but they're still essential.

Even if AI can generate technical documentation, you need to understand how a good specification is structured to review the result, identify weaknesses, and make corrections. You can't simply ask AI to generate a spec and send it straight to development.

AI can speed up the process significantly, but the final review — and responsibility for the result — still belongs to you.

"An experiment can go from idea to launch in just one or two days"

How easy is it to test your own hypotheses within SayStudio? For example, what happens if a game designer proposes an unusual solution that isn't part of the current development plan?

Let me give you an example.

When we hired one of our game designers, he started bringing us different ideas and suggestions for experiments. It was genuinely amusing to watch his reaction at first. He'd suggest something, and we'd say, "Sounds good. Let's test it!" And he'd be like, "Wait, what? Where are the ten rounds of approvals and all that bureaucracy?"

The thing is, nobody knows for certain what will work and what won't. If an experiment is reasonably justified by a hypothesis, why not try it?

If an idea has potential, we don't see a significant risk of damaging our metrics, and there's a strong hypothesis behind it, we can go from proposing an experiment to launching it in literally one or two days.

"There's no single right answer in game development. That's why the people around you matter so much"

You mentioned that SayGames helped you move from working on individual features towards broader product thinking. How did that happen?

I have an excellent mentor at SayGames. Now that I'm responsible for an entire project, he'll come to me and ask questions about it. He expects me to find the answers, even though he already knows them himself. He guides me towards reaching those conclusions independently.

To do that, I have to think more broadly, dive into analytics, investigate the data, and come back with my own answer. Then he'll explain where he agrees, where he disagrees, and why. And when you work through something yourself, that's how you learn.

In game development, there isn't really one universally correct answer. There are experienced people who understand which directions are worth exploring, but the same problem can have different solutions.

How much freedom do people have to suggest ideas outside their immediate area of expertise?

That's actually one of the things I really like about SayGames. Absolutely anyone, not necessarily a game designer, can write in our team chat and say, "Guys, I keep running into this issue. Something feels wrong or illogical here. I have an idea for how we could improve it."

We really value that attitude.

We regularly get together to discuss different ideas. These aren't forced meetings where everyone is expected to contribute something. They're more like informal discussions.

There's no such thing as a stupid question. Any question is better than complete silence. Even if an idea doesn't work in its original form, it might become the starting point for something completely different that we develop together as a team.

And that's genuinely enjoyable: working alongside people who are passionate about what they do and want to make the product better.

"If you're ready to take on more, you'll have the opportunity"

Returning to your own career journey, what advice would you give a game designer who wants to take on broader responsibility and have more influence on the product? What should they start doing differently today?

Look at the product as a whole, identify its weaknesses, and propose solutions. Play your own game, study competitors, study the market, understand your project's analytics, and constantly suggest ideas for improvement. And, of course, be prepared to take on more responsibility.

One of the things I really appreciate about SayGames is that people are given opportunities to develop. If you're ready to take on more and become more independent, you're given the chance to try yourself in different areas.

Of course, independence comes with responsibility. Not everyone wants that, because it also means additional stress. But if someone is ready, they'll have the opportunity.

Today, many professionals are looking for two things at once: the opportunity to influence a product and stability from their employer. How do these come together at SayGames?

One thing that surprised me when I joined SayGames was how low the employee turnover was. And that's still something I really appreciate.

It's also one of the reasons we take our time when hiring. We want to find strong specialists who genuinely enjoy what they do and are interested in growing with the company.

If someone wants to grow, they'll have opportunities to do so. We have plenty of examples of game designers who now lead their own projects. And if you don't want to move vertically into management, you can deepen and broaden your expertise instead.

AI tools make it easier to explore adjacent disciplines, too. A game designer can build a playable prototype, bring it to the team for testing, and get hands-on experience with tasks that would previously have required several specialists. That doesn't mean mastering every discipline overnight, but it gives you a practical way to try different roles and discover where you want to grow next.

We've also had cases where someone no longer enjoyed working on a particular project and, at their request, moved to another one.

We're interested in people's long-term development and try to create opportunities for them to grow within the company. We look for specialists who are passionate about their work, curious, and constantly interested in learning something new.

And when you're surrounded by people like that, you want to keep learning yourself.