Creating A Collaborative Culture In N26

Olivier Maître, Daniele Sandri, Laura de Bella, Chhavi Shrivastava, Josh Morales at UXDX Community: Spain. Video: https://youtu.be/26WgLM8B6sg

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.

Why everyone ends up talking to users

[00:00:04] Josh: Hey, thanks for the introduction and for having us today. I'd like to start these short talks about collaboration by looking into the way we ask questions to users. But first things first: why do we even end up talking to users? Well, because everyone needs to do research, right? I'm sure that most of you have heard any of those sentences at least once in your life, and don't take me wrong, I strongly believe research shouldn't be exclusive to researchers. Research is a team effort.

[00:00:34] Here at N26 we really wanted to collaborate in doing it, so we created People Work[?], a space where designers, product managers and even tech peers have the chance to interact with users on a monthly basis. In a nutshell, this is how it works. We invite four users to talk with four different teams, and there are four rounds of 15 minutes, which makes a full hour. It's like speed dating, but we don't necessarily expect kind words from the other side.

[00:01:06] Cool, we've made it. Every month we have more and more people signing up for those monthly sessions to talk to users, because after all, that's the thing, right? Interviewing users is just talking to people, and that's something virtually everyone can do. Agreed? Well, almost, but not exactly.

Build an arc, not an arrow

[00:01:30] When we think of talking to people, the anchor we use is the daily chats we have had since we were kids, which is completely normal. But in this informal way of communication, we don't really need to have a clear objective or a set of questions in mind. We can just grab a drink, sit together and talk about life with no purpose at all. And last but not least, we want to give it a comfortable space, reducing awkward silences and completing unfinished sentences if that helps. But to ask questions in our interactions with users, we need to reframe that.

[00:02:10] Let's think of a different conversational space: a court, and in particular the figure of a lawyer. Then I wonder, if what a lawyer does is just talking to people, why don't we see more and more folks willing to represent their own rights in court? The answer is clear, right? Because in this case it's easier to acknowledge we don't know the rules of the game. The daily chats anchor is helpless.

[00:02:38] Coming back to interviewing users, what are the rules of the game? When planning a guide, this is the interview structure we have in mind by default: a neat, straight arrow, a rush to get our answers straight from the user, as if it was an input-output system. But the arrow approach will at best endanger our research outcomes, because actually the questions we have, or the tasks we want the user to perform, are just one big moment in our interview time. First we need to get there, and after, we need to reflect on it. To do all that, we need to build an arc, not an arrow, and this is what it looks like.

[00:03:23] During the first minute of our interaction, our objective is to build rapport, set the right expectations and get to know the user a little bit better, especially around the topic we're interested in. Then, and only then, we can gradually move on, asking questions toward our topic, from more generic to more specific, one by one. You will soon realize that from "the good weather is coming back, right?" to "which apps do you use for booking flights?" there is a short, very interesting run. At that point you can consider yourself in the sweet spot to ask about the topics you actually are interested in, or to invite the user to perform a task related to the topic you were discussing. When done well, it just feels natural.

[00:04:04] Moving on, you can keep asking more questions if you're interested in particular aspects, reflect about what you've already discussed, or simply think about the future together to understand what the expectations are toward the research topic. And of course, by the end, please always make sure you overcommunicate how useful that time was for you and the team. That's the arc approach: similar to our daily chats, but not exactly that.

Four principles for asking questions

[00:04:35] By this point, though, you might be thinking, "Okay, great, Josh, but this talk was supposed to be all about good and bad questions, and we haven't covered that yet." And you're right, so let's do that. How do we ask those questions all over the arc structure we've seen? I can think of four key guiding principles to take into account.

[00:04:57] One: questions should be rooted in previous experiences more often than they are in future hypothetical situations. When we ask questions using the conditional tense, like the classic "would you buy that?", we are more likely to get biased answers, just because we are humans, and as such we are good at projecting ourselves in idealistic scenarios and making compliments.

[00:05:21] Two: remember, you're not reading a survey out loud and asking for check marks. While interviewing, always ask open-ended questions instead of providing a limited number of options for the participants to choose from. Let people freely express themselves in their own words, even when they are wrong.

