Why the job of a product manager is a puzzle game

And how you can solve your project-puzzles easily and efficiently

I like doing puzzles, in my job as well as while playing a game: looking at all the pieces, having no clue how to begin and then just doing it. Starting by looking at fragments that in the end will lead to a big picture – even if you cannot see it yet. Sometimes you get lost along the way, spend hours searching for the right pieces. Sounds familiar?

Let me show you how similar managing a project is to a puzzle game and introduce you to some practices you can use to master your projects – and puzzles.

At InnoGames, we don’t only develop games but also a lot of inhouse software solutions like campaign management and creative administration tools. One of the first things we build was a system to deliver landing pages for our browser games. For a long period after that, due to other priorities, it did not get that much attention, love, and time. When we added features, we did that rather quickly. The result was two very complex landing page systems, basically serving the same purpose and not prepared for future visions and improvements. So, at one point we knew what we had to do: make one system out of them. So easy! Right? Not quite…

So many pieces: Appreciate the chaos

Imagine  it is your birthday. Your present is a box with a beautiful picture on it. You like it a lot and cannot wait to open the box. You open it and you are shocked: So many pieces! Where is the picture?

Imagine it is your first day at a new job as product manager in software development. You start a new big project. It is easily described in one sentence (“Let’s have one landing page system instead of two”) and it seems to be straight forward. Then you open the box, you start looking into the topic and what you find is: a lot!

For the landing page systems, I started by looking into the two existing products, trying to understand what they do and how they interact with each other. Which other systems are involved, what are the user flows. It was all very confusing to me, and I did not grasp half of it at first.

The start of a project is often confusing, and you are not even sure if all those pieces that you see belong to the appealing picture you had in your head when you heard about the project for the first time. What is important to understand is this: it is okay! The first phase of a project can become quite exhausting if you let yourself be overwhelmed by the chaos. What helps me is: expect it and appreciate it! When you already know that there will be chaos, but you also know that at one point it will disappear: do not get stressed out by it. Appreciate the excitement and the not-knowing. See it as a challenge, as a game that can and will be solved.

Look at the pieces: Timebox work

Let’s get into it: I took a closer look at the landing page project, which means, I looked through documentations, I spoke to stakeholders and developers, I looked at data and competitors, I talked to external service providers, I tried out the existing solutions. As a product manager at this point you are trying to understand as much as possible. It is like looking at some pieces of the puzzle in detail and trying to find out where they belong – which part they play all in all. For some key pieces this is easy and also helpful. But for some it is a lost battle to begin with. That is also why it is easy to get lost in this phase: looking too deeply into the details consumes a lot of your time but will not lead to efficient results. Still this step is important to gain a better understanding of the projects and its bits and pieces. So how do you do it efficiently?

As a solution you might want to consider timeboxed working at this stage. This is not only a great tool for focused work but also to limit the amount of time you want to spend on a topic. It helps me to make sure I am not being carried away by my longing to understand every detail of the topic. Set yourself some boundaries that are appropriate for your project. Sometimes it might only be half an hour per topic. For other things it might make sense to look into it longer, for other topics maybe you make the decision to not look at them at all. Always keep in mind that there will be chances to come back to all topics in detail at a later stage. Often things that are a big mystery right now, will later present themselves crystal clear just because they by then already have a frame, a context. Any time spent on them earlier would have been a waste of resources.

Sort the pieces into piles: Content driven structure

By now you know the big picture and some bits and pieces of your new project, but it is still overwhelming. As a product manager you rather earlier than later come to the point where you have to start organizing yourself: You start sorting topics like pieces into piles. For my Landing page system project I started by writing down whatever came to my mind and ordered those thoughts – put them into piles. The results were several lists: stakeholder names, requirements, risks, goals, milestones, timelines, user flows, success factors and some first rough concepts for key features.

In the past, I did see some projects in which those lists had been predefined and were then expected to be filled with context. Of course, there is a lot of theory out there for what has to be thought of to handle a project. So, when we started a new project, you would just have to copy the structure of wiki pages including all the subpages like project plan, roadmap, risks management etc. Then you would try to fill those pages with content. I very often ended up trying to make up my mind where to put the content that I have in my head. And later I spend a lot of time searching things on those pages because the structure did not fit the needs of the project. It did not feel natural, organic.

