Team Purpose Vs Company Purpose

Jori Ahvonen at UXDX Community: Helsinki. Video: https://www.youtube.com/watch?v=9SCLOEgPmDM

Readable transcript: edited from the recording's captions for readability (fillers and false starts removed, punctuation and section headings added). Wording is the speaker's own. Timestamps are positions in the video. Names marked [?] could not be verified against the audio.

Three customer problems

[00:00:09] Hi everyone, I hope you can hear me OK. There are lights. It's a bit different from what you just heard, but it's going to be good anyway. Imagine you're sitting on a subway train. You look up and you see an ad where Beyoncé is dancing in the coolest pants you've ever seen. I know every man's looking at them, you're going to wear those pants. So you look down, you grab your phone, you navigate to Zalando, and you type "Beyoncé" and "pants" into the search box. But you don't get any results, because Beyoncé was just the model and the designer of those pants, but she wasn't part of the product data.

[00:00:54] Now imagine you are a 25-year-old man who just got your first invitation to a wedding as an adult, and you're imagining what 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?

[00:01:25] Now imagine that you're trying to find a pair of winter boots. You look at the Zalando store. There's the category tree on your left. You look at the different options: there's women, there's shoes, so you click shoes and boots, but you don't see any of the waterproof ones, because those were under sports, and shoes, and boots.

[00:01:56] So my slides are not changing. OK, now I am very confused. I can't get the slide to change, and I don't know why. Oh, good point. Oh my god. That was a good learning: never put the last slide first. Thank you. I'm good.

Fashion knowledge at Zalando

[00:02:47] All right. For the last year and a half I held the title head of fashion knowledge at Zalando, and I worked with a team of around 15 to 20 people. We were solving the problems that I just talked about. We were 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 us failing.

[00:03:26] 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 deciding where we go, but rather how do we actually build a team where everyone contributes.

[00:03:50] But before that, I'll introduce Zalando, so you know where I come from. Zalando is a fashion store; we sell fashion online. We're super big right now. We're at around five billion euros in revenue, and we grow super fast, around 20% per year, all the time. So if you imagine 20% per year on five billion euros, that's very significant: actual money, people, products. But what's especially interesting for me is that we are really a tech company and a product company. I work here at the Helsinki tech hub with around 100 colleagues, and we're just one piece of the tech group at Zalando. We do all of the tech in-house, so we're doing everything from machine learning and design and warehouse software to the applications and the websites that you see.

Why everyone needs to contribute

[00:04:55] Now let's get back to the story. Why is it important that everyone contributes to going to the solution? Why isn't it enough that someone decides? Well, 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. That's the core reason 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. Only then can you really come up with the best solution that that team can come up with.

[00:05:49] 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, checking off a box, then they're not going to commit to solving the customer problem, and they're not going to expend the right amount of energy on solving their task. If they have a small task in a big whole and they don't know what the big whole is, they might really be putting a lot of effort into something trivial that was not actually the crux of the problem.

[00:06:25] So that's really where I come from. We have a cross-functional team of around 15 to 20 people. We have a very hard, 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, my principles, which are very popular with me today, and then I'll share three processes. The three principles are three things that 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.

Principle one: everyone pulling in the same direction

[00:07:15] The first principle is that you want to have everyone pulling in the same direction. For us, the best way to do that was to have one customer problem for the whole team. Everyone knows that they have one customer problem, so they can all pull in the same direction. And this is not always easy. We had, for instance, designers who were loners: someone who was part of a different organization, and they came into our product team, but they had their own goals. They had, for instance, the desire to get the 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're going to expend energy in very weird ways and you're not going to actually make the impact that you expected.

[00:08:15] For us it was pretty good, because we were a fairly new team and we had clear direction and one customer problem. But it's not always easy. Sometimes you have an organization that has legacy products that they're running and 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 organization so that everyone can work on one customer problem. I do realize 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.

[00:08:55] Imagine my story about search, for instance. We in fashion knowledge were trying to model how Beyoncé and pants relate to each other, and on the other hand we have search, who are 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 the customer problem or a clear goal, but they work with "we need to maintain search and we need to have this profit margin," and we are working from the customer problem world, then making that connection is much harder. That was the first principle.

