Aligning Team Objective Through The Strategic Value of Design

Soeren von Sebelin, Giacomo Gabrielli, Noemi Bellioni, Sowmya Guru, Emilie Lindström at UXDX Community: Berlin. Video: https://www.youtube.com/watch?v=c-p-QTtesYs

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.

Welcome to the UXDX living room

[00:00:00] Hi everyone. For the people that don't know me, my name is Noemi and I'm an Italian UX designer. I've been growing professionally in various startups in Berlin, and now I'm happily building a smooth experience for the users of SofaTutor, which is a German e-learning platform which helps children and young adults to learn beyond school. But this is just secondary, because tonight I'm only your host and all of you are my guests. I'm about to let you in to my big, but of course virtual, UXDX living room, situated tonight in Berlin and more precisely in Neukölln. So take your seat and be ready to enjoy the conversation that we'll be having around the talks that you have been watching during the day.

[00:00:49] The topic that we're going to dive deeper into tonight is the following: aligning team objectives through the strategic value of design. The title is actually huge, and it can be broken down into several concepts, phenomena, keywords that I'm sure are tickling your brain. Teams, alignment, objectives, strategy, design. I'm sure that you work with them on a daily basis, but why are we even speaking about them today? I think there are no manuals that can tell us precisely what to do for making our product team work at its best.

[00:01:35] The good thing about the UXDX community is that it can work as a vector for giving the possibility to people to share their successful experiences. For me there is no better way to learn rather than looking at practical experiences of the people who work tirelessly on making process better, and even finding their own ways. If you're here it means that you're curious and you also want to try out new things, and that's just great. Whenever you find some quotes which are enlightening, or approaches that you would like to try also for yourself, don't forget to share and also participate in our core value, with your team, with your network, online. And why not also use our hashtag, which is UXDX Community, for us to see that the seed that we planted has been growing together with your thoughts.

[00:02:43] I would like to make sure that the speakers are actually here, and of course I want, as a first thing, to thank them, because they brought very nice topics tonight, and also for the dedication that they put every day into changing the team's behaviors towards constant innovation. While you people in the living room are preparing for asking them questions, let me pass the mic. Emilie, do you want to start?

Meet the panel

[00:03:19] Emilie: Hi, yes, I can start. Hi everyone, thanks for joining us today. My name is Emilie. I saw my name was spelled with two hours[?], that was fun. Like a good thing, I liked it. I work at Outfittery as a senior product manager and I've been with the company for ever. Six years actually, so it's a long journey. I have not done product for that whole time, but for the last three and a half years I've been doing product management, and I focus mainly on the internal tool landscape that we have. I don't work customer facing, but that also means that everything customer facing goes through my tools to our stylists, so I need to be a part of the whole journey. That is also why I very much enjoy my workplace at the moment.

[00:04:12] Soeren: Okay, hi everyone, thanks for having me. My name is Soeren von Sebelin and I started my journey at Goodgame Studios quite some time ago. I started there as a producer and project manager, only to find in the end my inner nerd about productness. Since then I'm calling myself a product nerd, and I hardly find any other topics that I can be as nerdy about as I am about this one. I started working for a short time at 1&1 as a technical product manager, and shortly after that I started in beautiful Berlin at SofaTutor, and that's around two years ago now.

[00:05:06] Soeren: I was mainly responsible, with my team, for the navigation, and basically to get the users, which are pupils at SofaTutor — as you can imagine from the description from Noemi, they are mostly small kids. That was quite an interesting challenge, to figure out how to navigate kids to the content that they really want to see. I would pass the mic over to Sowmya Guru.

[00:05:40] Sowmya: Thank you. Hello everyone, my name is Sowmya and currently I'm working as a freelance Android engineer. Just recently I started, since more than a month. I have over a decade of IT experience, working in big companies and startups, and finally now I made the switch. I'm also the founder of Coder Bee, an inclusive network that teaches programming to women and minorities in IT. It started as a small group which spun out of another women's group, and now we are more than 400 members, and I'm quite happy to continue this journey along with my as usual Android engineering.