[00:05:41] Three: of course you have the hypothesis to validate in mind, and that's mainly the whole purpose of interacting with users, we got it. But giving clues about what the correct answers are to users doesn't do a favor to any of us. When asking questions, don't guide or suggest; otherwise participants will start answering what they think you want to hear from them.

[00:06:02] And four: reduce your interventions, or to put it bluntly, shut up, really. Don't interrupt. Don't be in a hurry and jump in in the middle of a sentence to ask the next question in your guide. Be patient, use small pauses to let them know when you expect them to talk. It might feel a little bit awkward in the beginning, but with practice it really pays off. Listening to yourself in the interview recording will also help you improve faster.

[00:06:36] And that's it. Remember, when designing an interview guide, build an arc, not an arrow. Ask unbiased, open-ended questions based on previous experiences, and please embrace and engage everyone in doing collaborative research, anytime and as much as possible. But hey, users are not the only ones a product team should involve more in the process. What about developers, for instance? My peer Daniele will now tell us more about it.

Design and tech: two different philosophies

[00:07:03] Daniele: Thank you, thank you, Josh. Hello everyone, my name is Daniele. I am a senior product designer at N26 here in Barcelona, and in the next few minutes I will share with you some learnings on how to boost design and tech collaboration.

[00:07:22] When we have design and tech, we are talking about two very different approaches to products. I could almost say two different philosophies. On one hand we have the designer, who always tries to be creative, to think big, to challenge the status quo and provide a solution that simplifies users' lives. On the other hand we have the developer, who needs to translate that vision into code, always trying to reach their goal in the least expensive way while ensuring performance and scalability.

[00:08:00] These two different approaches can sometimes make the collaboration really difficult, and I'm sure most of us have faced at least one of these consequences that bad collaboration can bring. Time to delivery becomes longer and longer as the project proceeds. The solution gets far away from the initial target; a well-crafted design can become some sort of Frankenstein's monster. And last but not least, the team can get unhappy. The team members can get unsatisfied by the work they're releasing, and unmotivated.

[00:08:42] In my 10-year career I had the chance to work in a few different companies, collaborating directly with more than 30 developers. These experiences of course made me face some tough challenges, but also taught me some behaviors and approaches that helped me dramatically improve the way I now collaborate with developers. I tried to synthesize all my learnings in four main principles.

Involve developers early

[00:09:15] The first one is: involve developers. It can sound quite obvious, but by this I don't mean inviting developers to some milestone meetings to show them your well-crafted designs. I mean involving them early on in the process, from the very beginning of the journey. There are many ways to involve developers. You can start involving them in the research phase by inviting them to exploratory research and user testing sessions, and if they don't show up, you can still share your results and your insights with them.

[00:09:56] You can invite developers to concept workshops. Developers are very different from one to another, but they can really bring a different perspective to these workshops that gives a lot of value to the project. Make your work visible to developers. I mean share your early designs, even if you're a bit ashamed of how they look. It doesn't matter; share them with developers as well. You can get really valuable feedback from developers, not only from other designers.

[00:10:33] This picture is an example of a workshop we ran last January at N26, where we put together a few teams involving back-end developers, front-end developers, designers, PMs, product owners. This was a kickoff to align the whole team on everything we knew on a specific topic: the state of the art, the data we had, the constraints we were aware of. But it also served to prioritize the next steps together, to set the priorities. It really made a difference to start a series of projects on the right foot.

[00:11:14] Involving the developers is important mainly to ensure the whole team has a holistic understanding of the project, to make designers and developers understand and agree on the problems to solve at the beginning, making it easier to agree on solutions later on. It's important to identify constraints and issues earlier, making designers aware of them so they design accordingly.

Blur the boundaries

[00:11:47] It's not enough, though, to involve developers early in the process. This brings us to the second principle: blur the boundaries. We should work closer along the entire design process. It's a daily behavior; it's a continuous process. Often we think of product development as phase one, the design, then the handoff, and then phase two, development. Some companies still apply this, but they really miss an opportunity here to fully empower designers and developers to get the best out of their collaboration. The two phases should overlap more, enabling a loop of frequent iterations between the designer and the developer.