Principle two: constraints

[00:09:39] 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.

[00:10:14] 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 "we need to gather this data," but it really means that everyone needs to have some sort of understanding of 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.

[00:10:52] Also, as a manager, you want to bring in the constraints from, say, strategy. If the company has a certain strategy and your organization has a strategy, those are also constraints that need to be clear to everyone. Because otherwise, when people 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 know this." But that's always wrong. The problem happened before, when that constraint wasn't shared openly and transparently.

[00:11:26] There's a small thing that really bit us: the team is blind to unrepresented constraints. 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 if you are in a situation where you don't work with, for instance, a UI specialist or UX specialist, they might understand something about the user interaction constraints that that team simply doesn't understand, and this leads to a lot of ideas that just need to be discarded immediately. So: make all constraints visible, and seek out constraints that are not present in the team. That was the second principle.

Principle three: everyone literate in data

[00:12:17] And the third principle. I don't know how controversial this is. When we were working with my team, we were in a place where I thought everything was in order. We were all coming up with great ideas, writing them down and sharing them with each other: "OK, this is what we should do for Q3, this is what we should do for Q4." And suddenly we were sitting in a planning meeting and we could not prioritize. We could not argue, because everyone was vested in their idea: "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."

[00:13:09] 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. How we solved it was that the whole team, well, three teams, built reports, did user testing, and analyzed click data to find the patterns that customers take on certain pages, so that we had a full quarter where everyone became data literate and shared what they learned about data.

[00:13:48] After this, we went from a 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.

[00:14:10] Good. So those were the three principles. Everyone pulling in the same direction and understanding that we have one customer problem. The second was constraints: everyone is aware of the constraints that the team is under. And the final one was analytics: everyone is literate in the data and analytics that are important for the team. If these three principles are there, it really means that the team can do good. There are no big hurdles to having an awesome, autonomous, self-guided team that can come up with ideas internally and really be a modern product team.

Process one: outcome-based goals

[00:15:02] Next I'll share our three processes. These are three things that really feed 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. But I really think that the principles are things that in our organization were non-negotiable. Without those we couldn't really have everyone participate. We couldn't have everyone's ideas be treated fairly.

[00:15:35] The first one is outcome-based goals. This is really part of a pair. 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. If we're trying to achieve an outcome for the customer, that this customer problem is going to be solved, or that we are going to make this many more millions of money, that outcome is separate from the things that we're actually doing: the individual tasks, the individual projects, the features that we're building.

[00:16:16] Decoupling these two really helps, because then you can be creative. You know the constraints, and you know that what we're trying to do is really solve these customer problems; that is our goal. Then you can come up with initiatives, you can really solve the problem. You have constraints and you have a goal, and that really sparks the creativity in everyone. At Zalando we use objectives and key results, and I really prefer the Radical Focus one, 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's very good. If not, then please Google OKRs.

Process two: one-page initiatives

[00:17:01] The other half of the pair, the thing that's coupled with the objectives, is really what you are going to do, and in our case we worked with initiatives. They're really something in between. When you look at the different methodologies and principles, if you go to the most 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. 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. If you have a press release, which is a very fixed format, and you have to express in a press release format what you did for the customer, it's going to lock out a lot of the engineers, a lot of the analysts and data scientists who really want to come with their ideas but don't want to play with this format.

[00:18:04] On the other hand, you might have something like agile stories, where you just come up with who, what, and for what purpose. But if it's really a one-liner, then it's not something that you can prioritize, not something that you can argue over, and 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. The why part was the most important. You always had to either show some data that says why you're going to do something, or describe a clear customer problem that you're going to solve, or some other reason, a clear purpose for why you are doing this. After that you can come up with all the cool ideas. You can put all the machine learning in the house, as long as you did a really good why.

Process three: demo all the things

[00:18:57] And then the last process, demo all the things, is really related to the principles. If you want to have constraints that everyone is aware of, that everyone understands, "OK, these are the constraints that we're working under," that's not something that happens in one day. One day I came over, I told you what the constraints are, and now everyone knows them? No. 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, especially the communication of constraints and direction, and especially the analytics as well. Every time someone does customer research, every time someone really analyzes the data, 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.