[00:06:25] Sowmya: Pair programming is one of my favorite topics, that's why I'm advocating this, and I also see this is a very uncommon topic in IT in Berlin at least. I also did some research around, and I found that it's not so common at all, which is why now I want to talk about it and tell people why it's fun to do pair programming. And maybe I can pass the mic to Giacomo.

[00:07:02] Giacomo: Yeah, no problem, thanks Sowmya. Okay, hi everybody. First of all, Noemi, thank you so much for having me, it's a pleasure to be here today, and greetings to all my fellow speakers and everybody who's connected today. I'm Giacomo, I am from Rome, this is where I'm talking to you from right now, and I'm a UI designer. I work for Accenture, which is the big consulting company, and I've been part of a team for a couple years now working on a design system for some of the company's apps.

[00:07:44] Giacomo: That's more or less the core of what I brought in with my speech today, talking about our approach to the project and the things that I learned while doing so. It was the first time for me working on a design system, so I learned a lot of stuff by doing it, and it was a bit of an eye opener from both the UX and UI point of view. So yeah, that'll be it.

Working with stakeholders after the move to product discovery

[00:08:11] Noemi: Nice. So now that you have all introduced yourself, I would say that I could already jump in with some questions. What do you think? All right. I have some questions for you that came to me spontaneously while watching your talks. Even though aligning teams is the core interest of the initiative that you've been pursuing, I can imagine that bringing these revolutionary approaches might have also caused a pushback reaction from the rest of the team, or maybe from your product stakeholders. So I wanted to investigate a bit more this aspect with each of you.

[00:08:58] Noemi: For example, Soeren, you mentioned that before the transition to product discovery, stakeholders were mapped to the teams. How do you work with stakeholders together now, after the discovery environment is in place?

[00:09:17] Soeren: That's a very good question. In the very beginning — just for everyone who probably didn't watch my video — I was talking about the team structure, and probably actually the transition from team responsibility, so more like components that you're responsible for, the transition to missions. And also we were responsible for several stakeholders. To the major question in the very beginning that you asked, the whole transition was actually perceived very positively in general from the stakeholders that we had. We were very open and we tried to tell them what it's all about.

[00:10:13] Soeren: But what did not change drastically was the way how, let's say, who was mapped to the teams. We still had — and I can mostly talk about my team in this case now — we had like three teams, and each team managed the stakeholders a little bit differently. In my team it was mostly two different cases. We had case number one, where we had different goals and the stakeholder needed us to achieve their goals, but they were not entirely our goals. We didn't manage to change that drastically, and that's a long process. In the last two years we didn't change something drastically there, but always kept the normal, the usual stakeholder and product team relationship.

[00:11:12] Soeren: We also had a second case, and that was, if you ask me, the winning case, where actually the stakeholders were very well aligned to our teams. That was super easy then, to integrate the stakeholders into the discovery process. We actually learned together, and we came to solutions together, we experimented together and learned together, basically how to solve those problems. That was definitely also the winning case, and I think also the way to go for the future.

Storytelling: what the team gets out of it

[00:11:56] Noemi: Nice, super nice. So now I have a question for Emilie, on the same line. What type of outputs does your team have now with your storytelling method? Did you get any pushbacks? How did you sell them on it? And who's the potential enemy of the hero of the story?

[00:12:24] Emilie: Where should we start? The benefits that have come out of this is that they do know the customers, the heroes, a lot better. They have an understanding, which makes the grooming sessions a lot smoother and things just run a little bit more easy. I think the biggest pushback comes from myself, because sometimes it's just super easy to be like, can you just do this, because you're stressed and you have too much to do. Because this is an investment of time and energy. If you want to tell stories you need time, and you need to make sure that you do it with effort.

[00:13:06] Emilie: As a general, nobody really had a pushback on it, not from my team, not stakeholders either. But I think also it's important as a product manager that you also are able to change your language for whom you're speaking to, and also are able to adapt what part of the story that you highlight for certain users. For example your developers might want to hear a lot about something else versus what part of the story you need to tell to your stakeholders, so you need to be able to adapt that as well. But for me it's been helpful, because the team knows the hero and it just makes it a lot easier to work, to move forward.

Design systems, exceptions and snowflakes

