The Product Team Changes in 2019: Featured Project of the Month January 2020

In the past year, has expanded its product team to a large extent and hired its own UX people. For Micha, CPO, the era is ending now and he is changing to another TX marketplace.  To wrap up what he has learned in his time at, he gave us an interview. He told us how his relationship to UX changed over the course of his career and what his decision to expand the team as it is today was based on. 

Micha, how long have you been working at and in which role did you start?

In 2015, four product managers were hired at Two of them were responsible for internal products and two were Entrepreneurs in Residence, who were responsible for delivering innovation projects. I was one of them. At that time there were platform teams at In the first one and a half years, I was rather disconnected from the day-to-day business of, since I developed my own products. But when it became clear that the products developed on the side did not show the desired results, my colleague and I were also integrated into the team. At that time we tried out the Squad Model. This meant that we had several focus areas.

When did the term UX first appear at

We first tried to help a product designer to  become a UX specialist. We had two UX people at at that  time. I don't remember what we exactly meant by UX back then. It was probably a combination of research and design. At the same time, we had designers who we clearly differentiated from the UX people.  But what often happened, when it came to user questions and user needs, was that this dedicated UX team disappeared into a room together with the designers and half an hour later came up with the answer: "The user needs this or that!”. This was not really my idea of user-centeredness. I decided to start doing usability tests myself, partly because of my background as a self-taught UX researcher. 

What were the first results of these small usability tests?

They were very well received by They also led to interesting results. We worked with Ginetta a couple of times to do even more UX research. Unfortunately, these studies mostly happened without the involvement of the UX team and the team felt a little bit left on the side.  But I think the company as a whole realized what can be accomplished with UX research. This subsequently meant many long internal discussions. Unfortunately many of them stayed at the level of “UX vs UI”. They were very theoretical discussions that had no value for the product. The CEO at a point decided to let go of the UX team. This left a little bit of scorched earth behind and the term UX was a somewhat negatively coined as a result. I had never before experienced that UX involvement could not be positively associated.

What did you do then?

I eventually became Head of Product. And later, CPO. That was very challenging, because suddenly I was the boss of my peers. But I think that dissolved very quickly. The very first thing I did in my new role was to restructure the teams from focus areas back to platform teams. Since I was previously in one of these teams, I knew that the employees also felt that platform teams were the best solution. We also had to deal with a high amount of technical debt, and for that the platform teams seemed the right choice.

When all engineers from a specific platform are sitting together, all web people for example, or all backend people, they can articulate much better what needs to be done on the platform. But this setup is not ideal for product changes or user focus. Finally we got a new CTO, Thomas. Together with him we then evolved the setup to product teams.

What is the advantage of product teams?

The idea originally came from the Scout network (Immoscout 24). The idea is to have autonomous teams that own part of the code and can implement solutions for users from the beginning to the end. In practice, it looked like this: All web engineers and one or two backend engineers were in one team. Ultimately, in this form, we did in fact not have real product teams. Because the things we want to develop for are mostly not platform specific but really a general feature for Let's think about messaging: this is also a cross-platform project. This was a big drawback of the setup. Looking back, I would say that “delivery team” would have been a more suitable name since they excelled at executing a finished plan, but not really at discovery, product development and user needs. That is, unless the implementation is already planned and they just work through it. A bit like in a factory.

The setup worked well in the web team, but not so well in the apps teams since we had no backend engineers there. So the apps teams felt more like platform teams and eventually they ended up doing the things that were within their reach. So I think that we didn't work on the stuff that was most important, at least as far as the apps were concerned.

What was your next step to counteract these problems?

After some time we collected feedback from the product/tech team and assessed the situation. After several iterations it turned out that the right step would be to have all platforms (web, backend, iOS, Android) represented in each team, so that they can really work on a feature for all platforms completely from front to back. This way we avoid that the new features have to be adopted across the platforms and teams. In the old setup this had been a big challenge. I think the new setup is great for handling user needs and completing missions, mainly since communication between people from different platforms has been baked into the system. The teams now have much more focus. There is a buyer team, which has the mission to drive leads, a monetization team, which has the mission to drive revenue, a seller team, which has the mission to drive retention, or in this specific case to implement Origami, and an aggregation team, which has the mission to integrate other tx markets content. The teams can now ensure that they meet their goals by working on all platforms. The disadvantage, however, is that a lot more effort goes into the technical organizational structure. In the past, all the tech people were together in one team and were able to exchange ideas about what was best for the platform. This is more difficult now because, for example, all three iOS developers are in three different teams. So peer programming or pull request reviewing must now happen across teams and can't be done in just one team anymore. Consequently, the demand for guilds to work well has become very high. Guilds are associations of all engineers of the same platform. So there is a backend guild, an iOS guild and so on. A big responsibility has now shifted to these guilds. So at the moment we are learning a lot of new things. We just have to practice a little bit together. The good thing is that the product team can now decide autonomously for their missions and become experts in their field.