[00:19:57] All right, 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, and 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, then descriptions of what you're going to do in a way where everyone can contribute, and sharing the knowledge inside the whole team, then you can really have an autonomous team that can make an impact and where everyone can contribute. That was it for me. Thank you for your attention.

Q&A

[00:21:01] Host: Thank you so much, a lot of good stuff there. Are there any questions?

[00:21:10] Audience: Yes, I have a question relating to the customer problem. Maybe it's due to the fact that the Beyoncé pants didn't appeal to me, as I haven't had this problem before, but I'm a little bit concerned about your definition of the customer problem. How do you make sure that it's actually a real problem? Because my feeling, from what I hear from you, is that the problem is really based on how the Zalando product is set up right now. It's not related to a problem of users. A problem for our users is easy shopping, or finding a way, like Outfittery in Germany, for example, which is doing pre-shopping: they send you stuff, you can try it out, and you don't need to do the shopping yourself. I see that as a clear customer problem, and I would like to hear your view on this. Could you challenge the problem that you're working on?

[00:22:00] Jori: Yes, sure. Maybe I'll skip back to the customer problem; it was right here in the beginning: "I wish I could shop in a way that's natural to me." This was the customer problem, and it was really driven by our navigation and browsing team. Originally, when they were building the category tree and giving options for customers to browse, they had a lot of challenges, because when you have a tree, it always has one parent and multiple children, and one parent and multiple children. There are a lot of things that go in it that are like a graph; it's not really a tree. I think that's the core challenge.

[00:22:45] We had the product data, which is really the hard attributes of the product, things like color and size, and then you had this categorization, which was very fixed and through one lens. So a lot of customers were landing in places where they were actually looking at a shirt because they really liked the rock and roll style. They were looking at that shirt because it looks like rock and roll to them, but there is nowhere on the site for rock and roll. You can't even search for rock and roll, and you couldn't search for events, and those were not present in the category either. So there are a lot of challenges to this part, and these were really things that we validated again and again with customers. We have a lot of interviews that we're doing consistently. We're tracking their behavior on the site, and this is also what we were looking at in the data: how deep do they go in the category tree? Do they go into the category and do an immediate search because they didn't find what they were looking for? Do they search for something which actually should be in the category? These kinds of things.

[00:23:48] I do appreciate that it's not a big problem for everyone. 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. You can't say that this shoe is a trend. Sometimes you can: I've learned things like embellished socks and oversized scarves, 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, "By knowing the product data, I know exactly what this style would be." Does that answer the question?

[00:24:39] Audience: Yeah. And just an example: Nokia had a team focused on how to optimize a keyboard, how to make it user-friendly, and when the iPhone came out, for them the customer problem was how to make it more intuitive.

[00:24:52] Host: Does anyone else have a question? No one? But I have one for you. You mentioned that you are basically picking one problem. 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 more things. So how is it working for you? How much time do you allocate? Is it one sprint?

[00:25:24] Jori: Yeah, that's a good point. In our case, the customer problem here is a really wide problem. If we look at the Zalando fashion store, we're talking about maybe ten or fifteen touchpoints or different parts of the site that all have their dedicated teams running those parts, and their customer problems are not nearly as clear as ours was. We had a very distinct customer problem and a very distinct technology that we were using to solve it, in knowledge graphs and ontologies. So this was a place where we had a technology that we were bringing into the company, and a clear customer problem that we were using to communicate that new capability.

[00:26:12] But also, when we go from here to what we're doing on a quarterly basis, we look at what we can achieve in one quarter, and quite often that's a new customer problem, a sub-problem. And still there were so many people who wanted us to have many, many different problems, both for the high-level one and on a quarterly basis, to have five or six different things, and I think that's always wrong. You always want to focus on one thing. It's hard to find exactly the appropriate size, but you can usually scope it in a way where it lands nicely in around a quarter, and you want to focus on that one thing. And if you have multiple teams, like maybe we had three teams, then every team had one sub-problem of that that they were solving. 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.