Team Purpose Vs Company Purpose

Knowledge / Inspiration

Team Purpose Vs Company Purpose

Enabling the Team
UXDX Community Helsinki 2019

Jori Ahvonen, Head of Engineering, Zalando discusses how his team are ensuring autonomy, mastery and purpose by aligning the team and the business for better product outcomes

Team Purpose vs. Company Purpose

Speaker: Jori Ahvonen
Hi, everyone. I hope you can hear me. So imagine you're sitting on a subway train, you look up and you see an ad where Beyonce is dancing with the coolest pants you've ever seen. I know every man is looking, "Yeah, wear those pants." So you look down, you grab your phone, you navigate to Zalando and type in Beyonce and pants into the search box but you don't get any results because Beyonce was just the model and the designer of those pants but she wasn't part of the product data. Now imagine you are a 25 years old man who just got your first invitation to a wedding as an adult and you're imagining what do men wear at weddings nowadays? So you go to Zalando, you type wedding into the search box and you only see clothing appropriate for a groom. Why doesn't it show anything for guests? Now imagine that you're trying to find a pair of winter boots. You look at the Zalando store, there is a category tree to your left and in the category tree, you look at the different options. There are women, there are shoes, you click shoes and boots but you don't see any of the waterproof ones because those were under sports shoes and boots.
So, for the last year and a half, I was the title head of fashion knowledge at Zalando and I worked with a team of around 15 to 20 people and we were solving the problems that I just showed or talked about. We're trying to solve the problem of the customer, communicating in their language to our shop and expecting us to have the basic human knowledge to answer them correctly and failing and definitely the crux of the story today is that I'll be talking about how we built a team where everyone could contribute to going from a greater customer problem to the solution space. So not just one manager or designer or someone designing where we go but rather how do we actually build a team where everyone contributes but before that, I'll introduce Zalando, where I come from. So Zalando is a fashion store. We sell online fashion. We're super big right now, we're at around 5 billion euros in revenue and we grow super-fast around 20% per year, all the time. So if you imagine 20% per year for 5 billion euros, very significant things, money, people or products.
But what's especially interesting for me is that we are really a tech company and a product company. So I work here at the Helsinki Tech Hub with around a hundred colleagues and we're just a tiny piece of the tech group at Zalando so we're doing all of the tech in-house. So we're doing everything from machine learning, design, warehouse software to the applications and the websites that you see but now let's get back to the story. Why is it important that everyone contribute to going to the solution? So, why isn't it enough that someone decides?
Not all wisdom lives in the manager. Even if I might have thought that way, sometimes I usually don't know everything and there are a lot of specialists who really do know better. So that's the core is in my book, why everyone needs to contribute. You need to bring in all the knowledge that's in the team and that means that the designer, the architect, the software engineer, the analyst, everyone needs to bring their skills and their knowledge, and only then can you really come up with the best solution that the team can come up with.
And the other reason is that you really want to have people who are invested in solving the customer problem. If you're in an environment where people are just interested in finishing the task, coming in for the paycheck to check off a box then they're not going to commit to solving the customer problem and they're not going to expand the right amount of energy to solving their task. If they have a small task in a big hole, and they don't know what the big hole is, then they might really be putting a lot of effort into something trivial that was not actually the crux of a problem.
So that's really where I come from. So we have a cross-functional team of around 15, 20 people. We have a very hard customer problem, a general customer problem that we're trying to solve and we want to bring everyone along to go from the customer problem to the actual solutions. Today I'll share three principles, principles we're very familiar with today, and then I'll share three processes. So the three principles are three things just should be present in the team, in the mentality, in the culture and if they're there, then you'll do a good job bringing everyone along and then I'll share three processes that we took into use and that worked really well for us.
So the first principle is that you want to have everyone pulling in the same direction for us, the best way to do that was that we had one customer problem for the whole team. Everyone knows that they have one customer problem. So then they can all pull in the same direction. This is not always easy. We had, for instance, designers who were loaners. So someone who was part of a different organisation and they came into our product team but they had their own goals. They had for instance the desire to get this Zalando design system everywhere to bring their design system to the parts that we were going to change. Whereas we had a completely different goal to impact the customer in a certain space if you don't have the shared goal, then you are going to expend energy in very weird ways.
And you're not going to actually make the impact that you expected. For us, it was pretty good because we are a fairly new team and we had clear direction and one customer problem, it's not always easy. Sometimes you have an organisation that has legacy products that they're running and that has other software that they're doing. So, I don't want to say that it's trivial but quite often you need to try to form the organisation so that everyone can work on one customer problem but I do realise that organizational design is often a pain but if you're working with a customer problem, it's much easier than it otherwise would be. So imagine my story about the search for instance that as fashion knowledge we're trying to model how Beyonce and pants relate to each other.
And on the other hand, we have searched who's trying to create the best search for fashion ever. Obviously, we have overlap in our goals and we can come to an agreement but if they don't work with a customer problem or a clear goal but they work with, we need to maintain a search and we need to have this and this profit margin. We are working from the customer problem world making that connection is much harder. This was the first principle. So, the second principle is constraints and this might be surprising. How do you bring everyone along and make everyone brainstorm and really sparkle with ideas through constraints? But I think that's exactly the point constraints are the things that spark creativity to solve a problem. If you don't have any constraints, then you're just throwing around ideas.
But if you do have constraints, if you understand the constraints you have, then you can really solve the right problem. So, as an example, if I'm coming up with an idea as a designer but we simply don't have the infrastructure or data that can implement that idea, then it's useless to even bring up the idea. Sometimes you might want to bring up the idea as something we need to gather this data but it really means that everyone needs to have some sort of understanding about constraints. This is really about inside the team, especially you have all these specialists who understand the constraints of their domain. So that's straightforward and also as a manager, you want to bring the constraints from strategy. If the company has a certain strategy and your organisation have a strategy, that's also constraints that need to be clear to everyone because otherwise when they come up with ideas and someone knows a constraint, they can always use that as a Trump card. No, your idea is stupid because I have this constraint but that's always wrong. Like the problem that happened before when that constraint wasn't shared openly and transparently.
There is a small thing that really bit us also and the team is blind to unrepresented constraints. So you can be very much aware of the constraints that are present in your team. If you have a really good analyst they know the data of that domain but then if you are in a situation where you don't work for instance with a UI specialist or UX specialist, they might understand something about the user interaction constraints that simply the team doesn't understand. This leads to a lot of ideas that need to be discarded immediately. So making all constraints visible and seeking out constraints that are not present in the team, is the second principle.
The third principle is analytics. I don't know how controversial this is but when we were working with my team and we were in a place where everything was in order and we were all coming up with great ideas and writing them down and sharing with each other that okay this is what we should do for Q3. This is what we should do for Q4 and suddenly we're sitting in a planning meeting and we could not prioritise. We could not argue because everyone was vested in their idea through, "I came up with this and I think this is cool and it really brings out what's cool in technology or this really brings out what's cool in the design." But that's not the language that we're speaking in a commercial company, we're speaking the language of data, of impact.
And it really means that everyone has to be literate in that language to be able to come up with a good idea. So how we solved it was that actually the whole team or actually that three teams just built reports, did user tell testing, analyzed click data to find the patterns that customers are taking on certain pages so that we had a full quarter where everyone became data literate and shared what they learned about data. After this, we went from the place where one quarter before I was saying we can't do that because it doesn't have enough impact or we can't go there because it's not really solving a true customer problem to me not even having to be present in the meeting because everyone knew what to do. They all knew the data and they knew what had the biggest impact.
So those were the three principles. Everyone is pulling in the same direction and understanding that we have one customer problem and the second thing was constraints. Everyone is aware of the constraints that the team is under. The final one was analytics. Everyone is literate in the data and analytics that are present that are important for the team. If these three principles are there, it really means that the team can do good. Like there are no big hurdles for having an autonomous, self-guided team that can actually come up with ideas internally and really be like a modern product team. Next, I'll share three principles. So these are three things that are really feeding into the three principles that I shared previously. These processes will help you do this but you can have other processes and that's fine and you can still do a good job. I really think that the principles are things that in our organisation were non-negotiable. Without those we couldn't really have everyone participate, wouldn't have everyone's ideas be treated fairly.
So the first one is outcome based goals. So this is really a part of appears when you look at a roadmap or goals that you're trying to achieve for instance, in the next quarter quite often people conflate what we're going to do with what we try to achieve from that, so if we're trying to achieve an outcome for the customer that this customer problem is going to be solved or we are going to make this many more millions of money. That outcome is separated from the things that we're actually doing like the individual tasks or individual projects: what are the features that we're building? So decoupling, these two really helps because then you can be creative because you know the constraints and you know that okay what we're trying to do is really solve these customer problems like that is our goal. Then you can come up with these initiatives, you can really solve the problem, you have constraints, and you have a goal that really sparks creativity in everyone. At Zalando, we use objectives and key results and quite often I really prefer the radical focus where you have one objective and a few key results that show if you got there. So if you're using outcome based objectives that is very good if not then please Google OKRs.
Now the thing that's coupled with the objectives is really, what are you going to do? And in our case, we worked with initiatives and they're really something in between. So when you look at the different methodologies and principles, if you go from the most kind of product-oriented one, something like press releases to define what you're going to work on. It's really a creative writing exercise. You have to have a very good way of explaining how the customer will benefit and what you will achieve. So press releases are good to explain what you're going to do but they're going to lock out a lot of people from participating because if you have a press release which is in a very fixed format and they have to express in a press release format, what you did for the customer is going to look out a lot of the engineers, a lot of the analysts and an of data scientists who really want to come with their ideas but don't want to play with this format.
And on the other hand, you might have something like agile stories where just come up with who did and for what purpose. But if it's really like a one liner thing, then it's not something that you can prioritise, not something that you can argue over, not something that's really going to last you for a full quarter. So what we did was a one page initiative, and this initiative just had why, what and how, and the why part was the most important. You always had to either show some data that says why you're going to do something. You have to describe a clear customer problem that you're going to solve or some other reason like a clear purpose. Why are you doing this? After that you can come up with all the cool ideas is you can put all the machine learning in the how, as long as you did a really good why.
And then the last process, "Demo all the things." This is really related to the principles, if you want to have constraints that everyone is aware of, that everyone understands that okay these are the constraints that we're working under. That's not something that happens over one day. One day, I came over. I told you what the constraints are and now everyone knows them. The team is a living organism, they learn new things all the time. They forget other things, new people join. You constantly need to encourage the communication of constraints and direction and especially the analytics as well. Every time someone does a customer study, every time someone really analyses the dates at the exam, they need to share what they learned and the team needs to hear it. Otherwise, they can't contribute the next time you're figuring out what to do.
Those were the three processes. So now there are three principles and three processes, as long as you're starting with one problem you have constraints and those constraints are clear to everyone. Everyone understands the data, the analytics that's a good basis and when you take these simple processes of having good goals that are decoupled from what you're actually doing and then you have descriptions of what you're going to do in a way where everyone can contribute and you're sharing the knowledge inside the whole team. Then you can really have an autonomous team that can really make an impact and where everyone can contribute. So that was it for me. I really thank you for your attention.