[00:12:34] The whole point of this principle is breaking down the whole design into smaller, incremental chunks of polish. In this way developers can start developing earlier, for example starting with the architecture or some main flows, then getting the wireframes with some more details, and then getting little by little to the polished final design. This also means, on the other hand, that designers need to keep designing until the end. Forget about the handoff as the end of your work. The release is eventually the end of the work. There is a lot of work that happens after the handoff until the release. Be aware of that, plan for that.

[00:13:23] This approach of blurring boundaries brings some major benefits. It lets you gradually reduce uncertainties on both sides, design and development. It lets you easily adapt to unexpected issues. It lets the team find quick and feasible solutions together on the go, often taking decisions together, sometimes directly on the code, and that's totally fine. That's wonderful.

Dream big but be pragmatic

[00:13:52] Now let's see also how to approach this continuous collaboration, with principle three: dream big, but be pragmatic. Dreaming big, I think, should be in every designer's DNA. You can have the best vision ever, you can design the best solution ever, but if it's not feasible, or if it takes months to be built, well, after all that's not such a good solution. Informing design decisions with tech effort is being user-centric. Time matters, not only for your managers, not only for business, for your users too. They are out there waiting for your solutions. Again, time matters.

[00:14:41] It means designing while considering the complexity behind your design decisions, considering the effort needed between one solution and another. It means finding the right trade-off between the ideal solution that solves the user needs and the effort needed to implement it. Designers have a crucial role in this process, together with developers of course. It doesn't mean taking for granted what developers can tell you in some situations, like "No, this is not feasible" or "No, this is super hard." Challenge them. Try together to find some solutions. Try to dig deeper into the problems, try to understand their problems and to find solutions to those problems.

[00:15:29] Again, think big, but also be flexible and adapt to the limitations you face. Why be pragmatic? This approach will let teams deliver faster, learn earlier and increase design confidence for the upcoming iterations.

Build empathy

[00:15:49] All these principles, though, are worth nothing without this fourth one: build empathy. Empathy is the ability to understand and share the feelings of another. I say "build" here not casually. We need to build this ability on one hand, and the conditions to make it happen on the other. Building empathy happens on two main levels, I would say. One is the individual level. That means treat developers as your users. Observe them, understand them, adapt to them, adapt to the way they work.

[00:16:27] Developers can be very different based on personal soft skills, hard skills, seniority. Understand who you're working with, their strengths, their weaknesses, and adapt to them. Solve the frictions and create the conditions to do some great work together. The other level is the team level. That means planning some time together, some fun time together, some time where people can get to know each other a bit better, not only on the professional side but also on the personal side, on the human side.

[00:17:06] This of course also brings some huge benefits to the collaboration, in terms of building trust, in terms of limiting conflicts, and not least a stronger team belonging. Now, if you were expecting some specific step-by-step guides or frameworks, I'm sorry, I probably disappointed you. But I really think that a healthy collaboration, a good collaboration, starts first with common sense.

[00:17:41] To quickly wrap this up, remember: involve developers as early as possible in your process, blur the boundaries between designers and developers and their flows and journeys, dream big but be pragmatic, and build empathy. Thank you very much, and now I'm going to hand it over to Chhavi, who will talk about one of the ways to build empathy with your team.

Getting to know your team

[00:18:12] Chhavi: Thank you very much. Hey, thank you, Daniele. Before I start, does this calendar look familiar to you? As part of cross-functional teams, a lot of our calendars look pretty much like this, focused on productivity, delivery and quality. We have these release checkpoints, sprint planning, retrospectives. Let's not forget the monthly and quarterly OKR updates, leadership updates, company updates, one-on-ones and so on. In the middle of these updates and checkpoints, do you think we are missing one crucial checkpoint? Don't you feel we need to know our teams a little better?

[00:18:54] What am I saying? I'm saying: are you working with John the iOS developer, or are you working with John the iOS developer who loves surfing? Hello everyone, I am Chhavi, and I am a product designer with N26. Today, on behalf of my team, I will share some ways we collaborate within our teams, or as we call them, our team rituals.

[00:19:20] Now, as soon as I mentioned our calendar and our team, I'm pretty sure we all started thinking, "Oh god, not another meeting." Well, let's just accept it: no one wants to add another meeting to their calendar. So why are we even talking about it? Why should we as a team invest time in creating team rituals or getting to know each other better? Well, research suggests that employees who feel they belong to the team perform much better, and one of the key ways to increase this feeling of belongingness is to know your team.