[00:13:45] Noemi: That's very interesting. Now I have a question for you, Giacomo. With a design system in place, or at least your process, how did stakeholders react when you were trying to stay consistent to a brand? But as we know, everybody has different needs on the design, so how did you handle requests for exceptions, for example?

[00:14:12] Giacomo: Okay, thanks for the question, that's an excellent question. In my case the stakeholders that I deal with are other product teams within the company that decide to adopt our design system to create their products that they'll sell to clients. That's sort of the workflow. In general, design systems are not a new thing, they've been around for some years, so it's not something so revolutionary at the moment that no one else knows what we're talking about. People are more or less aware of them, so they know that they have at their disposition a certain number of components and guidelines, and that they can use them in a certain way. That's what they expect when they start working on a project that uses a design system, which realistically can't work for everything. You have to consider the fact that there will probably be some exceptions.

[00:15:15] Giacomo: At the moment we're in a phase of the project where we're still sort of starting out, even though we've been working on it for a while. We've released it probably a couple of months ago, and just internally. So even though we have set up a documentation portal where people can go and gain knowledge about the contents of the library and how to use the components and how to build products with certain patterns and templates and so forth, we're still at a level at which me and my other teammates can directly follow the designers that are using the libraries.

[00:15:57] Giacomo: If someone comes to us and they're like, okay, I need something that I cannot find in the library, the first thing we do is we usually try to figure out if there is a way to meet that need without having to invent something new. We try to rethink with the designers about a certain functionality, and if it can be built in another way by using what we already have, because that would be obviously a win-win situation. If you use what you have at your disposition it just makes the work faster and easier and cheaper, especially.

[00:16:37] Giacomo: If that doesn't work, the next step is we try to figure out if the new need is something we can actually bring in to our design system. If it's something that has value and that we can add as an official component. It can be anything, it can be a component, a pattern, an icon, a style, whatever. There's different levels of building blocks in there. And if we finally reach the conclusion that it's something that we don't think would actually fit within the general structure of the design system, what we do is we treat it as a one-off component. I think the term that's used is usually snowflake, because it's something unique and it kind of stands on its own. In that case we just bounce it back to the product team that's building the project, so they deal with it as their own part of the project. It doesn't come in to the library.

[00:17:47] Giacomo: Other more established design systems have this kind of dichotomy between official components and community components. So there's going to be an official list of things in the library, and then all the people that use that library or that design system will create their own components, templates, patterns or whatnot, and those are known as community components, and anyone can use them. Eventually, if we consistently keep on growing with the project, that's probably a realistic outcome of the situation, but for now we're just kind of playing it by ear.

[00:18:35] Noemi: It's very interesting that out of exceptions you can actually create a sub design system.

[00:18:42] Giacomo: Yeah, it's kind of like a crowd-sourced design system, that would be the general idea. I think it's great when you get to that point where a lot of the things in the design system have actually been created by a third party. It means that it's working well and the people use it and they get involved.

What pair programming actually buys you

[00:19:09] Noemi: So hopefully, definitely. Thanks a lot, Giacomo. And now I have a question for Sowmya. Have you experienced any downside of the practice of pair programming? And how do you think this practice is enhancing the transparency on the development challenges with the rest of the product team?

[00:19:32] Sowmya: Yeah, I think I do cover in my talk that promoting this, or even asking people to implement this, is quite challenging already, mostly because of the certain myths that are involved around this pair programming concept. Because most of them, as they see two people working on the same thing rather than two people parallelly working on things, it feels like, oh, so you're halving the developer productivity. People think it's just half of the productivity and you're not using the full potential. But it's actually the opposite. One plus one is actually more than two, because you can complement each other. This is one of the challenges, to convince people or startups and clients to actually implement this and introduce this concept.

[00:20:29] Sowmya: When it's done right, according to certain techniques used correctly, then I think developers also embrace this. As I say, this is a skill that can be learned. Soft skills, I think, are completely undervalued and underestimated, and it's all about technical skills. But I place a lot of value in this, mostly because certain qualities, like asking for help, are already challenging for developers. The biggest time, or the time you spend being stuck, is way more if you're doing something alone. If you have somebody to fall back on, it's easy to navigate through problems by talking. Getting unstuck is the first thing that a pair programmer has to learn, to not be getting lost in the rabbit hole.