Thank you so much, you have a lot of good stuff. Are there any questions? Let's start here.

I have a question relating to the customer problem. It's maybe due to the fact that the Beyonce pants didn't appeal, the example didn't appeal to me. Because I haven't had this problem before, I'm a bit concerned about your definition of customer problem that how do you make sure that it's actually a real problem? Because my feeling is that from what I hear from you that the problem is really based on how the talent the product is set right now. It's not related to a problem of users. For instance problem for users is to easy shopping or find a way for outfit here in Germany. A good job was, is not finding pre-shopping or you send stuff and you can try out and you don't need to do the shopping yourself. So I see it as a clear customer problem and I would like to hear your view on this. Could you challenge actually the problem that you're working on?
Sure. So ‘I wish I could shop in a way that's natural to me’;. So this was the customer problem and it was really driven by our navigation and browsing team. So originally when they were building the category tree and we gave options for customers to browse, they really had a lot of challenges because when you have a tree it always has one parent and multiple children. So there are a lot of things that go in that. It's like a graph. It's not really a tree. That’s the core challenge and when we had the product data, which is really kind of a hard attributes of the product things like color and size and then you had this categorisation which was very fixed and through one lens.
So a lot of customers were landing in places and they were actually looking at a shirt because they really liked the rock and roll style. So they were looking at that shirt because it looks like rock and roll to them but there's nowhere on the site rock and roll and you can even Google for rock and roll and you could not Google for a search for events. Those were not present in the category tree either so there are a lot of challenges to this part and these were really things that we validated again and again with customers. So we have a lot of interviews that were done consistently. We are tracking their behavior on the site and this is really also what we were looking at in the data. Okay how deep do they go in the category?
And do they go into the category and do an immediate search because they didn't find what they were looking for or do they search for something which actually should be in the category and these kinds of things. So I do appreciate that. It's not a big problem for everyone, especially since we have the concept of a hunter. Someone who knows exactly what they're looking for, they go and find exactly that but for a big chunk of our customers, the focus is really fashion, styles, occasions, trends. These are things that are really hard to map to products like you can't say that this shoe is a trend. Like sometimes you can, if it's like an embellished shoe, I've learned things like embellished shocks, oversized coats, which are hard attributes but often the trends are really something like Nordic minimalism or all white, which are much harder to express by saying that okay by knowing the product data I know exactly what the style would be. Does that answer the question?
Yeah and just an example is that Nokia was working on, it was an old team focused on how to optimise a keyboard feature, how to make it user friendly when the iPhone came out. So for them, the customer problems are like how to make it more intuitive but it wasn't.