[00:19:54] As Daniele also mentioned, it is very important that everyone feels comfortable to show up at work as their whole human self and not just their work self. Knowing our teams, having allies and having healthy collaboration methods really contribute to this feeling of belongingness, and to an increase in productivity. Now we are all hyped up, and we think, okay, this is the time we go in and put in another slot for a team meeting. Well, wait, let's not do that yet.

Designing a team ritual

[00:20:29] We don't want another black hole meeting that sucks in more energy than it creates. Rather, we need to design the time that we spend together as a team. Create a team ritual together with your team. Create agreements, not just a set of rigid rules. Go through the process to creatively design the team time. To give you an example, today I've got some slides, the actual slides from one of our favorite rituals within the local design community at N26.

[00:21:00] First of all, we just went ahead and renamed it. Rather than calling it a stand-up, we started calling it a get-together. Every Monday afternoon we get together as a team and start off by talking about how we are feeling, using mood scales. We got creative with that. We used a mutual[?] like this, or this, or this one. Yes, this kanji one was a real hit with our team.

[00:21:31] In the same Monday ritual, we also started putting in some quick snapshots of our past week. Simple things like, "Hey, here's what I've been cooking," or "Here's what I've been watching on Netflix," or "Here are my favorite Instagram accounts," or, these days, just pictures from our grocery trip. Having a slot on Monday to just share how we are feeling and how we are doing helps us break into that week together as a team. We are much more in sync with how everyone is feeling in general and how everyone is doing at work.

[00:22:05] We also take some time to come up with team activities we can do together and share any thoughts or concerns openly. It's an open slide there, like a team's own digital scrapbook, and everyone is really free to put in stuff that they want to. There are no hard rules as such. We take turns to host this ritual, which also allows everyone to bring their own ideas and thoughts and creativity about how to go about it. Over time it has really become a safe place, and as rare as it may sound, right now it's a meeting that we look forward to as a team.

[00:22:43] Seeing the last few slides, you might feel like we got it right on the first go. Well, not really. It's an ongoing process, and you need to be able to evolve and adapt to your team's needs. I'll give you another example of a ritual. This one is from our weekly team update. Since we all work in cross-functional teams, we felt it was really necessary to keep our fellow designers updated on what we're working on. We did what everyone thought was best: we just got a slide deck together and started putting in stuff about what we are working on. Over time we realized nobody was really reading it. We were just doing it for the sake of doing it.

[00:23:22] It was time to fix it, and this is what it looks like right now for us. We all put in little screenshots from our design files on the slide deck: really quick, really dirty, really low effort. And we renamed the ritual as well. Guess what the ritual is called? Screenshots. Another thing that we do is we do not shy away from having meetings about meetings. If one meeting can help us slash or improve five other meetings, then why not? We've also started doing a survey on the state of design rituals, and we come up with our own defined action items every time.

[00:24:06] To sum up: do find that time and build a safe place and time in your calendar for your team. This will ensure that everyone can show up at work as their whole human self. Take time as a team to design that ritual. Do not be lazy, do not look for that magic formula, and do not just try to copy the format that we have. What works for us might not really work for you, so just take that time to design that ritual for your team. And most importantly, when you realize something's not working, evolve and adapt that ritual to meet your team's needs.

[00:24:44] That was all from my side about collaborating within your teams. But how about collaborating with technical partners? Well, my colleague Laura will give you some useful tips about that. Over to you, Laura.

Launching SEPA Instant with a partner

[00:24:55] Laura: Thanks, Chhavi. Hello everyone, my name is Laura. I am a software engineer here at N26, and today we are going to talk about agreements with technical partners, sharing a little of what happened when we released SEPA Instant. Let's start by understanding why SEPA Instant and where this partner sits in our flow.

[00:25:20] SEPA Instant is a very cool functionality that we as a modern bank wanted to have. It's a scheme where you can transfer money within seconds, so it's very aligned with what we are offering for our clients. The problem was that we had a big time constraint, because there's a very tight deadline in this scheme's windows. There are specific days where you need to be ready to go live. But we had the possibility to integrate with a partner that we were already integrated with for other schemes, and we decided to go with this approach. Everything was set up, which would improve our time to live.