[00:21:27] Sowmya: That's why I think a pair works more effectively, even doing the simplest of the problems or the complex of problems. And that is the reason, because there is somebody constantly reviewing what somebody is writing. This is the reason that the code quality improves, and there'll be two steps of reviewing, that means it's pretty ironclad, I would say, as long as people know what they're doing. Like I said, asking for help is quite challenging for developers already, so you would see some pushback from developers to say, no, I want to work on my own, I need my productive focus time, kind of a thing. But actually two people focusing together is way more productive. That is my argument.

[00:22:18] Sowmya: The third thing is, basically developers, as long as they're willing and they learn the proper tools, then use the techniques correctly. Because two people can also be using these techniques wrongly and there could be conflicts. It's not easy to always pair with somebody, and that's why it's important to rotate pairs. Coming to how this could improve the productivity in the team or the effectiveness in a team, firstly it improves collective code ownership, which means there won't be one single person being a subject matter expert, or the superhero of the team who everybody goes to. So that knowledge silo is no more there, that means there's more equality in knowledge and understanding.

[00:23:15] Sowmya: Because you're pairing with a new person every day you get to know your colleagues, that means the team morale improves, because you're continuously interacting, speaking, and you have to work through problems together. Definitely it boosts — the biggest thing that I know developers who love this concept tell me is that it's more fun to do something. It's nice to play with people, it's more turning work into play. It's nice to solve a puzzle with somebody rather than doing it yourself. So that I think is the biggest benefit.

[00:24:00] Sowmya: But when it comes to investment, if you look at the other side of the coin and say, for startups or clients, why would they have to go with this, because it seems like it might be more expensive. Studies also show that this concept, once used properly, improves code quality hugely, up to 22 percent less defects and bugs. And sustainable — as you grow it has to be sustainable, otherwise there'll be technical debt which will cost you way more later. It's like building on top of broken stuff.

[00:24:46] Sowmya: So that's what I think. It improves the overall team quality, product quality, teamwork, communication, all these soft skills which are important. And you will learn through feedback loops, that means the team is in a very healthy condition. You will face friction and conflicts, but that's why there are feedback loops, to actually overcome these. And because you have to do this continuously, you're already mentally prepared to actually solve these problems.

Driver, navigator and the mini retro

[00:25:23] Noemi: That's a very interesting topic, and also the audience has many questions about this, so if you don't mind I will already address to you one question that came. Do you enforce strict driver-navigator and timing, or do people do what they think is best while pair programming?

[00:25:45] Sowmya: Yeah, the second one. I think, honestly, nobody does so much research until they actually think this is important or fun, or you have to give a special importance to this topic. That's when you have to see how good it is to actually learn what are the techniques that could be used on an everyday basis. But mostly people don't know, because it feels like, oh, two people should just naturally come together and start writing code. But no, that doesn't happen. There's so much going on, you're making decisions, and there's some pride attached to it, saying, I want to be — you are showing somebody how much you know about the topic, basically that's your core expertise that lies on. So that is a bit harder.

[00:26:43] Sowmya: That's why I think basically you have to keep changing, rotating pairs, also for the same reason, like navigator and driver has to keep rotating, so you don't do certain things like keyboard hogging. Some people keep using the keyboard three hours a day or four hours a day without changing. People feel like, oh, I'm writing something, that means I'm programming, otherwise it's not. But programming requires both strategic and tactical modes. That's why it's important to continuously do this time management.

[00:27:20] Sowmya: Also, like I said, mini retros is another thing, if people do not use this. This is what I stress on also in my talk, that this is something I also never knew, that a mini retro at the end of the session is crucial for pair development. It's called pair development, that means you talk about what went well and what went wrong in just the last five minutes, and you also give each other compliments about some impressive things somebody suggested or did. I think these things are a bit missing. I feel like, because I've paired with a lot of people, I know that we could have done better.

[00:28:03] Sowmya: Another thing was, somebody like a senior developer, it's really hard, if they don't want to pair with somebody and just write code, you can't really — when you're mid-level or junior you can't force people to do something that they don't want to. But by perseverance and showing people — it's all about psychological safety, I think. Showing people that you're nice and you appreciate them is crucial in pair programming, because these are important qualities, I think.