That is why: Try not to come up with the list or categories first but rather build them up out of what you have written down. Starting with the content will make your work much more efficient and well structured. When you are finished you can still do a sanity check against the theory to make sure you at least thought of everything: What are potential risks to the project? Do you know who are your stakeholders for which topic?

Sorting pieces by shape: Question yourself

When you do a puzzle for the first time you might think, it is a good idea to sort the pieces by shape. You would probably get lost along the way, had to rethink your approach, and start all over again. As a product manager this can also happen to you. You realize along the way that what you first thought was important enough to become its own pile, needs reordering. For my project I created a list of potential risks only to later realize that they actually belong to different milestones, I should have them listed there. The same happened concerning the user flows: I started with a generic approach, trying to create a general documentation and concept for it. It never felt smooth, but I thought this was what we needed. Only later in the process I looked again at the things I did and questioned myself: is this really the way I should structure it? I talked to the developers and stakeholders and in the end came up with another way: I looked at the user flow of each single landing page, one after the other, in preparation for the ticket writing. What in the beginning seemed like a way too detailed approach was in the end the most efficient and best way to do it – who would have thought!

To me this is one of the key abilities a product manager should master: think again! Be open for change and question your current approach regularly. Look at the results of your work from different angles. This is not only important for new projects but also for established products. Try it out with something small like writing a concept or a user story. Write it, and let it be for at least a day or two. Now look at it again. Just by reading through it you will probably already have the first improvements, even if it is just the structure or how you phrased things. Now try actively to look from a different angle. Ask: But what if…?

I am amazed again and again how complex a concept for a simple user story can turn out to be just because you look at it again and again and again. With every look you learn something you did not think of at the first glance.

Sounds like a lot more work? Maybe. At the beginning. But it will have two effects: First, you will get used to this process so that you do not need to let a few days past before working on it again. Second, even if it takes longer for you to write: a good concept is the groundwork for everything that follows. The more elaborate it is, less communication is needed afterwards and fewer misunderstandings occur that might lead to refinements.

So please make sure, even if you forget everything else from this article, to remember this: Look again, think again!

The Frame: Start building an MVP

After preparing those piles I felt confident that I had a good overview of which pieces are needed to create the picture (aka. landing page system) in the end. It was time to start putting the pieces together. What would you start with? Of course: the edges and maybe parts of a key piece.

Nowadays at InnoGames and in software development – this is no big news – you usually start with the definition and the development of an MVP (Minimum Valuable Product). You try to deliver a product that already gives your customers some value and that can be delivered fast. Based on their feedback you will iterate on it and thereby make sure to keep it relevant. For our new landing page system, we defined the MVP as one landing page that looks and feels the same as one from the old systems and can already be used for actual registrations and logins. Yet there would be a lot of features missing, things that happen behind the curtain like routing or AB testing.

For me one of the biggest advantages to work with MVPs is to focus on what is really important. To gain a common understanding of the main goal, what will be the heart of the product and what will be built around this. Without this common understanding a technical decision might go into another direction and will later lead to difficulties. The other thing I value a lot is that you will, while building the MVP, discover new pieces and already build up new piles for the time after the MVP is done. 

Done! The frame of our puzzle is done and the key visual is recognizable. It still has holes and is not connected to anything, but we learned a lot. Now you look at the other piles of pieces: which is the biggest one, which is the most important one, is there one that is still very big and feels overwhelming – does it need some restructuring? From now on it already feels more like feature development because you have something that you can attach the next thing to. What a relief!

Keep looking at the picture on the box: Feed your vision

Imagine doing a puzzle with only scanning the box once at the beginning and then put it in a closet to never look at it again. That might work for the first steps, but on the long run – how to remember where which pieces belong. It would take forever to finish the puzzle.