[00:26:06] We thought it was going to be a good idea, but in the end we were not thinking about this constraint of time. All the agreements and SLAs were already there, but we were not thinking that, well, we have to process these transactions within seconds, and maybe a few things were going to change.

[00:26:27] This is our general architecture. Transfers are regulated by an entity which is called the scheme, and it's responsible for setting the rules and defining how the movements are going to happen. The scheme's messages are more complex, so that's another reason why we decided to go with a partner. The technical facilitator works as a gateway between us and the scheme and translates every message that the scheme sends to us into a more domain language. The other way around is the same: when we are talking with the scheme, we are sending a more domain message, and the facilitator is translating it to what the scheme wants to see.

The go-live incident

[00:27:17] Then we moved on to the controlled go-live test. The development was fine, and we were able to make the deadline. We got to this point of the controlled go-live test, which is a moment where we partner with a bank to do a few transactions and see that the whole flow is working fine. By mistake, one bank updated their list of possible addresses[?], and we ended up receiving real traffic. When we were expecting 10 or 20 transactions in a week, we started receiving real traffic, so it was not controlled at all, as you can see. But in the end it was fine. We were happy with the result, because we started processing the first payments, and that was our main goal.

[00:28:12] Then we went live, and this is what happened. We had a major, major connectivity issue. We were surprised by a big volume on the first day. We thought it was not going to happen, because most of the banks charge fees to use the scheme, and we thought not many people were using SEPA Instant. But then we ended up receiving lots of transactions that resulted in timeouts. Our partner advised us not to worry about timeouts, because it's not an expected scenario. It was a super edge case that we didn't need to treat to go live. Well, we should have, right?

[00:28:56] We had to manually process a lot of cancellations, and it was piling up; we were having more transactions every time. So we decided to disconnect from the scheme. We were, I think, one week disconnected while implementing automated handling of timeouts and doing a few more tests. In the end everything was better. We were able to implement this automated handling. But we decided that it was not good enough the way it was with our partner, so we had to set the boundaries very clearly at the contractual level to make sure that everything we wanted them to be doing, they were doing.

Six pieces of advice for technical partnerships

[00:29:44] Here are six pieces of advice that my team and I gathered together, so that if you have to integrate with partners, you don't go through what we did. The first advice: make sure you have access to the proper test environment, and test unhappy scenarios. Don't trust "this should never happen, don't worry." I think this is basically what caused our major incident. Of course this instability shouldn't happen, but at the same time, we were not ready to handle it. We were told that this shouldn't happen in any case, and it was not the truth. Make sure that you test everything and you are confident with the product that you are going live with.

[00:30:34] Second advice: make sure to test load in a live environment, and please remind your partner to stop the pipelines when doing it. This is two pieces of advice in one. The first is because we didn't test load in a live environment at all. We just tested the functionality, and load we only checked in QA. If we had done that, probably we would have caught the issue and it would have been fixed before going live. Regarding stopping the pipeline, it's just because we had to retest a few things, because our partner's pipelines were not blocked, and a few tests that we did, mainly for load, were not conclusive. We had a few timeouts that probably were not because of the issue but because they were deploying.

[00:31:29] Third advice: make sure your SLAs protect what you really need. Availability is different from uptime. What we saw is that we need to be more clear in the SLAs and define everything that we really need, and make sure that the concepts are very clear. Uptime is a very broad term that can mean machines up and running, which is not enough, right? We want the payments to go through; we don't just want the machines working. It was frustrating, because with all the problems that we faced, we still had an SLA of 100% availability, which was not true. Make sure that the terms are really clear and you know exactly what your SLAs are protecting.

[00:32:20] Fourth: if you need to negotiate, protect different endpoints with different SLAs. Payments should be more available than returns or recalls, for example. This is not really related to this incident, but it's a past learning. We had degradations that were sometimes affecting the full connection and sometimes affecting only one of the endpoints. Our SLAs were very generic, and when we were negotiating, we negotiated too low, because it was on average. But in the end we don't want to lower the SLA for payments, for example. We need the payments to be four nines or five nines in SLAs, and we need to keep that. If you need to negotiate, maybe lower the returns or recalls, which you have more time to process.