Pairing beyond code: the opportunity tree

[00:28:38] Noemi: Yeah, it's super interesting, and personally I'm very interested in this topic. I would also like to ask the other panelists if you actually do pairing work, or pair programming, with the rest of your team, if it's a good practice, and you can also put a word into it.

[00:29:03] Soeren: I could probably start. It's always difficult with questions for everyone. I'm just thinking of, for example — I was actually with you, Noemi. I think one of the biggest successes of pair, I don't know, pair working or something, that we've had in the discovery process for SofaTutor and our team, was actually as we kickstarted something like the opportunity tree, where we basically were standing together for hours discussing and going through data. That was something that I also always valued a lot, and I think the output in the end was amazing.

[00:29:52] Soeren: We actually even had the perfect comparison. I think around half a year later I did it all by myself, and then Noemi looked at it and you kind of did it all by yourself as well. Then we merged it and we realized, okay, the result was far from where we could have been if we just sat together and did it together. So that was probably something that I can relate to.

[00:30:21] Noemi: I don't know about the rest of the crew, but can you explain maybe to the rest of the crew what an opportunity tree is, and why do you think that it's a good practice to be done by a UX designer and a product owner?

[00:30:37] Soeren: Yeah, sure. The opportunity tree is basically something that is helping the team to align its actions according to a wanted outcome, a desired outcome. It's like a normal tree, like a decision tree, where you start with the root, which is the desired outcome, and then you start in the next level with the opportunities, things that you could — opportunities that you can take to basically reach that desired outcome. And then there is a next level where you already start thinking about ideas and solutions, and after those solutions, the next level is thinking about experiments to iterate over.

[00:31:21] Soeren: What we did, Noemi and I, as a team basically in this case, we paired together over actually only the opportunity part. We had the desired outcome, that was clear, that was given from the management, that was the mission that we had. And then we had so many insights and so much data that you're always biased when you're going through this data yourself, so it's always good to go together through this and find the core essence of it, and figure out together what type of opportunities do you really have and can you really grasp. Because if you do it all by yourself you're always biased and you're always going in one specific direction.

[00:32:11] Soeren: What happened is that we had a big variety of good opportunities, and it was based on good data and good insights. And the team alignment afterwards — we talked with the team about it, and all together we decided on I think one branch of this opportunity tree to focus on, and it was a big success. So that was, in my opinion, really, really cool.

Nobody should work alone

[00:32:37] Noemi: I can only agree with that. It has been also my favorite collaboration and pairing. Not programming, but designing, let's say, designing the product. Emilie, do you have a sparring partner that you are pairing with and that you like to work with, and is it mostly the fruitful collaboration that you always prefer?

[00:33:04] Emilie: I mean, I think that nobody should work alone, ever. You get tunnel vision and you don't know what you're doing. I love when my team pair up by themselves, I don't even have to tell them to. And I also very much enjoy when I have back-end and front-end developers actually sitting down and really digging into problems and trying to find solutions together. In the world of product, I couldn't do my job without my other product managers, or having discussions with my team, or anything. My job is to get the best out of everybody else. I would love only pair programming, but that's not really possible. I think that's something that everybody should encourage as much as they possibly can.

[00:34:00] Emilie: But I get also the hard times with it, where it's time consuming and all of these myths around it, so it's difficult. And then also sometimes it's not actually efficient, because it's just like, I just need to do this. But then we also try to do, if we don't have time for pair programming, we always try to do knowledge sessions. And also if we have spike tickets we try to share them properly within the teams when we have time. And also, as I mentioned, having these kickoff meetings when you have new initiatives or new things that you would like to do, these are also brilliant times when you can get so much new information out. No man is an island.

Making sure a design system actually gets used

[00:34:44] Noemi: That's really true. All right, now we shift our attention a little back to design systems, because we have a question from the audience for Giacomo, and that's the following. Design systems are getting some bad press for being a huge investment that gets ignored in the end. How do you ensure that your design systems are being used in your organization?

