Product Mindset: Why Does Your Team Need It, and Is It Worth Cultivating?
The Editor’s Note
We can all agree that awesome ideas come from awesome teams. This notion is followed by a fallacy that all you need to do is build an amazing team and then just step aside and let them do what they do best.
Yet in practice, most teams whether they are left alone or being heavily guided, fail to deliver commercially successful products. The reason is that they lack a product mindset and either can’t or won’t make the right decision.
Konstantin Mitrofanov, Chief Product Officer of Belka Games (a studio that has quietly racked up half a billion in revenues) shares practical steps on how they were able to create an organization that is both autonomous and highly successful.
A truly profound read!
What is a product mindset?
Broadly speaking, a product mindset is the ability to identify what your product needs in order to reach its ultimate goal.
When we employ this skill to make decisions, we don’t do what we want to do, what we feel like doing, or what we know how to do; we do what needs to be done in order for the product to succeed.
A product mindset means having a good understanding of the value the product has for the end consumer. When it comes to free-to-play games, this consumer is a paying player, and the tools we have for learning more about their needs include marketing research and analytics.
But I’m not here to talk about using action-based algorithms to accomplish product-related objectives (that’s a topic for another article); I’d rather discuss how to develop your team’s product mindset. As I firmly believe that:
product mindset helps us make financially successful games
product mindset is important not just for producers, managers, and game designers, but for all team members
How to tell if you need to work on your product mindset
We’ll start with a question: How widespread is a product mindset in the industry as a whole, or in your team in particular? Let’s take a look at a few different situations:
A producer can’t tell you which metric a given feature is targeted at or explain why a given metric needs to be changed to meet a KPI.
A manager doesn’t have enough team capacity, so they suggest pushing the feature with the most business potential to another version, but the current version doesn’t make any sense without this feature.
Designers and UI specialists keep redoing the user flow when they should be referencing a successful competitor.
Artists spend hours polishing unnecessary details for ordinary tasks. Or they review the assets they’ve created in a graphics editor rather than in the game itself. Or they review them in the game, but not on an actual device.
Developers build a “proper” new architecture instead of using a time-tested solution. Or they do the opposite — “save time” on the thorough development of an important module and, as a result, create a trail of problems with stability that can persist for years.
QA doesn’t try hard enough to replicate real player behavior. They limit themselves to mechanical testing and don’t raise a red flag if a feature “doesn’t play right” or breaks the gameplay flow of adjacent features.
I’m sure you’ve all seen at least some of these things before.
But we could keep going, right? If we continue this list, eventually every specialist will be on it. We’re all under the influence of internal and external forces that chip away at our focus and push us off course — the company’s founders, the community, the market, our expertise and preferences, the limits of our knowledge and skill, limited resources, coworkers’ suggestions, etc.
The hardest part is that, depending on the context, the exact same actions can be either right or wrong.
For example, if our USP (unique selling point) is a new feature, then its flow really does have to be “invented” using bold design experiments.
And if our game’s USP is graphics, then raising the bar for ordinary assets and continuing to refine old content could be an important business decision.
An advanced product mindset is like a compass that points toward your objective and shows you what’s really important and what isn’t at any given moment. It tells you what to spend your energy on and what you can let go.
That’s why we in Belka Games believe that everyone needs to develop a product mindset regardless of their role and area of expertise. This entails:
Grasping how the F2P model works
Knowing the project’s current goals and how we’re going to reach them
Understanding exactly how their work affects the achievement of shared goals
Being able to apply that knowledge in practice in order to accomplish a specific objective
If all these criteria have been met, that means that this person knows what they’re doing and why. This knowledge will have a positive effect on their engagement and their ability to set the right priorities in their work. In the end, it will lead to real benefits for the company and the employee themselves. And if they start performing better because they’re doing exactly what we want them to, we’ll end up with an awesome product.
How can you develop your team’s product mindset?
First of all, you need to have people on your team who regularly update the product’s goals and perform high-level tracking to make sure the team is moving in the right direction.
Just doing this at the beginning of development isn’t enough. The context of development — or, to be exact, the state of the product, your team, your company, the market, and the industry — all of these things are constantly changing, and you need to be able to react to these changes. If you’re a CPO, producer, or any other manager that qualifies as a product owner, then this is your job.
Second, you need to establish an effective process for providing this information to the team in a comprehensible way. I say “comprehensible” because just telling the team “here are our results, our KPIs, our feature list, our roadmap, etc.” isn’t enough. People are focused on their own tasks, and most of them aren’t going to want to spend time learning about the product’s needs on their own — especially if the team is large and some specialists are far removed from the decision-making process.
So it’s important to explain to the team where certain goals are coming from, why they’re changing, and what kind of logic is behind your goal-setting process.
Third, you need to delegate responsibility within the team. This means that even if there are specific decision-making points and people who are responsible for those decisions, you need to be able to “let go.” In other words, you need to let your team think and act independently, providing them with an overarching vision and criteria for evaluating their work, but not making decisions for them or looking over their shoulders all the time.
I’d like to take this opportunity to share our best practices for increasing awareness and developing a product mindset within our own team:
1) Give everyone who makes key decisions and manages goals, deadlines, team, and product quality, access to business data.
This recommendation is primarily for the founders. If you want people to share responsibility for the project’s (and the company’s) business results with you, you need to give them the same amount of information you have yourself. For example, you can show them your profit/loss structure and give them real numbers. You can make the company’s goals transparent and explain exactly why they are the way they are. Are we aiming for revenue growth? Want to show profitability? Capture a bigger market share?
If a producer, PM, or department head doesn’t have this information, people will start living exclusively “inside” the product.
Here’s a typical example: while trying to come up with a content-rich live ops feature, the team forgets that they’re going to have to update this content regularly so it can be reused. As a result, even if the feature is a success during its first launch, it might not make financial sense to operate it because of the costs of content you need or the extended production pipeline.
Sometimes you can increase your metrics just by scaling the team, but project leads don't come to you with this idea because they don’t understand that their team’s size and composition is also a tool that can be used to achieve the product’s goals.
2) Openly share the game’s metrics with the entire team, including how much you wanted to earn, how much you actually earned, and how earnings have trended over time.
You want this kind of openness to apply not only to the development team, but also to the marketing team, as well as all other departments that can have a direct influence on the product’s performance.
We perform a detailed results breakdown every month, and an analysis of key metrics is available to the entire team in our daily and weekly reports.
3) Transparently and proactively evaluate the performance of key solutions and features.
It’s important to not just celebrate your success, but also explore the reasons for it, and it’s even more important not to hide your failures, since you often learn more from them than from your successes.
Being able to dispassionately evaluate the results of your work and teach your team not to be afraid to look their own errors in the face is an extremely effective (if sometimes unpleasant) way to enhance their product mindset.
Hiding your mistakes just makes it more likely that they’ll be repeated.
4) Present features, review builds, and exchange opinions within the team in an open way.
Every feature in your game should be presented to every single team member on the project, without exception. As a rule, this happens after the primary documentation has been written and draft UX mockups are done. Regardless, your team’s feedback can sometimes give you a new perspective on your vision for a feature or convince you to abandon it entirely, and you can’t have this opportunity unless you really want to listen to people and consider their opinions.
It can be difficult for producers and game designers to accept the fact that they’ve overlooked something. I’ve encountered plenty of assumptions in my day that have prevented game design professionals from listening to specialists from other fields. But if you can learn to properly process your team’s feedback, then their “collective intelligence” will definitely help you get the best possible results.
Another important checkpoint is reviewing pre-release versions. At Belka, this is always an open, transparent process where every team member can provide feedback, as well as review feedback from team leads, game designers, and producers. This is a great way to help people grow professionally and keep everyone on the same page.
5) Set employees’ KPIs through the prism of the product’s current needs.
Sometimes an employee’s KPIs are basically just a set of professional requirements: complete tasks faster or better, learn to do something, augment their skills somehow, etc.
For people who directly depend on feature performance, product-focused metrics such as ARPU, retention, and conversion to a certain number of purchases are always in the foreground. In some cases this might even include a specific amount of revenue for a given feature.
For employees who don’t directly depend on metrics, you can set not only personal, but also team-based objectives that will bring people together via a shared context and give them unified criteria for evaluating their work.
6) Encourage people to do market research and take an interest in products in adjacent genres.
It’s no secret that lots of people who work in mobile game development play PC and console games in their free time. This is fine, but it’s even better if they play games that can serve as points of reference for your company’s own products.
You can’t and shouldn’t force people to research something they don’t like, but you can try to engage and support them. This is part of why we launched the Belka Experts program. Anyone can research projects that are relevant to us, and in return, they get in-office currency they can spend on merch and tech. Believe it or not, you don’t need to be a game designer to provide an excellent breakdown of a game — hardcore fans from the admin team can do it too.
7) “Share” the product mindset of team members who exhibit it at an advanced level.
If the most effective way to develop a product mindset is to use it in practice, then the next-most effective method is to learn by example. To do this, you need to:
Create a unified information space where your team can discuss the game (we already talked about this in point #4)
Encourage experienced team members to share their knowledge and techniques
In order to establish this process, we started streaming internal classes where we exchange cross-project experience on the producer and team-lead level via idea balloons and industry insights and compiled libraries of useful materials for each field. None of these initiatives was a “magic bullet,” but, taken together, they allow us to grow our team’s experience more rapidly and cultivate a healthy culture for new hires.
So does it make sense to develop a product mindset?
Needless to say, developing your team’s product-based mindset is a job that never ends. It has no ultimate deadline, and it’s common for it to get moved to the back burner when there are more pressing matters to attend to. Sometimes it might not even be clear why it’s worth spending time on it. What good is it, anyway?
The answer to this question depends on your management style and your ultimate goals. You can rely on a handful of highly-skilled people who understand everything on their own so you can focus on essential business objectives. Or you can try to create a culture in which the entire team works with as much awareness as possible, is engaged in the decision-making process, and does a great job supporting those decisions without excessive hand-holding.
Personally, I’ve tried it both ways, and, based on my own experience, I can tell you that betting on a core group of highly-skilled people with a strong product mindset entails:
High effectiveness in the moment
Fast-paced work
Inconsistency from a long-term perspective, since success depends on specific individuals
Poor scalability
Developing your entire team’s product mindset entails:
Investing a lot of time and effort without much immediate benefit
Slower-paced work
Consistent results over a long period of time
Good scalability
If we want to build a team that can complete multiple successful projects rather than just one, provide consistent results, and grow without sacrificing efficiency, it makes sense to invest your effort into establishing a product-based mindset from the get-go. This doesn’t mean you won’t need the amazing solo performers you already have — every company needs and values these guys. But it does mean relying on the team as a whole and believing that success is achieved through the efforts of every single member of your team.