[00:33:12] Fifth advice: make specific agreements regarding incident management: time for first response, incident severity, resolution targets depending on the severity, frequency of updates. We learned that during the process, and it was not very nice. We had an incident management policy inside N26, but it was very broad, and we figured out that we needed a very specific one for payment schemes, and even more specific when we are dealing with a partner. This was a change that we made, and now it's something that's in our contract. We need to make sure that we know when they are going to update us, if there is a direct line or a direct person that we can contact, if there is a war room that we can join, and make sure that they are progressing on the issue. Make sure that you have everything set up. It will make things easier.

[00:34:13] And the last one, and the most important one, I would say: do it often, from day one, and mainly think about it from day one. I know that we don't want to think that things are not going to go as smoothly as we want, but we need to think about it, and our lives would have been much easier if we had done this from day one. We had to go through all of this to learn, and I think we learned it. But that's the purpose of this talk: I want to make sure that fewer people go through what we've been through. These were my six pieces of advice. I hope you learned something today. Now I will welcome Olivier. He's going to drive us through what working with regulators looks like and what other industries face. Thank you.

Product frameworks come from loosely regulated industries

[00:35:03] Olivier: Thank you, Laura. My name is Olivier, and I am a product manager at N26. I now work on lending products, so things like credit and overdraft, and savings products as well. Prior to N26, I worked a few years in the healthcare sector. My talk here will be around adapting the classic product methods that you can see in [?] into industries that are heavily regulated.

[00:35:33] If you just do a Google search on things like product management frameworks or how to do product discovery, you'll probably find millions of results. As a matter of fact, there is a website, productframeworks.com, that lists 58 of them. In the end they're all a variation of defining an objective or a problem, building something to try and solve it, then measuring, improving, launching again. It's literally just flavors of that, in different shapes and forms.

[00:36:06] If you look at most of these frameworks, they come from industries where the regulation is quite loose. All of them need to comply, for instance, with GDPR in Europe, but that's pretty much it. Typeform at the very top, as an example, is doing surveys. The second example is the Jobs to be Done framework, and that comes from academia turned consultant. Google is Google. And this at the bottom comes from a tech veteran, an ex-Googler as well. There is, to my knowledge, no product management framework that comes from, let's say, a bank or a pharmaceutical company or a car company. That's not product management's typical background; tech mostly is.

What regulated industries are

[00:36:51] What do I mean by regulated industries? I hinted a bit at them. Essentially, a regulated industry is a sector of the economy where you have a specific set of rules, often quite strict, that tell companies what they can, cannot, must and must not do with regard to specific things like customer information, customer protection, pricing, partnerships. The goal of that is not to be annoying. It's just because there are areas where there is a greater need to protect safety, health, finances, things that are essentially super serious, not like online forms. In healthcare, if you screw something up, people will have diseases or even die. In finance, people will lose money. In transportation, the same thing if you have an accident; think of airlines, for instance. You must have that body of regulation that protects the industry as a whole.

[00:37:44] What does that mean with regard to product management? On this slide it's really high level, but I'll go with a few specific examples. Apart from GDPR, and forget about that one because everyone is subject to it, the rules of play in non-regulated industries are much looser than for regulated industries. I'll take an example on subscription pricing. Strava, the running and cycling app, a few weeks ago changed their subscription model and just said: now 60 days for free to anyone who signs up. No need for lots of communication, no need to explain it.

[00:38:21] If you take the example of a bank in a similar situation, you can provide interest-free periods. Think of your credit card. Maybe not nowadays, but they used to provide months or even years of interest-free periods. But then you have a whole body of communication items you need to provide to customers: what are the rules during that period, what are the rules after, how does the price change, and so on and so forth. The impact in terms of product management, if you move to that kind of regulated industry, is literally pages and pages in the sign-up flow of consent giving and small print screens, because you must make sure the customers go through this, rather than actually inputting something or going through the actual very simple step of signing up. You can see how a purely tech company, or a bank in this case, with the same intent, has to go through a very different route and design a very different flow.