[00:35:10] Giacomo: Okay, that's an excellent question, thanks. Well, I can talk from my specific experience. This is my first time working on a design system, so I can't really dive into what other companies are doing. But in my case, what we're building is meant to be used by products built with a specific business platform within the company. So once it's done and it's out there, we are 100 percent sure that things that are being built with that platform will use the design system.

[00:35:51] Giacomo: In general though, I get the point that this question is making, because building a design system is in fact a huge investment. It takes a lot of time, it's a really, really big process and it could take many, many months, so it's expensive. But the ultimate goal is to make sure that the things that you're pulling out, that are made with it, are consistent. You're making a series of products that follow certain guidelines and that are consistent with what the company wants to tell, basically. And also that they're quicker to make, because you're striving for consistency and you're striving for a faster workflow, because you don't have to reinvent the wheel every time you're creating something new. You have at your disposition something ready made, ready to go, with certain structural patterns that you would have to invent from zero if not.

[00:37:01] Giacomo: I understand that what you asked me before about exceptions, that is a big turn off sometimes, because people feel kind of like they're caged when they have to use a design system. I understand that it kind of limits the creative freedom, if we can call it like that, if it's approached like a limitation. But I think that it's important to bring everyone on board to the fact that it's not a limitation, it's actually a tool that can really help you. Because, as I said, you don't have to reinvent everything from zero, you have stuff at your disposition, but also you can build on it and just scale it up and scale it up as much as possible. I think that's sort of the message that should be sent out there when trying to get people involved and trying to get people to use a UI library or design kit or design system in general.

[00:38:13] Giacomo: Within my company, it's a huge company, and there's so many branches and platforms and different tools that are used, and I see there's so many different visual languages used on all of these different internal tools. I think that eventually, being able to have one single source of truth for all the things that are used within a company is just a very, very powerful way of telling your story and of communicating something. But it takes time, especially if a company is big and there's a lot of different teams and groups within it.

Design systems from a developer's point of view

[00:39:03] Noemi: So yeah, from my perspective, I can tell you that all the time that I joined a company which already had a design system in place, it took me like one second to understand how to actually enter into their mindset and design for the product. So I fully agree with what you said. And now I'm curious to know from a developer perspective, Sowmya, do you work, or have you ever worked, with a design system, and what do you think, from your perspective, this can be as a tool for team alignment?

[00:39:43] Sowmya: So, design system — particularly what do you mean? I don't understand this term of design system in the developer perspective.

[00:40:02] Giacomo: When you have a design system in place you have design assets and you have code assets. So everything you design, you know 100 percent for sure that it is backed by code. It just makes the handoff phase much easier for both the visual designers that are working on a project and the developers that are working on it. For example, in our case, the design team works very closely with the development team, because everything that we put out has to be approved by them, it has to be built by them as well.

[00:40:45] Sowmya: So yeah, now I know that. And I forgot your question, sorry.

[00:40:53] Noemi: I wanted to ask you if you ever worked with a design system, and how it is for you as a developer, and a help for team alignment.

[00:41:05] Sowmya: Yeah, I mean it's a regular thing that developers have to work with designers all the time, and they put out certain — there's different kinds of design schemes or frameworks. For instance, when it comes to Android, now okay, Material Design is quite common for all the platforms, I think. But still, not every platform has frameworks which would support this. Even Android is supporting this only a couple of versions before. Basically it has to be backed up by also your whole framework. That's why we undergo a lot of version changes and we have to interact with designers so closely, I think.

[00:41:53] Sowmya: Mostly because, like how Giacomo was saying before, we don't want to reinvent the wheel and start building something from scratch which we know is not a regular design pattern. Because if the pattern is not there, that means that it should not be used. Rather than building that, you have to tell the designer that this is not a standard pattern, and tell them that we have another, probably something similar. What I do usually is I show — because I use my Android device as well, I see patterns — and I give them a screenshot of some other app.

[00:42:38] Sowmya: Basically I think it's possible that a designer's perspective is quite creative, but we need to fit that with a development perspective, and easiest is the topmost important, because making a little thing which is not default could be costing a lot if it's not told before. That's why communication becomes very important throughout the team, being aligned, keeping product managers in line as to, to build this it will take so many hours, or to build a native component using something would be way easier and simpler, because you don't have to redo a lot of work which the framework does for you.

