In this episode of Quality Bits, you'll hear about so many aspects of building the right product. Lina's guest is Nadine Oldorf who shares her experience on stakeholder management, continuous discovery, working on writing user stories, or why there may be resistance from delivery teams when it comes to product feature building. You'll learn not only about building the right product, but also other topics like empowering each other.
Find Nadine on:
- Twitter: https://twitter.com/nadineoldorf
- LinkedIn: https://www.linkedin.com/in/noldorf/
Book recommendations:
Links to books are to Amazon and as an Amazon Associate I earn from qualifying purchases
Further reading recommendations for some mentioned concepts:
Follow Quality Bits host Lina Zubyte on:
- Twitter: https://twitter.com/buggylina
- LinkedIn: https://de.linkedin.com/in/linazubyte
- Website: https://qualitybits.tech/
Thank you for listening! Follow Quality Bits on your favorite listening platform and Twitter: https://twitter.com/qualitybitstech to stay updated with future content.
In this episode of Quality Bits, you'll hear about so many aspects of building the right product. Lina's guest is Nadine Oldorf who shares her experience on stakeholder management, continuous discovery, working on writing user stories, or why there may be resistance from delivery teams when it comes to product feature building. You'll learn not only about building the right product, but also other topics like empowering each other.
Find Nadine on:
- Twitter: https://twitter.com/nadineoldorf
- LinkedIn: https://www.linkedin.com/in/noldorf/
Book recommendations:
Links to books are to Amazon and as an Amazon Associate I earn from qualifying purchases
Further reading recommendations for some mentioned concepts:
Follow Quality Bits host Lina Zubyte on:
- Twitter: https://twitter.com/buggylina
- LinkedIn: https://de.linkedin.com/in/linazubyte
- Website: https://qualitybits.tech/
Thank you for listening! Follow Quality Bits on your favorite listening platform and Twitter: https://twitter.com/qualitybitstech to stay updated with future content.
Lina Zubyte (00:07):
Hi, welcome to Quality Bits, a podcast about building high quality products and teams. I'm your host, Lina Zubyte. In today's episode I'm talking to Nadine Oldorf. Nadine is one of the people that I go to when I have any product related questions. She's the person with whom I discuss building the right product, which I think is absolutely crucial if you want to build high-quality products. I'm very happy to present you today's conversation. It's a little bit of a slow burner. We get into so many important topics, so I highly recommend you to stay here until the end. From continuous discovery, stakeholder management, requirement analysis, or even what Nadine thinks about estimation, we head to book recommendations, mentoring and sponsoring. I hope you enjoy this conversation as much as I did and learn much more about building the right product.
(01:25):
Hi Nadine, welcome to Quality Bits. It's so nice to have you here because I think you're one of the most inspiring product people I worked with and I've learned so much from you.
Nadine Oldorf (01:37):
Thank you, Lina, and thank you for the invitation. I'm very happy to be here.
Lina Zubyte (01:43):
Wonderful. So could you please shortly introduce yourself?
Nadine Oldorf (01:49):
Yes sure. So I'm Nadine. I'm from Hamburg. I'm living in Hamburg. I'm a freelance product coach and I'm also working part-time as consultant at ThoughtWorks. And on my daily basis I'm coaching product teams, so individuals like product managers or product owners. I'm a mom, I have two kids. So at the moment all my hobbies are kind of on hold. I spend my free time mainly on playgrounds or I don't know, in Hamburg we have a lot of water, a lot of sea, so I'm spending it there, but one hobby I kept is enjoying a good book.
Lina Zubyte (02:29):
Nice. So we'll talk about the books a little bit later because I always get such good book recommendations from you, so I'm very excited to share it also with listeners. I wanted to start actually that you started as a QA and then you switched to product. What is the story of this switch and how do you like it?
Nadine Oldorf (02:53):
Yes, sure. So when I started at ThoughtWorks seven years ago, I joined as a QA. And on my first project I met a very cool business analyst. Laura was her name, and she was also coaching product to our client. And I was watching her doing her work and what I liked was all the conversations she had, doing the interviews with the users for figuring out what their needs, pain points, desires are. And then on the other hand, having also more difficult conversation with our stakeholders by convincing them what their problem actually is, what they want to achieve, helping them to do that. And then mapping both side, like the business side and the things from the users and come up with a really nice solution and with a really nice product. I wanna do that as well. So I asked her to shadow, and that's actually also the thing that I enjoy today the most. Doing all those conversations.
Lina Zubyte (03:56):
So there's lots of misconceptions about product. What are some of the misconceptions that you see every day?
Nadine Oldorf (04:06):
Misconceptions about product... In many companies, especially I think in Germany as I'm in the German market what is neglected is the discovery part. So people, the stakeholders, the business side, they come up with ideas. They're not talking to the users, they're not checking if this is the right problem they want to solve and if the solution would fit, they're just starting building it. And then after a while, after months, after years sometimes they notice it was not the right product, it was not the right solution. So from my perspective, discovery part is highly neglected in Germany, delivery principles, practices as well. But main part is the discovery.
Lina Zubyte (04:53):
Yeah, it's funny, I remember working in a consultancy and how we would speak that Germany is actually not really great with product innovation because if you look at the cars and there's lots of automotive companies in Germany, they haven't changed that much, right? In many years. And getting to work with some of those automotive companies, that's exactly what we could see, those rigid processes and little room for innovation,
Nadine Oldorf (05:22):
There's a misconception about discovery as well. So sometimes you do discovery work, so you have the fixed problem, you haven't checked if the problem is really a problem and then you do kind of discovery, brainstorming around the solution, but you are also not really checking the solution.
Lina Zubyte (05:40):
It's so common. It's a lot of people think that product management is basically building solutions while it's actually understanding the problems. If we actually learn more about those stages. So you mentioned discovery, we also mentioned a little bit of stakeholder management. What are the stages of building high quality products? So if you could start from scratch, what would those be?
Nadine Oldorf (06:05):
So there's the saying, you also know it: "Building the right product the right way" and it has two parts. The right product means it needs to be a good fit for the business. So it needs to meet your goals. So your business goals need to be mapped to one of your main outcomes. So this is the start point: alignment on your business outcome. What do you want to achieve? Then the next part is the users. Figuring out their pain points, their needs, their desires, and then you can start trying to figure out/map how can we solve the business goal, the business outcome with one of the designs, needs or painpoints. That and ideating on a solution and after you have the solution, you start testing, you can start the delivery and in the delivery as well. You still need to start questioning. You still need to have the doubt, not being a 100% sure, always have this mindset could still be wrong and go slowly doing some tests moving forward in small bits and pieces until you have the right solution. So you have the right product in terms of you meet the users, you are meeting your business goal and it's also built in a very nice high quality technical way.
Lina Zubyte (07:17):
There's so much there to unpack that companies tend to fall into this trap of all kinds of issues with what you've mentioned. For example, even small bits, small iterations how important the slicing is when we already work on it or even this question, are we building the right product to begin with? I worked in teams where sometimes if I asked already in delivery stage, which is quite far, but they would shrug the shoulders and they would say, well that's what I said so we will do it. And I think, yeah, proving that we understand the problem when we build the solution is extremely important. So where does actually stakeholder management come in here? So you mentioned alignment, you mentioned users mapping out the solution and then the delivery. So would stakeholder management come in alignment? Maybe it's also all over the stages, but mostly in the start?
Nadine Oldorf (08:21):
It's on all over the stages. The first contact is of course at the start of the alignment parts of figuring out what the outcome is. I, for example, have to do stakeholder interviews, figuring out what they are at the moment, valuing what is important for them, what are they care about, who are there actually, and how can they help me, can I get some support from them and truly understand their outcome or what they want to achieve. Some stakeholders are still in this output mindset. So they're telling you build future X, Y, Z and then starts questioning and figuring out, okay, what do you want to achieve with feature X, Y, Z? And if you have start interviewing your users or figuring out what they want to have, you still need to come back and explain to your stakeholder, okay, this was the outcome we agreed on. Here are my ideas from the user interviews, here is what your users are actually saying, how we could solve their problems and how it would meet your outcome. So on every stage, the contact to the stakeholders is important and getting their agreement and getting them on the way with you.
Lina Zubyte (09:30):
Has it ever happened to you that stakeholder wanted one solution but then the data showed actually that it's not the solution or that they didn't understand the problem?
Nadine Oldorf (09:41):
I can share one story, yes. It's not about a feature and a software, it's about the device. So we were building something for delivery people and the idea was that they have for example, smartphone and when they are loading that truck with the goods they need to deliver to hotels and other companies, they needed to scan the products and drive to their clients, to the hotel for example, unloading everything, get a signature so that everything was delivered and so on and so on. And the first idea was to use a device that has the size of a normal piece of paper, like A4 format, and we were testing it and you can imagine it's very, very unhandy. So the first thing the drivers were telling us, how should I use that? How can I put this on my pocket? It's way too big. And yeah, they already ordered a lot of those devices and we quickly figured out it's not usable. They cannot do this work with the device they had. And we could have figured it out if we had one device and started with one driver or two drivers and asked them: How would you use it? Would it be feasible for you?
Lina Zubyte (10:51):
And how would you tell these news to the stakeholder who thought that it's a great idea, the person who was involved in ordering that many devices, how did you approach it?
Nadine Oldorf (11:03):
The perfect way? If there's the opportunity, just get them with you, show them, make them do the work so that they notice or you can record a small video or otherwise you can just note the quote and repeat the quotes in meetings.
Lina Zubyte (11:21):
Yeah, I guess it's detaching the person from it more and just talking about the problem of the user and helping them learn about it, which is hard, especially when there's hierarchies involved.
Nadine Oldorf (11:35):
Yeah.
Lina Zubyte (11:36):
I've also seen that you've shared before about continuous discovery. What is continuous discovery?
Nadine Oldorf (11:46):
Continuous discovery is I would say framework from Teresa Torres. And the idea is that you have at minimum weekly touchpoints with your customers, with your users, can be 20 minutes interviews per week with a team that is building the product, not one person, but the whole team is involved. And in those interviews you're doing small research interviews, you can ask about needs, painpoints, desires, you can test your ideas, you can verify your assumptions and so on and so on, so that you are pursuing the business goal. So you're doing it every week continuously and you're not stopping also not when you are already in delivery mode, ongoing process.
Lina Zubyte (12:32):
And what would be the habits of continuous discovery?
Nadine Oldorf (12:36):
The main point is talking to the users on a weekly basis and having a product to you as well. Not only one person, not one product manager responsible, but having a team containing of a product manager, a developer, it can third person can be a QA, design can also be four or five people. But having this mixture of people, different perspective and then continuing talking to the users, figuring out what they need, how we can map it to the outcome and then go forward, start testing and building.
Lina Zubyte (13:11):
This is the three amigos. Product trio. That's the first time I hear it that way. Yeah, I really like three Amigos. Funny. I think now continuous discovery and the concept of it made me remember the book that I've just read. It's "Who Moved My Cheese?" Have you ever read it? So this is a tale about four characters who are looking for cheese in a maze. And they do find, oh my god, I'm spoiling the whole book, but they do find one room that has lots of cheese and then eventually there's no more cheese in that chamber. And how every character had different attitude towards that, how two of mice actually ran away and they just left the chamber and there was someone who just stuck there and sat and was grumpy about the cheese leaving. And basically they said, who moved my cheese? And to cut the story short, one of the messages that was "move with the cheese", so when there's certain situations in life change. So all this book is about change that we would adapt to change and move with it. So I guess continuous discovery is exactly this. So you'll learn new things about the business you're in and instead of staying with your old cheese and just sticking to it you are actually moving to new ways of work. You are adapting to the customers and building something new.
Nadine Oldorf (14:52):
Yeah, sounds wonderful.
Lina Zubyte (14:54):
So we spoke about stakeholder management and getting to know our users and mapping the solution. So how would you map the solution? Would you use user stories? What are the techniques that you like to use or you would recommend people to use often?
Nadine Oldorf (15:13):
My favorite tools for the whole process from discovery to delivery for the whole thing is story mapping. Because in story mapping you can add the goal, you can add personas if you want. You can think about process, the step that the users or different users need to take through your product and also start adding ideas. So this is one thing that I like and especially for mapping the opportunity space in the discovery path, I like to do the opportunity trees where you have on top the main business outcome that you want to achieve. And beneath that you map all the quotes that you hear from your users that could help you achieve the goal. For example, if we are doing a video streaming example: one business goal could be increase watching minutes. And then one quote you could hear from a user is "my show ended while I was when I fall asleep" or "I haven't watched all my favorite shows".
(16:14):
So some stories you hear in the interviews and then you can think about, okay, or favorite shows, watch what could be built to make the user watch even more. So it sounds like a recommendation tool. And this is something I would like to use, you're not focusing on one single opportunity, you are study mapping. You are looking very, very broad and then you can start deciding for the first opportunity, go forward, do quickly testing. And if it's the wrong one, it doesn't matter because you can always go back. You have to drill, you can just choose the next one. And the idea is to get comfortable with decision making because you are doing very small tests going forward on a fast pace, small iterations so that it's not a pain if you are wrong. If you figure out in testing and delivery, it was a wrong decision. Let's go back. It's a two-way decision.
Lina Zubyte (17:05):
It sounds really adaptive to have opportunity trees and to be up to the market. What it makes me think is as well the delivery side of things, that there is this common stereotype and reality that engineering teams may think that product are again bringing in new features to build. What's your opinion on this? Could it be done in a nicer way or what is the problem here? Why a lot of teams have this resistance? Do you think that product people in the teams could do a better job or it's a two way thing?
Nadine Oldorf (17:47):
Do you mean the resistance towards building new features?
Lina Zubyte (17:51):
Yeah, because sometimes also we find new requirements and people get somehow stressed out about new things to build and they're like they haven't made up your mind.
Nadine Oldorf (18:04):
Yes. Two thoughts on this. First what we already mentioned is that in many companies the discovery part is done poorly. So some person is deciding we are building future X, Y, Z, so there was no discovery. So yes, the routines are actually good by questioning it. And the second thought I have is that the communication is done poorly so that you're not explaining where you're coming from, that you're not doing all the way, why are we doing it? Because we want to achieve the business goal. Why do we think the solution or this feature is the right one to do that? Because we have done our discovery part, because we have data to show it's a good opportunity, it's a good approach to go forward and still product teams do the questioning until you have a good feeling that it's a good approach to go with a solution.
Lina Zubyte (19:00):
I guess it's a psychological thing, trust your gut, trust your feelings, and if the delivery team is actually upset about something, there's likely something going on there. And as you say, there's a communication problem or motivation is not clear. Come to think of it, I remember working in a team with you and you would bring up product things that we would be working on with the PO and it was always so relaxed it was never some kind of push from the sky thing. We would just sit down, I remember in a circle in the room and we would discuss and everyone would ask questions and infrastructure consultant would be like, so why are we doing this? And I really liked it. And sometimes I think it's a lot about psychological safety as well and having some kind of background data because each time we asked you, we knew that you were going to give us the answer or you will figure it out. So you will write it down and say, huh, good question, open question, I'll figure it out. I think that helped a lot.
Nadine Oldorf (20:07):
My thought, my opinion in product in general or software delivery in general is there's no room for egos.
Lina Zubyte (20:14):
Oh, I love it.
Nadine Oldorf (20:16):
You need to embrace the different perspectives. You need to embrace being questioned. Although it feels uncomfortable. Yes, of course if you wrote the stories, you're ready to go forward. You are sitting in backlog grooming or planning or whatever you call this meeting. And then the developers question everything that you did so far. It just means okay, you haven't communicated well before this or you should involve the developers a little bit upfront and it's hurtful at this time, but you can only learn and move forward.
Lina Zubyte (20:51):
I actually recently just published the requirement analysis article and was one of the longest ones I wrote for Quality Foundations because there was so much to write there and I still couldn't write everything. And it was about the stage where we're questioning the requirements we get and I am wondering if you have any advice here, how could we make better requirement analysis before we even start developing?
Nadine Oldorf (21:22):
Again no room for ego, so please don't do it on your own. You can use three amigos product principle type so that you get different perspective before something goes and delivered before you even start a story. My personal approach because I'm actually not able to pair when I'm writing: when I'm writing user story, I need to do it on my own. I cannot think when somebody's sitting next to me and watching my fingers. So I start doing the job but I'm not finishing it. I'm finishing it to an extent that I have no idea what to add anymore, but it's still have open questions, still room to improve and then get it out there. Ask your QA, ask your developers, ask your designer, ask the security champion whatever role is important and get feedback very early on even before you go into backup remain or planning.
Lina Zubyte (22:17):
Yeah, I think that's what I remember as well working with you and I really appreciated that because this somehow aligns with this concept of shifting left because we would actually think of quality and building the right product before we even start the delivering before it's too late.
Nadine Oldorf (22:36):
Yes.
Lina Zubyte (22:38):
So let's imagine the case that requirements change in delivery and it does happen. So sometimes something may change. What do you do in this case?
Nadine Oldorf (22:49):
Breathe. Like first thing is always breathe and then come together again as a pair, as a triple, as a quartet, how many people you feel comfortable involving at least product and QA. And then you need to decide if you still want to go forward with a story which is probably in play, if you need to kill it or if you just need to pivot as doing a small tweak, which can be probably done in the next story. In case you need to kill it completely in the future - I think it's okay. Breathe and get comfortable with being wrong. We don't like being wrong. Nobody likes to be wrong, but we need to be comfortable. And if you're doing your job good, if you're doing discovery part, if you're doing delivery and small bits and pieces, not much time should have passed. So it's okay being wrong. And starting from stretch, you probably also have the opportunity tree you can choose. That's the next one. Use the next user interviews to check if this one, the next opportunity is a good one and start from scratch. And you probably also have some good reasons for killing it. So you can also communicate that in a good way why you thought it's a good one, why you noticed it's probably not a good one. And yeah, you made the decision to kill it.
Lina Zubyte (24:00):
Actually we don't see this killing... Well, this sounds funny.
Nadine Oldorf (24:05):
No, nobody's doing it or nobody feels comfortable doing it if you also often leave the feature.
Lina Zubyte (24:11):
We don't see it that often but I guess we should see it more often. So it would be more used to it as well. This failing fast and learning and this is directive. So you mentioned actually small bits and pieces and slicing. I've seen so many user stories, which like, I don't know, a list of 10 acceptance criteria. What are your thoughts on this? Or do you have any tips how to make stories smaller? How do you decide what's the size of it?
Nadine Oldorf (24:41):
Oh, that is complicated question and actually depends on the topic. So what I like to do is getting to the bones, the bare skeleton that the feature needs to get live without any extras and implementing that. And then you can start making it nicer and more usable. But it really depends on the topic.
Lina Zubyte (25:03):
Yeah, I think I really like getting to the bare bones of things. Another thing that pops up often in delivery is estimation. What are your thoughts on estimation?
Nadine Oldorf (25:18):
I don't like estimation, I'm not a fan of estimation. I can understand why we are doing it because we want to have an answer to the question, when are we done, when are you ready? When can we put it live? So you want to have an answer to that. And we are doing it by putting a random number on a software piece, right on the feature and it's an estimation and there is this oxymoron about accurate estimation. So what I prefer doing is to get an answer to the question: when are we done? It's measuring, so on average how many, I call it tickets becomes, it can be user stories, but tech tasks, ops tasks, like the mix, how much can be done in a week for example, or in the iteration you can measure it for some iterations and then you can start doing the graphs. Figuring out for the whole feature. We probably need, I don't know, we have 20 tickets to be done in total we are achieving five per week, so it's four weeks. And then I'm having this conversation with stakeholders on weekly basis again, but even more. And also telling them, okay, we are a little bit behind cause somebody was sick, somebody was on vacation, somebody left, we need to onboard someone new. Yeah, it can all lead to delays, but it's still more accurate than just putting a random number on a feature.
Lina Zubyte (26:50):
Yeah, I really like this. I mean I've been in situations where a stakeholder or someone from management would ask the team without talking to product person. Would you feel like product person in the team is someone who's shielding the team from all these questions and most educated likely to answer and/or knowledgeable about the estimation or how the team works?
Nadine Oldorf (27:16):
Kind of yes. But then on the other hand, I also like what I said, no room for ego. So I think it's again like a trio pair. But yes, the product manager, product owner is the person who communicate the product person is the one who gets the question, when are we done? So yeah, they need to have the answer and they need to figure out how they want to answer it.
Lina Zubyte (27:41):
Yeah, that's really nice when we have a good ally on product side. So you mentioned no room for egos multiple times we're talking about this. I know that you're really into mentoring, coaching also non-male empowerment. What's a recent learning you have in this topic?
Nadine Oldorf (28:05):
So I can share one of my personal coincidences that happened a few months ago. I'm also a freelance product coach and I'm just at the beginning I'm starting and I wanted to learn from the person, her name is Petra, who is actually already where I want to be. So she's a really cool product coach and I wanted to meet her and there was this conference MTP engagement and I knew that she would be there because she's curating it. So I went to the conference, I already also saw her, but I couldn't go over there and say, hi, I'm Nadine, can I talk to you? I I would like to get some insights, I need your help. And after the conference at home I thought, oh my God, why are you not brave enough? Why couldn't you just ask her? She's probably a nice person.
(29:00):
So what I did is writing her on LinkedIn and to my surprise, she answered within 10 minutes or so and we had the conversation then via Zoom remotely. It was such a great call, she gave me so many tips and shared her stories. It was really, really cool. And I learned that we need to support each other. So again, no room for egos. Go talk to your competitors. You are all in the same boat. And if one person is already very experienced, they probably have a lot of clients and then they could probably share them with you. So if they have to say no to their new request, new people they can say, but hey, I met a new person. So here, talk to her. She's also very nice, very good. And another fact that I learned is that a lot of minorities are over mentored, but unsponsored. Sponsoring means getting the opportunities, getting suggested to conference talks, for example, or panel meetings or for work, getting the position within the company, getting promoted. So a lot of people are getting mentored, a lot of people share their knowledge with minorities, but less of them get them into position or share the opportunities in getting them sponsored.
Lina Zubyte (30:28):
This is also not just being available for someone to talk this mentoring part, but as you say, giving a seat at the table or lending your privilege saying here, I'm not taking this, why don't you take it? Or maybe I'll take something else. So I think it's a great chance for you to do it. This empowerment is so powerful and we don't think about this lending of privilege very often.
Nadine Oldorf (30:52):
Yep, exactly.
Lina Zubyte (30:55):
Actually from you, I have learned more perspectives about this empowering others. I remember once we spoke how sometimes as women in tech we may actually be mean to other women in tech. Do you remember that?
Nadine Oldorf (31:11):
Yes. Probably I should share my background. So I studied physics and you can probably imagine that physics is not a subject where you can find a lot of non-male people. When I started, I think we were 20 women in a group of 150 men and it felt quite intimidating. So what you're doing is that you are start adapting behaviors that you get how males are treating you as a woman and a subject where they think you don't belong. You're starting doing the same. And what I noticed on my own behavior that when I finished my studies and I was working for the university quite a long time, that I always had the thought I had to fight here, I survived this, so let's check if you can do the same thing. And I noticed this long after that happened and I really hope that I treated them in a good way at the end, but I cannot be sure. And after I realized it, I changed completely. So at the moment I'm always putting my non male colleagues upfront and share the opportunities with them, share my knowledge with them. I sponsor a lot because there are lots of seats at the table there, enough seats at the table for all of us and we don't need to fight against each other.
Lina Zubyte (32:51):
It's really inspiring to hear this, our time is running out. So I wanted to ask you about the topic that you're really passionate about. I've gotten lots of great book recommendations from you. So what are some of your favorite books or recent reads that you really liked?
Nadine Oldorf (33:13):
Yes, so I can start with product book recommendation, like there too, I think everybody should read "Inspired" by Marty Cagan and "Escaping the Build Trap" by Melissa Perri. They're not general, but really good books to get you into this product mindset. If you want to get more specific on different frameworks and tool links like the one I mentioned about story mapping, there's a really good book by Jeff Patton. I learned so much about writing user stories and how to do story mapping. It's an amazing book. And the other one is from Teresa Torres and Continuous Delivery. So this is from the product part. And at the moment I'm reading "Non-violent communication" by Marshall Rosenberg again because it's also really a nice tool to do stock stakeholder management and getting out what their needs are like from the business side and what they want to achieve. And because the framework is sometimes a bit hard, I like to reread it.
Lina Zubyte (34:14):
You're also a mom. Are there any books that you're reading about raising children that would be interesting and related to the things that you care about?
Nadine Oldorf (34:26):
Yes, I do that too. So my kids are one and four and we are living in a neighborhood who is not that diverse. So I'm also thinking about how I can make my kid be aware of different people and different ways of living. So what I read a lot on is how to talk to my four-year-old son about gender, for example, and how to talk to him about racism because he will hopefully meet more diverse people here in Hamburg. And I want him to be aware about what that means and how to behave in a proper way.
Lina Zubyte (35:10):
And was there anything in this book that you could share as an example?
Nadine Oldorf (35:16):
About gender? Yes, I can start with gender because it's at the moment for me, the more easy I want to talk about. So when he's saying, oh, this is a girl and this is a woman, I always ask him, Hey, how do you know? And then he's for example saying, oh, because she has long hair. And then I'm saying, okay, yes, a lot of women have long hair, but they can also have short hair. Look here like the grandma of your friend, she has short hair and on the other hand, males could also have long hair. So making him aware that this is not how you recognize a woman when it comes to race. When we are sitting in the subway and people of color are sitting on the subway and he's asking, Hey, why is this person have a different skin color? I learned that one way to explain it to children is that you say is there's a hormone in our body, everybody has it, it's a melanine and it depends how much melanine you have in your body, how your skin color looks like. So we have not enough, so our skin is quite tight and people of color, they have more melanine. So making it very natural.
Lina Zubyte (36:37):
Wow, I guess a lot of adults are going to lacking this knowledge and it's amazing how you see this little toddler as someone who's also thinking and worth explaining things or questioning things, right? So you're asking as well to understand the cause. I think that relates to your work and stakeholder management and communication because you try to understand rather than just say, Hey, this is the thing I do. I love the parallel there. So this has been an amazing conversation. We spoke about all kinds of different topics here from products shareholder management to even empowering each other or how to raise more socially conscious kids. So to circle back, what is the one advice you would give for building high quality products and teams?
Nadine Oldorf (37:33):
I cannot emphasize enough on it. Talk to your users on a regular basis.
Lina Zubyte (37:39):
Nice. So then this beautifully wraps up our conversation, so if there's something you should remember from this is talk to your users and thank you so much, Nadine, for joining me here today.
Nadine Oldorf (37:56):
Thank you Lina for having me.
Lina Zubyte (37:59):
Wow, what a conversation. There was so many different topics and I am not even sure if we scratched the surface of building the right product. I'm sure we will have to dig deeper into lots of aspects that we heard about today. Thank you so much for listening. As usual, I'm looking forward to your feedback, subscribe and let me know what you think of this episode. I will be adding all the book recommendations and resources into podcast notes as well as Nadine's contact details. Thank you again, and keep on building those high quality products and teams. See you next time.