One team per business and or user need. I believe that the team setup is now going in the right direction.

What is still not working as well?

It's been difficult to get the designers to buy in to this new setup. In their opinion they will contribute worse designs by joining the product teams. In the platform-specific world, a designer who is very familiar with web-based designs could find solutions and contribute completely to the web team, and someone who knew the specific patterns of iOS or Android could incorporate their specific knowledge to the app teams. Now, if a designer is assigned to a team, the designer would have to be an expert on all three platforms. That person would have to be familiar with Web, iOS and Android. In my opinion, it would be right to work with full stack designers, but that's just not the case with us. We have 2 people who are very good at web design and one person who is very good at app design. We've had many and long discussions where I've tried to get the point across that it's actually more important to better understand the actual user need, and thus deliver a more appropriate solution, than to deliver the better design. But we haven't found each other there yet, and I don't tend to know any better. I don't want to simply impose my opinion against resistance just because I'm their boss. Accordingly, we have agreed to make an experiment in which they live as a service team alongside the product teams and are involved in an epic or story basis. This means that if something specific to an app comes up in the buyer team, the designer who specializes in apps will be added. This also means that the pairing between product managers and designers can suffer. Currently, the PMs do not have a designer at their side who is familiar with the team specific user problems. I think this is a drawback of the current setup and we will monitor the impact and evaluate on a monthly basis whether we need to adapt the system. Probably in the ideal case a designer would be a permanent member and sparring partner to a team and PM.

Why does have two UX researchers?

I think the question should not be why has so many UX Researchers, but why the other Tamedia brands have so few or none. I think that all companies should have their own UX researchers. This belief originates from my background as a UX researcher of course. I have simply seen that user testings and engaging with the users always creates value. It has always led to better results and a better decision making process. wants to build a performance-oriented culture.  The contribution of the product side to this goal should be an insight-based and not assumption-based process. If we really want to do this, we must ultimately provide facts. If the product managers or product designers themselves cannot do that, then you simply need the people who have the necessary tools. Our UX researchers show their peers their tools and integrate their research into the process. Getting these resources was ultimately quite easy because we started the Tricki project.  We knew that at some point, presenting newly integrated content from Homegate, CarForYou, and Ricardo on, we would facecorresponding user issues. We are no longer just a marketplace, but suddenly also a search engine for things that generally exist on the market. This has to be made clear to the users somehow. And for this we needed people who are specialized in digging out the users’ needs and expectations. I hope that can be a lighthouse in that respect also to other TX companies. If more companies had their own UX researchers, they could help to change the mindset in the product teams and have an impact on the daily work. At it seems to be well received by the teams so far and I am glad that I could make this contribution. Especially the product managers in my team often emphasize how much the UX researchers help them.

What did 2019 mean for the product team for

It was definitely the most eventful year for the product team with the most twists and turns. I sometimes find it hard to judge what we did. Often I am not satisfied when I look back on what we have done. However, this is often due to technical debts. Especially in the last year we have changed a lot at, but more on the strategic level. We have made ready to consume this newly integrated content properly. To do this, a lot of bridges had to be built with other companies. I think that we now have a kind of pioneering role and are also a very good example of how cross-company technical collaboration can be established. We have also made technological changes, from an old technology to a new one (Elastic Searching). Because in the end the whole thing has to be presented to the users very well. So we have implemented many things that were essential for our strategic repositioning. I think we have done a good job of this. We have managed to consume content from other Tamedia companies in our own product and combine this with the marketplace functionality without it being completely contrary to what users expect from That's quite a remarkable thing that we have managed to do.

Thank you very much, Micha for this interesting conversation!

What would you like to read about in our next "Project of the Month" coverage?