[00:39:18] Another example, which tackles the partner part at the bottom, is pharmaceutical companies. I've worked on this kind of project before. When they try to develop digital health products, often follow-up apps for serious and chronic diseases that spare people from traveling hundreds of kilometers back to the hospital for regular checks after a transplant, for instance, they need to partner with hospitals or health institutions. There are lots of justified regulations around, for instance, conflict of interest: how you ensure that the doctor or the professor at the transplant center is not in some way paid by the pharmaceutical company. You have to show quite a lot of goodwill to the regulators when you do this.

[00:40:03] You also have to follow different rules depending on how deep your product goes, and that's the very big impact in terms of product management. It might very well mean the end of your product if what you're trying to develop would be classified as a medical device, which means providing diagnosis. I had a project, for instance, where we were developing a knowledge base around bacterial infection and whether a doctor would have to prescribe antibiotics or not, because in some cases it's not black or white. Adding a symptoms checker, for instance, would make it a medical device, and then you need to go through clinical trials and make sure that you follow a very strict, and fairly normal actually, process. A dosage calculator would be something similar. Making sure that the scope of what you're doing falls or doesn't fall within the regulation is super critical when you do product management in those regulated industries.

Lessons from lending at N26

[00:41:00] In the specific case of N26, what does that mean? Because we're a tech company, arguably, but we're also a bank, a regulated one actually, so we do fall into those very strict categories sometimes, and as I work in lending, I'm right in the middle of it. A few pieces of advice, a few things learned along the way. The first one that everyone must have in mind is that regulation is mostly good. It's here to protect customers. It's good for customers, and we all want to help customers. As a product manager, I identify problems that people face and that they want solved, and I help provide them the tools to solve those problems.

[00:41:42] The other thing that is a big difference is you don't get the choice. If you're in a regulated industry, you just have to abide by the law. Sometimes it's frustrating, because obviously the rules don't optimize for experience, which as product managers, designers and engineers we all want to do. One great example, if any of you work in the UK in finance, you'll feel the pain, is the Financial Conduct Authority's body of regulation. They're the regulator there. It's essentially a nightmare to read. It's full of obscure acronyms like BCOBS and CONC. But when you actually boil it down to the essentials, it's a great inspiration for amazing features around notifications for specific things that can happen along the way of an overdraft or a lending product. It's actually good to read as a product manager, even though it's tedious. The point being, it's actually a good thing. Regulation is something that is useful.

[00:42:40] The second thing, and that's more inward focused, towards the company: if you have an idea for a feature, a whole product, anything, talk to legal and compliance first. Not because you're covering your butt, but because that actually sets the constraints. As I said, you don't have the choice, so you must make sure that you get the constraints right. This is crucial. This will set the boundaries for the product scope, and therefore it will inform your user research, your business case assumptions, your tech decisions, with regard to, for instance in healthcare, what you can and cannot store as information. It's really important to do this in advance.

[00:43:20] The third and last piece of advice is that agile legal doesn't really work. It's not really a thing. You can't give advice on something that's always moving. You need a given product scope to give to legal and compliance, and they can have a look and say, "Yep, that's the law, that's why what you're providing works or doesn't work." They can also outline gray areas. You can have gray areas in the law, and you can have gray areas in your product scope as well, and that kind of discussion really needs a scope that is fixed at a certain period for it to happen.

Regulation doesn't prevent innovation

[00:43:56] The other thing is, don't think that regulation prevents you from being innovative. Legal and compliance folks actually like a good challenge. Most of the people I've worked with, well, all of them at N26 and certainly most if not all of them before, like a good problem. They're problem solvers. You give them a set of constraints and try to bend them, and that's something they like to do. Don't be shy, stay innovative, and just present whatever you're working on early enough, because no one likes to be surprised. The worst situation you can put someone in is, "Oh wait, that's going live in two weeks." That's going to hurt them, because they have to work fast, and that's going to hurt you, because it's probably just not going to work at all.

[00:44:46] This is actually the message I'd like to close with, also because every presenter has touched on this in their different presentations. The two things that really help in product management are building clarity and empathy. If you make sure you bring people in early enough in whatever you're doing, if you set expectations beforehand, or as early as possible, from day one as she said, and you work pragmatically with people, then everyone will end up pulling in the same direction, because there is an alignment of incentives. If you do that, whether you're a designer, an engineer, a product manager or a researcher, that's going to make your work much easier. Thank you.