User Experience in B2B: Building a product in the retail industry for today’s consumers - with Henning Witzel @NewStore

Welcome everyone to another episode of the Product Bakery Podcast. My name is Alex. I'm here again with my co-host Christian. Hey Alex, good to see you. We have Henning sitting here. Christian, you know Henning a little bit better, so I leave it up to you to introduce him to the round. Yeah, thank you Alex. I'm super happy to have our guest Henning Witzel here today. Henning is a product designer at a company called New Store. And a pretty fun fact about the company and Henning is that I used to work at New Store as well for two years in the same team with Henning. Henning and I were actually like a kind of a pair of twins. So it's some sort of like a revival. It's a revival, exactly. And I had actually very great experiences with Henning working as a product manager. But before we dive too deep into this, I think Henning can maybe quickly introduce himself and tell us what New Store actually is and does. Hi guys, I'm Henning. Thank you Christian for this nice introduction. So as I said, my name is Henning. I'm a product designer. Actually, I'm the head of product design at New Store. I studied computer science. That's the way I got into software development. And while I was doing that, I got quite bored and I started to find some other students and we basically founded a company, an agency, where I built and designed products. And it was pretty cool. And at that time, I didn't know I can design. So some of my friends showed me how to use Photoshop. And I was like, wow, that's the tool I always needed to express, you know, my ideas I have in my head. And from that point on, we had a couple of clients and one of these clients became a company called New Store. And the original CEO from the former company asked me to join this as a product designer. And I was like, okay, I've never been a product designer. We had a company, we served our clients, I studied computer science, I was a developer, I did web design, all this kind of stuff. And I was like, okay, let's give it a try. And I moved to Berlin. And this was like five years ago in 2015. And since then, I'm still with New Store. And I'm happy to be there and still working and still push our product further. You asked me what New Store does, right? Exactly. The general mission of us is to bring joy back to retail. And to explain you this a little bit further, I have to give an example. Imagine you have a product you want to sell. What you do nowadays usually is to, you know, bring up a website, the eCommerce system, and start to sell it through your website. At some point, this product gets very successful, and you want to open stores. So you have stores and a website. And it's the same kind of customer, right? They're browsing your website, and at some point, they're entering your store. Now go back in history and think about all these retailers out there, where they at some point started to bring up eCommerce systems. And since then, it's almost like the retailers with their stores internally against the eCommerce systems. And they do not work together very well. It's also because of the systems, they are not designed to work together. So New Store started with the attempt to build an omnichannel platform. And omnichannel is kind of a buzzword nowadays. Boom! But I recently heard a nice definition. It allows the retailer to say yes. The customer walks into the store and wants to return something, you can say yes, because you know, I have your online order, I can find that. The customer bought it in another store in another country, this shouldn't be a problem. And we walk in, they know you. If you buy something online, and an associate is looking you up, they can see that, and so forth. So that's all related to omnichannel. And New Store is basically empowering brands to do that. And connecting their existing systems, some of them like an eCommerce system, like Shopify or Salesforce Commerce Cloud, with our order management system, or mobile point of sale, the associate app, and store fulfillment. So you're pretty much like combining, or you started to combine the physical word with the digital word and kind of having everything like running into the same system. And also, I mean, it sounds like making more sense of like the whole customer data across like all the channels. Exactly. It's all about customer data. But in a sense, on a creepy way, you know, it's about meaningful and useful data. If you walk into an Apple store, you have this feeling of, oh, man, they should know that I have an iPhone, right? And that I have an Apple watch, and I want to feel like valued in a certain way. And so far, this was more in the luxury sector, like really high end retailers. But this is not reality anymore. If you go to a brand like Bose, or Allbirds is a company that also sell these wool shoes. If you walk in there with Allbirds on your feet, I mean, you want to get recognized and then start a conversation. So it's really like feeling like being a customer. So, I mean, not sure if you can like openly talk about it, but who are the clients of Are we talking like about the smaller kind of stores or bigger chains? Who are you actually serving? So five years ago, we started to focus on the luxury retail. And we thought this is a pretty good idea. And we little bit underestimated the complexity of it. And also how many features they were already expecting. So when you are a startup, and you want to build something innovative and breaking, it changes the experience. You don't want to build the old stuff, right? So imagine we kicked off with a customer where we had a cash button in the app. But there's no proper cash handling. We didn't talk to cash draws. We don't need that, right? Everybody pays with credit card. But then the more you go up market, the more customers you want to have, the more you require these mandatory. We used to call them the... Christian, help me out here. We called them the... What was it again? It's kind of like the mandatory features. But this is like there was a special word for this. I think must-haves, from what I remember. Table stakes. The table stakes. Yes, you're right. So like the no brainers, you need a proper cash handling. Okay, got that. You need to be able to process a return. Okay, got that. Operate on discount level. Okay. Okay, then we build discounts. So, you know, you go from one to another, and then you need to be aware of the rabbit holes, of course. But I can definitely talk about the customers we have right now. So one of them is Decathlon. If you know them, we have their business in the US. And they opened with us one of their huge stores with like 50,000 square meters. They have up to 80,000 SKUs in the system. So for us, this was a lot to handle for our product catalog. Then we have smaller ones, like Untucked or Outdoor Voices. And Untucked is pretty successful because they have more than 80 stores now. And this is a brand that grows with us. It's like a startup that started, I'm not sure, like 2013 or something. And they were like, pretty successful with their eCommerce business. And then they went into stores. And then they use Shopify. And to a certain point, they wanted more. And Shopify was basically on their limit to what they can offer. So then they were looking for another system. And then you go up market pretty quick. And the systems are super expensive. Like it costs you millions to integrate. And it almost feels like it takes forever. So they have a pretty big investment up front. And that's what they were looking for, a solution like new store. Exactly. So Decathlon, Untucked, Outdoor Voices, Anine Bing. It's also a retailer you can find in Berlin. And recently, we launched Burton Snowboards. So we're pretty much into the sports sector. And the reason why, which is something I also learned, is that the sporting retailers, they are innovative. They want to move forward. They're not holding back. So they are as innovative as we are. And that's why they keep looking for solutions. To summarize, what you're saying actually, is that you're working in the B2B enterprise area, as far as I understood, with a touchpoint to the consumer or to the end customers. So we're talking about B2B2C. I'm interested in getting a kind of deeper insight from you on your daily life as head of design. Maybe you can talk a little bit about your current projects, your challenges, and especially how you look at things in terms of product development in such a kind of format, B2B enterprise with touchpoints to customers. Yeah, there's a lot of questions. I think you have to repeat some of them. So how does my day look like? So when I wake up in the morning, I grab a cup of coffee. And then for eight hours, I'm sitting in front of my computer, and then I'm closing it. The story of our lives as well. I guess, yeah, we all can feel you there. Exactly. I go to the toilet in between, I have to say, but it looks like you are more hardcore on that. Yes. Wow. Actually, it's pretty much true that we sit almost the whole day in front of our computers nowadays. You have to force yourself to get out. It's important. Do that. Well, no, we basically, I have the product design team. We work as a unit inside Newstore and helping other engineering teams to deliver an experience that we are looking for. We constantly do user research. So we basically talking to our users as well as the choosers, which is something in the B2B sector that's very important. What is that? What is the chooser? The choosers are the people that actually look for a new solution inside the brand. They look for something, a tool that helps them to get that job done in a better way. And then they find a solution like Newstore. And then they're evaluating this and then they pay the money. And in the B2B business, it's important to have a good relationship with someone who pays you the money. And then we have actually the users, in our case, store associates, for example, that work at the brand and they come in in the morning and they get a product in their hands and say, this is your point of sale, use it. And so we have to carefully put our, when we build new features or if we talk about certain experience to address always the right stakeholder in this case. So this is really important for us also on day to day business. I mean, it's already very interesting. You touched already the user research and the empowerment of other engineering teams. Maybe we can dive a little bit deeper into user research, especially in B2B. I don't think you can just grab a couple of customers to talk to or randomly choose. So how is that kind of process happening in general? And how are you just starting and driving it? Let's start with the problem here. That's what user experience people do. Well, you can skip it. That's my biggest issue with it. So you can easily go ahead without doing any kind of user research or design research, which often leads to products that are, you know, unusable. Think about the TV remote you have and how many buttons on this remote is, how many of them you're actually using. And at the same time, you can easily end up in an experience rot. So you have tons of features that nobody's actually able to figure out how to use them or you need like two weeks training to be able to use that software. How do we drive user experience then? We have different mechanisms for different problems. Sometimes we have problems that are pretty much, we are pretty much aware of them. So little things we have to do, our customers talk to us directly. We have regular calls with people from our retail success team. So those are like separate managers that talk to individual clients. They give us direct feedback. So if we launch a new feature and it doesn't work properly, we get that pretty quick and pretty soon. If nobody's complaining, that's also sometimes not a good sign because you could say, well, somebody's not using it or they're happy using it. So we pretty much get both. One thing I recently heard from Burton Associates was that they don't feel like a grandma anymore because they had to use all these old systems and now they have an iPhone in their hand and they can pretty much do everything with the iPhone in the store. So they don't have to leave the customer or you don't have to wait in line on a checkout cash register. This doesn't exist. We pretty much allow them to set up the stores like Apple stores. You can arrange everything how you want it and you don't see any kind of technology. So it's a pretty cool experience. Since 2010, people want to be like the Apple store since the first one launched. So the retailers, they really want that. So how do we do this? There are a couple of things we tried in the past. Once I worked as a store associate, that was pretty interesting. So I went to Decathlon in San Francisco and I put up the blue suit and then I take the associate app, which is our mobile point of sale, mobile point of sale. I hope it's not a pain of sale, because that would speak against a good user experience. I think just to remind you, we're not cutting anything out here. I think I want to use that in a presentation. And I worked for a day as a store associate, eight hours. And this was the first moment in my life where I felt like, wow, the pressure is really high if the customer is in front of you and there's a loading spinner in the app and it doesn't tell you anything or it loads forever. And you're like, okay, that's pretty interesting. Another example, which I told you in the beginning, we were like trying to get around cash. And Decathlon was an awesome customer for us. They also didn't want to use cash. They actually had a machine where you can put in cash and it gives you a gift card. And then we were scanning the gift card to actually take the money in. They did not want to deal with all this cash, because think about it. If you take cash, someone has to go to the bank, you have to store it securely. So there are a lot of things involved in this process that you need to know of. We have to pay fees for the pain as well these days. Which is actually also something, and I mean, probably some of our listeners know it, but we worked at SumUp, right? And this was one thing that especially small merchants don't really understand, the cost of cash. That's crazy, right? Because people see it. Oh yeah, it's free. I don't have to pay this fee on every transaction. But there is actually, as you say, and then there is the factor of something can be wrong arrests, wrong amounts, like people lose money. It's crazy. You give out the wrong change and stuff like that. And there are all these regulations. You have to report on cash and you have to do these daily openings and daily closings and have to count everything. And honestly, to also reference to Corona these days, you have to touch it. You have to take the money. You have to count it. In a certain way, it's good that modern payment methods keep up coming and ramping up and we don't have to talk about this anymore. But there are still countries for us, which is also a challenge if you want to expand more internationally, that you have to keep up with their requirements and also their user experience. I mean, we are in Germany, right? So in Germany, it's normal to take cash. People still expect this more than credit cards or anything else. Even in Berlin, especially, you still have a lot of shops. And one funny story about Corona, I've been to a bar and there was a sign, the official one from the government, with all the things that are important for Corona. And the very last one is like credit cards, right? They just did a strikethrough and said, we fulfill everything here, but we don't take credit cards. We still take cash. And my story around cash was actually that in the application, we had a button called cash payment. And I was next to the customer and we do the checkout and then I say, okay, you want to pay with credit card? They said, no, I want to pay with cash. And I was like, we don't take cash. And then she was saying, but there's a button, there's a button called cash. And I was like, yeah, I know, but I don't want to take cash. And then I had to discuss with the customer. And I was an associate for a day, so this was unusual to me. I was like, wow, we have to be careful with the user interfaces here, because it's not only the associate looking at this, it's also the customer. And that's an experience that we didn't think about before in terms of user experience. We were always like, okay, the associate is looking at that app and is using it. And if you've ever been to an Apple store, you can see how carefully associates at some point not showing you the app and they're doing everything. Our associates, they do it the other way around. They're doing it with the customer. It's very open. So for me, this is important in the design. So that think about some KPIs you don't want to expose just like that, like you should not have a dashboard that just opens and tells you like, this is how much the store made today. And you're like, no, no, no. This should be a little bit more hidden. Yeah. As well as when you, let's say you open a customer profile and you've been, you know, not the best customer. You're always like returning stuff and this is usually broken. And there's like some notes from customer service, like he complains a lot. It's like, this is something that we need to make them aware of in the design. So for us in user experience, this is super important to incorporate this. How do you handle then these kinds of situations in the design process itself? So you said you were quite confused and stressed when you realized there is a loading button that doesn't tell you why. What were your takeaways? How did you manage to tackle this kind of problem in the team? And how did you put this into your design process? We basically went back to the engineers and tell them, this is all shit and you have to fix it. Sorry, my language. You have to beep that out. No, that's not happening. In my example, there was actually an engineer with me because I was looking for an engineer working in our mobile app. I was like, you want to get some customer, like real life experience? And he worked with me. So he experienced the same kind of issues. We went back to the teams and we basically tell them firsthand stories. And by the storytelling, giving them concrete examples, not these, you know, user stories, right? I want to, and sometimes it feels so artificial or it feels like, did somebody made that up? Some product manager just like, I need a user story here, so I'm just writing it. Nowadays we have stories that favor concrete examples. Like you can read it, like we went to the store and we experienced this. And then we have systems in place to actually validate this with quantitative data to say, well, let's see, we have many issues coming in here. So this is not happening once, it's happening every second day. And this is how we translate our experiences and what we saw back to the engineering teams and the product teams. you also mentioned like systems for the quantitative data and you brought it also up earlier, right? Like not getting feedback can be good or positive because it could also mean that people are not using it. So like in line with all this tracking and behavioral tracking live in the app, things that you cannot observe, how are you going about this one? I like to do it. I saw really good examples of other companies doing this and learning from this. We are in the process of setting something up in a better trackable way. So in the beginning we keep using Firebase and for our web app like Google Analytics. Sometimes you sit in front of these and like, I don't know what this means. And I heard recently about some tools that allow you like session replays. So I'm actually currently in the process of looking into tools like this to find some mechanisms to replay sessions. What is the real problem behind not understanding what Google Analytics and other tools are showing you? Is it the fact that the data are not deep enough for you or are not well explained and defined in terms of events? So what are you struggling with? I'm struggling missing the circumstance the user was in, like the environment and what situation. If you track in a B2C and you have some specific funnels about checkouts, that's all fine, right? You have a certain goal. But I don't have the goal for an associate to have a checkout funnel. If they stop in the middle of a transaction, maybe it was fine because the customer said, I don't want it. I'll walk out the door. So for me, it's important to understand why did the customer walk out? Was it something related to the technology? Was something wrong with our system? Because we had situations. It just took too long and associates had to cover the situation. You want a drink? I will take a while to get your return in, which was designed to be quick and fast. But there was a circumstance we didn't expect, which still is like we haven't solved it fully. But when a customer wants to return something and they bought it at different times, so it's not one order they want to return, it's five. We can return one order by another. But if you bring me five products, it's always a different order. I have to go into every each of the orders and initiate the return, pick up the right product and so forth. This was time consuming. I did not know that. So then we're like, okay, how often does it happen? And in this case, you don't get quantitative data so easily. So what we do then is we talk to our retail experts that keep talking to our customers. And they can give us a good feeling about how often it happens. But ultimately, if you really want to know it, you talk to the people, you talk to the users. How is New Store structured? Because you're talking about retail experts, you're talking to the customer, there's a support team. So how's the flow to get feedback into the product team? So we have a product team, which consists of a couple of product designers, user experience designers and a bunch of product managers. We have different engineering teams, some of them taking care about inventory, some of them taking care about customer and catalog. Then we have a team called professional services. They do the implementation. So when a burden comes to us and says, we want to use your product, someone has to integrate that into their current systems, get their historical orders in. Something we also a little bit underestimated in the beginning, how much of historical data you actually have to have. If you walk in from something you bought one and a half years ago, so still in some kind of return period, oh well, we don't have the order. That's nothing you want to say, right? As I said in the beginning, we want to allow them to say yes. So we built a historical order import. Then we have a team called retail success, and they pretty much take care of our customers. They have weekly calls, they talk to them, they give them onboarding and training. So even though we aim to have usable apps that are super understandable, there are processes you just need a little bit explanation. And therefore we do some nice cool videos using our app. And we have people taking care of this. You know, whenever I want to know something about, let's say, a burden, I just talk to our retail success manager, Rachel, and she tells me all about it. And I think next to support, of course, we have a people team, take care about the people at New Soar and help with the hiring process. And as design team specifically, like the user experience designers, how are they structured within the organization? Because you also mentioned you support like different teams. Are you working cross-functional designers sitting with the team throughout the whole development cycle? Or are you more like kind of working also from an in-house agency perspective of really supporting all different development teams? I love that you ask. I feel like we did pretty much everything until up to this point. Everything works. Yes. So we are a design as a service. We have three designers serving like 70 to 80 engineers and 11 different engineering teams. And we, up until recently, worked app-based so that we had designers taking care of the associate app. Another designer took care about the inventory application we have. And the next one about our omnichannel manager experience. I changed that because it didn't really work. Created some silos. This person is not there. Nobody can take over. You can't help each other. So we changed a little bit the way we work. And we work more in collaboration and sharing topics. So if it's a topic where we don't know much, we do a lot of research upfront as a team. There are still people leading topics. When it comes to development, you are a dedicated designer in the team. So for example, we're currently improving our store fulfillment. And one of my designers is directly working with the inventory team. From the initial brainstorming to do some designs, you exchange them with the engineering team to make sure they're feasible with the product managers. And then you're part of the sprints. And you work with some deliverables they need and also for the rollout process. But you also have other topics to deal with. We have to investigate something in terms of product discovery, because that's something that is super important. You should not underestimate how much time you can put in product discovery, because that's the point where you can fail and it's not so expensive. Because if you fail after you developed it, well, that's something you should really consider. So I'm basically having to split my time between concrete deliverables. So when an engineer asks you, hey, can you check the story because we want to see the UI? Okay, let's look at it. And then all of a sudden you turn around and you ask users about, so what were you trying to achieve? What's your goal here? It's pretty much very flexible. I have a pressing question actually regarding your transition from app-based design process to a more functional one. How do you make such a kind of transition? The reason I'm asking is I'm consulting two companies that have a design team. The engineering organization is going away from domain teams rather to cross-functional teams. And the idea or the plan is also to adjust the product teams to this kind of new setup. And they realized, okay, it's maybe better to let the designers more collaborate with the engineers. How do you empower the designers to be able to go away from their application that they owned to a way to work more on functions across multiple applications? In terms of the design team, since I was running it, I was pretty much figuring out by myself that the way we do it, it doesn't work. We had some examples where the designer wasn't felt comfortable in the team. And I and my other designer, we couldn't help. We're not in the details here, so we pretty much have to deal with it. And this didn't feel right. And I got really inspired because NuSo made a couple of changes in the past with new SVP engineering. And I saw that they pretty much start doing changes. If you work so long in a company, you feel like things are set in stone, right? We always started like this. And we never like, actually, just be the change you want to see. And that's what I did. I had this moment where I was walking in one day into our very empty Corona office. So we reopened our office, and we have some few people still coming in. And I still enjoy spending a day in another place, except my home. And I was like, I need to change that. And I got my designers in and brought up a proposal and said, we should stop worrying about others and should take care about ourselves. And the way we want to move forward. And I told them pretty much like, we're not hiring more designers here. We need to make this work. And as an engineering organization, they're actually happy if you help them, if they really see a benefit. If you just give them designs at the very end, they don't see any kind of benefit. So we try to make it work. Pilots are a good idea, like smaller projects where you see the impact of having a designer with your team. How about a design system, for example? That's something I always wanted to have. It's always like no time, or you do something else instead of the design system. I think it could help. I have many engineers asking us for this. So when do we start doing the design system? I'm like, yeah, when we get to it. And I don't know, I have a very mixed relationship with design systems. I think it really helps you to get things out the door quickly. Easy things, 80% of the stuff you can solve for the design system. But then there are these 20% of problems that are really hard to figure out. And maybe it needs special user interfaces that are not as custom as they are or, you know, sometimes you want to put something more special, but it can help you to speed up especially the development process because you have to worry less about the designs. You can give them a wireframe, they just pick the right design elements out of the system and it works quicker, let's say that way. The one thing I'm wondering is like with an engineering team of like something like 70 engineers, I assume there's a lot of stuff going on and I assume like there's also like quite some different requests coming in. How do you go about scoping or even like prioritizing to what point are you also kind of comfortable to let the engineers run and do their own thing? And to what point do you feel like, okay, when do we need to be involved as designers? Like what's, how do you control this? I involve the designers very early in the process. So as soon as we have start writing up an epic or something like this in that sense, or even finding out what the problem actually is, then they talk to customers in a very early stage and each of the teams, they have different parts of the roadmap. We have a payment team that owns the payment process and if they want to do improvements where we see very early that they plan us in the next quarter to do something around our checkout, then we are in. I'm going to raising the flag and say we need design in here. And it's kind of developed a relationship where they come to us. We have a Slack channel called us, the UX design team, and they're going to start reaching out and then say, we need design here, sometimes very late. But recently we had a fun thing. We worked together with Salesforce. So Salesforce Commerce Cloud is crucial for us. A lot of retailers run under this system. And one of the teams they built, they wanted to build an interface to be able to control, I think something in the catalog import easier. They came to us and said, can you do the design? And we came together in a meeting and then we looked at each other and we're saying like, you can just make, you know it better than we do actually. You know actually the users from the Salesforce Commerce Cloud integration layer that need to do this. We don't. We would need to do user research. So why are you not doing some wireframes? We have systems. We can give you any wireframe system, whatever, put some forms together and then come back to us. We're going to give you advice. We're going to help you. So we make them better designers. It's, you know, I like to say like Jared Spool is like, everyone is a designer, but most of them are not good. You know? And you could say like, if somebody comes to you with a design and you look at them like, well, this is not good. Let me take it. I'm going to take it over. This is not empowering. This is taking it away from them. Or you could say, well, wow. So let's look at this together and let's walk through it and see if there could be some improvements made. And how do you feel about that? Why did you make that decision? So we're going to make them learn more about the design process. And that's really crucial for me to scale this at a level like three designers versus 70, 80 engineers. I will never have 70 designers in each of the teams. It's impossible. I have to say, and we slightly touched on this also in our last session. I think it also really depends a lot on like the designers. Some designers get kind of protective also about their work and what they do. And I can imagine that you specifically are looking at this like a little bit with another lens because you are coming from a background where you used to code, where you were not a designer. You didn't go like to design school. And so, so I guess like for you, it's easy to grasp this. Is there an advice for, let's say the traditional designers from the design school and so on, like on how to build this trust also in engineers or like, what would you tell one of your designers when they start getting protective about, oh, I wasn't involved in this specific case, for example, or an engineer showed me a wireframe? Because like, I think especially when non-designers come up with some suggestions, I've seen it quite often that designers then say like, oh my God, but why does he believe that he can do my job? Well, I feel like even though I haven't been to design school, I also get defensive. You know, I still go into this trap of I make a design, you know, you spend time on it, you're kind of proud of what you did, and then you show it to an engineer. I remember we were fighting a lot back then sometimes. And you know, and then the engineer comes up and says like, this is not going to work. This alert or whatever you like put in, we can't do this, and you're like, I want the alert. I'm like, okay, take a deep breath and try to understand the other perspective. And then you as a designer, if the engineer tells you, well, this takes a day and this takes a week, you have to make a judgment call. You need to know the business, you need to know how much time you want to invest, because that's a crucial piece of the designer. If you have all the time in the world, you can try to design the best thing ever. But wouldn't it be interesting if you approach it from, I have three days and I have to finish this book. Would you like try to come up with another chapter or would you try to fix the spelling mistakes? I would bet you would try to fix the spelling mistakes and not adding another chapter. And this is also about the design, like how do we, how much do we want to change actually? Or do we want to keep it like this? And I think it's not easy. So don't design too much without involving somebody else, show designs as early as possible and as ugly as possible. You can still make them better. I have sessions with engineers where we design ad hoc in a Zoom call, but recently we talked about opt-in capabilities because we're building a pilot where customers have to opt-in and we knew we have this in the sprint and the engineers did all the spike work and tried to analyze what is possible from a technical perspective. And I was looking at it and say, well, how does it look like in the user interface? Could have go to my desk, I do it and then I come back. Just jump right into Figma in this case, take the design system we have and make a quick flow. We got some pretty basic questions out of the way and then we agreed on this and we went out to the call and I had some further ideas to make the design actually a little bit better. And then two hours later I was sharing like here, like some improvements, I changed this, I changed that and I had to buy in immediately from the engineers because they were part of the design process. If they're not part of the design process, always imagine pushback because there will be pushback and just kind of stakeholder management because they're all a stakeholder. And you know what? End of the day, honestly, the designer is sitting at home and the engineer is on an on-duty call because something doesn't work in the business of your client because it's a B2B business. So the designer is not sitting there fixing the problem, it's the engineer that has to fix it. So also always think about their side, that they have to be there. Yeah, I guess it just like shows up again, the whole importance of like relationship building as well. Mutual kind of respect, trust, I mean, it's already becoming a theme after a couple of interviews, but I can totally see the importance, especially if you're a small team and you need to learn on how to prioritize and how to not waste time in endless feedback loops or discussions or trying to convince someone about something. I think just to add one more thing, I think for us as designers, it's important to show our value. Nowadays, it's a little bit more acknowledged, I think also from CEOs and from some like on the C-level that design is important, user experience is important. So when you work in a company that really values user experience, call yourself lucky because that's not always the case and you really have to fight a lot. So show your value, show why something is actually better than the other version that was proposed. And also keep in mind how much time you want to invest, because it's all an investment at the end of the day. So Henning, you talked about talking to your customers, you talked about improving your processes within the design team, you talked about values, we talked about the communication issues and challenges, the collaborations with engineers, but there's one thing I'm really missing here. So let's bring a little bit of meat to the bone or for the vegetarian people, fruit to the trees. How do you... Okay, that was a very bad one. Are we talking about the low-hanging fruit now? Yeah, let's go to the low-hanging fruit. Where's the product manager in all this kind of processes? So how do you kick off a feature together with the product manager? Well, you don't need them. That's what you told me two years ago. I do not move forward without a product manager. Honestly, if there's a feature or even an idea and the designer comes up, let's look for the PM that's responsible for this area. Do not do this alone because you don't pull it through until the end. And not every designer knows how to launch a product or a new feature. It's not just designing it. It's like the initial stakeholder management and then like, okay, this is the idea. This is the problem I'm trying to solve. But you also have to get it live and maintain it. So I would not move on without a product manager. And then they are key. Sometimes the tasks they do, they overlap, of course. So I worked as a product owner myself at New Store actually, because sometimes we had some pretty interesting development in the product design phase because we were all designers, but we felt so much ownership about the app we are building that we pretty much took over. PO responsibilities or PM responsibilities. And then we believed we can just do that. And after like half a year or year, I went out of this because I felt that this is not what I want to do. I love to design, I love to investigate. But I don't want to deal with all this other stuff. You know, you get support requests, you get all these questions the whole time you have to respond. It's a pretty hard job, actually. So it's good if the designer incorporates the product manager immediately from the beginning. There's a good process we're using called user story mapping. I think you've heard of it. Which is, we talked a lot about it. The topic comes up quite often. I'm not sure we're onto something. But this is a good good way of also making engineers and product managers do design. You come up with an activity. And by the way, you should research the activities of users. You can start making them up, but then go back and validate them. Or you actually talk to them and then create the activity. Because they pretty much never change. They are kind of stable. How does somebody do a checkout? Well, somebody comes, has a product, you need to take it, you identify it, and you take the money and customer walks out the door. This doesn't change. Maybe you want to change that. But that's another story. But the options, how do you do this? Well, people did it 80, 100 years ago already. Nowadays, they use apps and mobile phones. And like 50 years ago, they just use a normal cash rep to do that. Now they scan barcodes. Back in the days, they put some stickers on and said the cost is 5 euros. So this never changed. But the options and how you solve it has changed. So the story mapping process is crucial in our product discovery. And it also helps you to get a shared understanding. Because imagine you write up an Epic, put all the requirements in there. And if I do this as a product manager, everybody should understand this. Well, everybody looks at that, reads it in their own time, which is good. And then they have a different picture in their head. One imagines this like this, the next one has this imagination, and the third one this one. Then we do story mapping. We put everything on a wall, or a mural board or some other tool that nowadays also in a digital way, that I prefer also the whiteboard. Nevertheless, and we start out mapping everything. And out of a sudden, people realize that they had a completely different understanding of how it should work. Now we get an alignment. And if everybody walks out the door, and looks back at the map in two weeks, or in four weeks time, they remember what we talked about. It's like a vacation picture. You see the beach, you've been there two years ago, you remember how you get there. You remember some stories around, you remember the super annoying couple was there, they were always talking about something you didn't care about and way too loud. You don't see it on a picture, but you remember. And the story map for me is key. They start remembering all these things. And you know what's really cool? If an engineer in a sprint review shows a capability, and they actually tell the story. They're not just showing, yeah, you could click here, and then it does this, and it does that. I had this. Because sometimes on you, so we jump on the other side, and we look for solutions that we might incorporate into our system. And then people present us their things. And this is super interesting, because then you see like, you should do more storytelling. I know what you're trying to do, but I don't get it. This is not good. So storytelling is crucial. And if engineers can do that, this ultimately leads up to they understand the product better. Because think about they make decisions in the code that really influence how the product works. And if they don't understand it, who can understand it if they don't? And the designer, they see that they can make a design right now. And then you still have a different idea of what I did. And you're like, I thought this works differently. I thought it like this. Well, a story map can help definitely. Actually, like, I would want to go back a little bit to the whole topic of working in, let's say, the B2B enterprise business, we started there. And I think like, there's also a lot of knowledge you might have that would be super interesting to others working in that area as well. And the thing that one one thing I'm personally super curious about is, especially as you mentioned, there's like a lot of like these features that have to be there, right? I already forgot like table stakes, table stakes. So yeah, you bring to the poker table. So you can't I thought about my plate. No, no, it's not nothing with steak on my plate. That's when I think about stakeholder. No, it's something that you bring to the table as the money you can start with without they don't let you play. So you can't play with them. So no, but I mean, it's, it's good. I mean, it's like these kind of things that help you understand like, also, the stakeholder probably comes from something similar. Anyway, I just understood T-bone. Okay, we're getting we're getting hungry here. So with all these table stakes that you need to build, where do you as a company prioritize? When do you say no, because like, obviously, and we also shortly touched on like feature creep or to simply have like a lot of stuff in your apps. And I would assume this is something really hard for many people working like with enterprise on where to draw the line when to when to say no, what do you need to integrate? Because it's completely different from a consumer product where you're just like, okay, here's the product if you want to use it, use it. Otherwise, like, yeah, especially when you talk about consumer products, it's something we learned very early is when I give you a version, I cannot just change that because I'm like, Oh, I have I have a B version, the A version didn't work. But the associates, they got used to this, right? The other B in your B2B is running a business, just not deploy a new version. And it's all of a sudden, the whole interface has changed. So something you also need to incorporate. So where to draw the line. We are in year five, a new store. And people keep asking about what happens if the internet is gone? And we're like, well, then it doesn't work. And then we keep losing customers for this. So if we want to go addressing a different market or go up market, we have to have an answer for an offline capability. You could say it's a table stick, right? Like you can't have a point of sale system that doesn't work without the internet. We could also argue and say, well, then they always have internet, put a SIM card into the phone, right? It's thinking about what problem you're trying to solve. I try to be always like, they always want to sell, they do not want to leave the customer without anything. Well, okay, we can try to solve that. Maybe offline mode is the solution. Or maybe we have 100% coverage of your Wi Fi in the store. And always have a backup internet. That also solves the problem, by the way. So that's one way of getting to deal with the uncertainties of the customer because they have an anxiety. They want something new and shiny. Of course, it looks cool. It's way better what they have right now. But they are scared about the new solution. They don't know it. And you know, it always looks nice in the sales package. You go to website of a B2B company. And a lot of things on the website that you're like, wow, this looks pretty cool. I want to have this. But then you start looking under the hood. And then maybe half of it was just like some nice screenshots. And it never really worked. So you have to be very careful with what you promise, especially in the B2B sector. In the B2C, they're going to figure this out in two seconds after they signed up. Where's this? It doesn't work? No, I'm gone. Sign out. Sign out. Exactly. Delete my profile. So where to draw the line. As I said, for a long, long time, we had no proper cash handling. We had a button. The cash was all nice from the reporting. I'm not saying that. But then we wanted other customers. And they said, well, we have cash draws in the store. You have to work with them. So we started to put them in contracts and also promised them. I said, okay, you want to go live when in like six months or a year. Until then we have cash management. And then I said, okay, I'm going to go with you. So then we develop an MVP. We develop something that we call like the minimal viable product, right, or minimal marketable features, or there are many words of that. So I call it the first version that you also hopefully do increments on. Sometimes you don't, you just, actually, you should try to aim for a good shot in the first version. Because the likelihood that you never go back at this is not so low. We all experienced that, I think. All been there. Yeah, exactly. Seen it, done it, failed it, I would say. So you really need to nail down. At one point is a problem solved. If it's okay, like this, then you can go with it. Is it for one customer? Or is it for 10? If it's for 10, you should spend more time on it, right? You should really like this is a table stake that we need. We had capabilities that, you know, I keep saying cash, right? So cash was something we built last year. And we always said, now we do the investment. And we spent like, a couple of months building that from, okay, now we can open a drawer, everybody was yay. Okay, now we do all the non sale transactions. Or someone who takes like some petty cash out of it. Okay, we have to scan that drawer. And by the way, we have to find the right hardware because we have the mission to challenge these old systems, right? These old perceptions of retail, how it works, we're going to give you something else. So we have to like find other ways. And if you think about a cash drawer, they usually connect it to a point of sale system. But in our case, it's an iPhone. So they're not connected. So we need to find it, we need to find a vendor that gives us cash drawers that are on the network. We found someone pretty cool, they have like barcodes in the front, and you can scan them and they open. So for us, it's like the associate just walks there takes out the money. Also a good interesting thing from the user experience in this moment, they put the phone away. In every design we did, We never put the phone away, right? Because in the design, you do a prototype, you don't deal with cash. You say, I know you give me the $50 and then you're like, but out of a sudden, in the real world, I can give you all that money and I feel like, okay, the phone is here, the screen should stay on because I want to see the change. Doing all this and then, you know, that's pretty important to always look about this. But drawing the line, the user story maps help. Here's the line, MVP only fulfills those activities and then we're going to give it to you. You can get this in, I'm not saying two weeks, because I learned that this is not like, I have barely seen a feature developed in two weeks sprint time. I mean, if you would put the sprint on like six weeks or eight weeks, then it would work in one sprint. But you also have the risk of like building something that's might not what the customer actually wants or what solves their problem. Because often they know what they want, but we need to find out what problem they have. Because they tell us like, just make this button there and change this in this table and then we will work. And then we're like, I'm not sure if this will work. And by the way, you have one customer and we have like hundreds of them using this product. So maybe it's just you. We have to find this out for each of the table stakes as well. So especially for like inventory management, something we also developed, it was often a weak point because they said, well, I knew so, you're really cool, you're doing store fulfillment so we can ship products from the store, but you're not the inventory master. We're not, we don't want to be the inventory master and like, but it would be actually cool if you would be it because then you can control everything, how many units you have, you can cycle counts, you can do all this. Someone comes in in the morning and delivers new items. You have to take this and put it into the system, right? And we had no system for that. We had no app, nothing that helped you. So they had always to use a third party. So now they're going to pay a new store and another system just to take in the inventory. Of course, they keep asking if we can also be the inventory, right? Then they don't have to get this other contract and the B2B. So for us, this is like, we need to make the platform as good as it can be to deserve your basic needs, which also makes us a little bit more sticky, right? So it's harder to remove this system as well as we have more opportunity to make it better. When I talk about Decathlon, for example, that we have them in the US, in all the other parts of the world, they have their own system and they're really good at this. They're really good at this, but they developed it by themselves. So if they don't have time to do further improvements or they also need to establish an engineering and product culture to understand their own product, of course they could build it for themselves the best, but often retailers end up having customer solutions that they cannot maintain or technology is changing so quick. So yeah, for us, it's literally talking to the customer and finding out what the table stacks are. Drawing the line again, Henning, by the way, thanks, that was the meat to the bone I was looking for. So what are a couple of key takeaways you would like to share with the audience when it comes to user research and design thinking in B2B enterprise? Talk to the users. Always ask, what is the reasoning behind something? Why do people want that? What's the job they're trying to get done? What's their goal? If you're in a story mapping session and you struggle with, is this an activity or is this an option or like, where do I put this? I like to go, if you ask how to do something, you go deeper, right? You go more like, okay, how to do it? If you ask why, you go up. You find out at some point, so why does the associate scan the item? So to identify the product, why do you need to identify the product? Because I need to sell it. Okay. The ultimate goal is to sell it. That's good for me. Keep doing that. Try to find out what it is. And think about the business on the other side. You might have your own goals as a company, but these goals do not relate to the goals your customers have. Our brands, they have different targets to hit. They get a feature from us and if they don't see the value in their goals and in their numbers, we made a mistake. We did not make it obvious for them. Why does this feature move, gives you more like GMV, more market value, more, right? We launched a feature called MixCard where you can make two transactions, something that's in the store and something you don't have in one. Cool, right? If we launched this, then you have less transactions. Because before you always had to do two, so like, oh man, we're doing all these transactions. Now you have only one. Make this visible and make the change visible. The impact of this. Awesome. All right, Henning, that was an amazing session. Lots of learnings. Me and Christian, as usually, will stay a little bit longer and try to get our heads around like all the things that we said and debrief a little bit. At this point, I really want to thank you. It was great having you. It was great to share a glass of wine with you and hear your story. Thanks a lot. Henning, thank you very much. It was a pleasure seeing you again. Thank you. It was a pleasure for me as well. Bye. Bye. All right, finally, without Henning, back in the usual setup. So Alex, I'd like to hear from you what your impressions and key takeaway were of this nice session with Henning. I really enjoyed hearing the setup that they have at Newstora. Having a fairly small design team and working so efficiently also with this whole engineering organization. I know how complicated it also can be to scope projects and to make sure that you don't burn out designers, but you still can deliver across the whole product. I also love that this team emerged again of trusting, building the relationships with the other team members. And I mean, this is really one thing I'm always looking out for. And therefore, whenever I see this kind of being confirmed, very positive. And at the same time, definitely interesting as well, this whole topic of working with enterprise businesses, especially going deeper on who is actually using the product and not only thinking of who is buying it. And I think this is so crucial when you try to design the user experience, that you include the end user, that you include the associates standing in the shop, and that you even go like this one step beyond of seeing, okay, there is even like the customer at the end who might see the interface and who might look at the interface. And I think it's such a big ecosystem that you have to look at and making sure that also as designers and throughout the whole product development cycle, you're involved. And I mean, Henning spoke about taking the engineer along when they went to San Francisco to the stores. I mean, this is the best thing you can do to build this relationship, to build a mutual trust, to get the buy-in, to get the involvement, taking it then down into like really co-creating. And I think user story mapping is just a part of it, but the co-creation of having the whole team involved is just such a crucial part. Yeah, I fully agree with you. What I was hearing out is that the whole design culture is very valued at Newstore. There are many companies where design teams are working in an isolated bubble. I think especially you, Alex, have seen this many times. What I was really impressed about is, first of all, as you said already, the close connection to the engineering team, which I really like. I also liked a lot that the team itself, going back to the design culture, focused so much on improving processes. This is something that I personally would share with design teams to not only start serving others, to go a little bit back and ask yourself, what can we do? What can we improve within a design team? The most important thing, as usual, but this is not because product is so important, but it's just part of the process, is doing it not by yourself, as a designer, as an engineer, or even as a PM. I touched it also in our previous episode. I think it's super important to work as a team. Planning a feature without a product manager, and I'm not involving the people who are drivers, doesn't make sense. And Henning said it very well, you can't push it through as a designer by yourself. So the collaboration part is so important, and I think there's a kind of theme coming out of our podcast that everything is around communication. Seeing how well they're organized and how much they are living this kind of culture is to me super impressive. I mean, it's a little bit also confirming why we are doing a podcast. We want to kind of look at this cross collaboration. And I think one thing that unfortunately we didn't really talk too much about it, but still like I think there was a notion in there as well of the importance even beyond the product team. And I think, again, in enterprise, there are so many different functions, working with the clients, onboarding them, and especially like even the sales team, and we heard about contracts that are being signed with some promises also in terms of like feature roadmap and what is being delivered. And there comes even in this importance of how do I work with those stakeholders? How do I make sure that not only like the engineer walks up to design and openly asks about something that they are going to work on. Like the salesperson comes to me and says, Hey, listen, like how does this affect the user experience or how would you integrate this? And I think having product really at the center of a company, at the center of an engineering organization, at the center of from consumer products to B2B products at the core of the business is super important because you build it, someone needs to use it, and if the salesperson promises the wrong thing, you can have best product development process and design process and engineering process on the word, but you will fail. To maybe go one step further, I see here the distinction or the importance of taking a look at two things. And so one is the customer experience and the other one is the user experience. And I think it starts with the customer experience to do the right contact negotiation, to make sure you have everything in place that you can empower the customer to use your solution. That's the first step. And then we go the next step to make sure that everyone inside this business is able to use the product. And that was very well explained and it seems like they have very good processes. And I'm really looking forward to talking to more people with such a nice way of working and inspiring feedback for us. Absolutely. So this brings us to our next session. We have some good interviewees lined up. And so stay tuned. Thanks a lot for tuning in. As usually, we have an email address where you can send us your feedback. It's hello at product-bakery.com. Yeah. I hope to see you in the next session. Me too. And goodbye.