Especially for bigger projects that take long, it is very important to not get lost in single feature development over time. As a product manager, it is crucial to never lose sight of the big picture – the vision. Always make sure that everything you and your team do, pays in directly into achieving it!

And ideally not only you are aware of how everything you do is connected to the overall goal but also everyone else who is involved, from stakeholder to developer. It makes communication with your stakeholders much easier if they already know why something is done and it gives your developers the context and motivation, they need to deliver great work. Depending on how you structure your project, make sure that the different levels of work are somehow connected. As a simple example: In our landing page project a ticket belongs to an epic, an epic belongs to a milestone and a milestone has a direct connection to the midterm goal, which is part of the vision.

Fill in the gaps: Expect the Unexpected

At one point in your puzzle game, you are left with only some small gaps and some pieces missing. By now you are longing to run your hand over the finished puzzle, to feel the texture of the surface and say: We did it! You fill in the last pieces…

The deadline for your project is in sight, the pressure to get it done rises. All tickets are done, all checkmarks checked, you deploy to staging and then… how could we have missed this? Something is not working as expected. There are still gaps in the puzzle, but you cannot see any pieces left on the table.

Please make sure that when planning your project, to expect the unexpected. In my 10 years’ experience I did not have one single project that ran through without something we did not think of in the beginning. The bigger the project the more likely this is to happen. Our world evolves constantly and is so complex that it is nearly impossible to think of everything in advance. What you can do is: reserve some time for the unexpected so you do not get into timeline troubles. When doing this, also consider external effects: my developer team that is responsible for the landing page system is for example also in charge of some other crucial products. I never know when or what will come up with high priority. The only thing I can do is estimate and plan in the unexpected work based on the past.

If you did this, you would probably still feel your pulse going up when you would realize the missing pieces. But then you would calm down, clean up, search for the pieces under the table, find them and fill in the gaps.

Present the puzzle: Be open and ready for improvements

Finally! The puzzle is done. Since you like it so much you want to show it to your friends, proud of what you have achieved. When you told your friends about the picture and the puzzle, they all liked it a lot. But now, showing it to them, they are not 100% happy with the result. If it was up to them, they would change some of the colors and maybe even exchange some parts of the picture completely. 

Replace “friends” with “stakeholders” or “customers” and this situation can easily be transformed into software projects. No matter how careful you aligned concepts with them, let them experience the MVP, communicated closely every step of the way. Experiencing the finished product often brings up change requests. Because in the end, as much as the job of the product manager might feel like a puzzle game, the result of your project is not a puzzle but a software product. And as such it is part of its DNA to be adapted, changed, and improved over time. Never think of it as set in stone or as perfect as it is. Always be agile, stay open minded and you will never get bored with this kind of puzzle.

My finished puzzle, the new landing page system is yet to be finished. It will allow us to deliver our landing pages fast and will enable state of the art A/B testing for InnoGames Landing Pages, including routing and analyzing the traffic to optimize it. It will be built in a way that it could possibly be used as a basis for future requirements, such as generating insights and automatic fine-grained routing adjustments with possibly Machine Learning and AI. This is the plan – I am sure its details will change, and I cannot wait to see it evolve!

Conclusion

Being a product manager for software projects is a challenging and diverse task, no matter how big the project is you are working on. Add the complexity of a big project to it and it can become overwhelming quite easily – even for experienced Product Managers.

Some of the techniques described above are only needed in the first steps of a project, but other can be used in every aspect of your work. Anyways, using them will help you to manage your project and your work more efficiently, by:

1. Improving the way you approach challenges (Appreciate the chaos)
2. Actively considering how much time you spent on what (Timebox work)
3. Upgrading the structure of your processes and documentation (Content driven structure)
4. Looking at issues from different angles and thereby gain a deeper understanding (Question yourself)
5. Delivering meaningful value fast (MVP)
6. Never losing focus on the product vision (Feed your vision)
7. Making your planning and estimation better (Expect the unexpected)
8. Giving the product and the project room for evolvement (Be open for improvements)

At InnoGames, we do not publish puzzle games, but as you can see you do not have to be a gaming company to solve puzzles.