Anyone else has a question? No one but I have one for you. You mentioned this article. You guys are basically picking one problem, which is maybe for some of our smaller teams, it's really difficult to only address one problem, one KPI or so usually we need to do a couple of more things. So how's it working for you when you basically, how much time do you allocate? Is it like one sprint? I really wonder.

That is a good point. In our case, the customer problem that's here it's a really wide problem. So if we look at the Zalando fashion store, we're talking about maybe 10, 15 touch points or different parts of the site that all have their dedicated teams that are running those parts and their customer problems are not nearly as clear as ours was. So we had a very distinct customer problem and a very distinct technology that we're using to solve it in knowledge, graphs and ontologies. So this was a place where we had a technology that we're bringing into the company and a clear customer problem that we were using to communicate that new capability but also when we go from here to what we're doing on a quarterly basis, we look at what can we achieve in one quarter? And quite often that's a new customer problem, like a sub problem.
Still, there were so many people who wanted us to have many different problems, always both for the high level one but also on quarter bases to have fiber thing, six different things. And I think it's always wrong that you always want to focus on one thing. If that one thing is like it's hard to find exactly the appropriate size but you can usually always scope it in a way where it lands nicely in around a quarter. You want to focus on that one thing and if you have multiple things like maybe we had three teams then we had every team had one subproblem that they were solving again but always try to keep it one thing that you're trying to solve and try to express it as one thing so that everyone is really doing one thing.