[00:43:28] Sowmya: So it's all about communication again, how well you can communicate with designers. But sometimes it's hard, it's like a sweet spot I think, because sometimes you have to also give designers the power to be creative, but also you should make sure that you don't spend so much energy on something that's not providing too much value. Basically that's why we also have product to align us, if we have conflict with time or energy efforts. So yeah, I think it's always good to have, like in sprint planning, all this sorted out, or even beforehand. I like that you can iterate over this way before with designers, and then you can always figure out.

[00:44:18] Noemi: Yeah, it's cool to consider also the design system a UI agreement between the look and feel of the platform from the designer perspective, and then agreed with developers on how it should function and look on a platform.

[00:44:35] Sowmya: Developers always make sure that your head stays on your shoulders, you know, just don't fly too high.

Strategy: narrowing the focus

[00:44:45] Noemi: That's true, sometimes we also need some small limitations to our broad creativity. So I have one small little question for whoever wants to answer it, and the topic is strategy, because I think strategy plays a big role in all the initiatives that you're bringing to our knowledge today. How do you think storytelling, product discovery, putting in place a design system and enhancing programmer collaboration can help narrowing the focus of the product strategy?

[00:45:25] Noemi: Who wants to answer this question? Emilie, do you have an idea of how to — patiently waiting for someone else to answer it.

[00:45:41] Emilie: No, no, no. From a storytelling perspective you will be able to align a lot easier on the strategy, yes. If you have the story that you want to tell, essentially the story could be even the mission of the whole company, and then it's very easy to break it down into the pieces you want to do. I am not sure that I would start with the storytelling part. I think I would start in another for coming up with a complete product strategy. I would probably talk about the hero, the customer, from the beginning, and then break it down from that point, rather than the whole complexity of the story we want to tell as a company.

[00:46:31] Emilie: I'm not sure that answers the question, but it's applicable. Strategy is super difficult, it's really difficult too, from everybody I've heard, the different companies, different strategies. It's difficult because it's about aligning. And from the truth that none of us are the heroes of the stories, this is then difficult for people to also accept, because everybody wants to be the hero rather than actually seeing the customer in that light. So I think the job that we can do, regardless if we're a designer or a developer or we're a product manager, I think what we do is that we help out to align with bringing the customer in focus and always bringing him back. That's what I think we can do.

[00:47:21] Soeren: I can also jump in there. Especially you, Emilie, you even had in your talk, and also now in your question again, what you also said is something that even I referred to in my talk as well, which is basically talking about the why. You call it just differently, we call it discovery lab and you call it differently. I think that's actually, if you ask me, probably even what I see as the core reference of what the team and what the product team basically does as product discovery: constantly talking about the why. And when you talk about the why you automatically ask yourself, okay, is this going into the right direction? Because if the answer is somehow awkward, or it doesn't feel like it's going into the right direction, you're not going to do it.

[00:48:10] Soeren: That's why I believe — because Noemi also asked about product discovery — I think actually product discovery, especially in terms of the product teamwork, this is the exact task, let's say. You've got to figure out, when you have a strategy, when you have a mission or a vision, or however you want to call it, are we running into the right direction? And everything that we apply to product discovery, is it the reporting process, is it how you make your grooming meetings, in which direction is the management talking about strategy or visions, and how, and who is talking about it in which area. It's all about getting this aligned onto the strategy and figuring out the right thing to do, basically, for our customers and not for ourselves. Which, I've got to say, yes, Emilie, you're so right about this.

[00:49:16] Soeren: If I would want to pin it down, obviously one major important part of product discovery is to actually have a strategy. Without it it's pretty hard to do it, and you're probably going the wrong direction and you don't even know about it. But when you have one, that's your major goal, on whatever hierarchy level or abstraction level it is. When you have a strategy, that's your thing to do.

Closing

[00:49:52] Noemi: Yeah, I think you really nailed my point on the strategic value of all the innovation that you want to bring to the table with your initiatives, so thank you very much. I would say that we are really close to the end of the session for today, and before we go I would like to take a minute to look inside of ourselves, and also at our teams, and think for a minute about one thing: what can be the main takeaway for today, something that we can walk away with after our discussion.