Dr. Nesrine Changuel credits innate curiosity and a personal motivation for unlocking new knowledge as the catalyst that has brought her to Nokia, Microsoft, Spotify, and now Google. Her career journey has been thoughtful and deliberate, first as a researcher and later a transition to product management.

Nesrine explains how a growth mindset encourages learning – and the confidence that comes with it – that allows us to break out of our comfort zones to grow as individuals and product leaders.

The key to success, Nesrine adds, is never forgetting what the problem is. “Fall in love more with the problem than the solution,” she says. One way to achieve this mindset is to have a very clear product discovery roadmap that is distinct from your execution roadmap.

The discovery roadmap outlines a list of problems – not solutions. It leans on her experience as a researcher, generating incredible value validation that includes lots of time engaging with users to understand their challenges and pain points. And it’s work that brings together the product trio: product manager, UX researcher, and engineering to deliver products that improve users’ lives.

Be sure to listen to the entire pod; capture in minutes some of the vital nuggets Nesrine Changuel has picked up as her career continues to unfold, including:

• Failing fast during product discovery: taking educated risks, validating them through regular, rapid feedback.
• The power of iteration: the ability to stop, inspect, and adjust.
• Avoiding the Scrum Fall Trap.
• Using data to distinguish between what users say they want and what users actually do.

Product Collective’s Mike Belsito returns to emcee the 2023 ITX Product + Design Conference. Save the date: June 22-23, 2023 in Rochester, NY. Learn more.

Podcast: Play in new window | Download

Paul [00:00:19] Hello and welcome to Product Momentum, where we hope to entertain, educate, and celebrate the amazing product people who are helping to shape our community’s way ahead. My name is Paul Gebel and I’m the Director of Product Innovation at ITX. Along with my co-host Sean Flaherty, and our amazing production team and occasional guest host, we record and release a conversation with a product thought leader, writer, speaker, or maker who has something to share with the community every two weeks.

Paul [00:00:43] Hey, Sean, how are you doing today?

Sean [00:00:44] I’m doing great, Paul.

Paul [00:00:45] Awesome. I am jazzed up about the conversation we just had with Dr. Nesrine Changuel. She had a ton of experience in the product space and I think it was emblematic of how many product managers find themselves in a career in product coming from somewhere adjacent, just the anthropology of how people find themselves in this career that we call product management.

Sean [00:01:07] It’s wild, right?

Paul [00:01:08] What were some of your key takeaways?

Sean [00:01:10] Well, the first one was around great product careers, right? We talked about her journey, but her decisions were really around a growth mindset.

Paul [00:01:18] Yeah.

Sean [00:01:18] So her journey through product discovery was one of my top takeaways.

Paul [00:01:22] Yeah. It was a really dense conversation, lots of process and mindset conversations about how there is no silver bullet, but when you can catalyze a team around a product discovery and continuous delivery mindset, you can unlock greatness.

Sean [00:01:37] Her contributions and the way in which she shared knowledge from her time at Spotify was fantastic. And I love the concept of the Scrum fall trap. We talk about it a lot but really articulating what it means and why we fall into it. This is just a great podcast.

Paul [00:01:50] Something for everybody. Let’s get after it.

Sean [00:01:52] Let’s get after it.

Paul [00:01:56] Well hello and welcome to the show. Today we are pleased to be joined by Dr. Nesrine Changuel. Nesrine is a product manager at Google, formerly at Spotify, Microsoft, and Nokia. She’s managed highly visible consumer products over the last ten years, including Chrome, Meet, Spotify, and Skype. Before turning into a product role, Nesrine worked as a research engineer at Bell Labs, Nokia. She holds a Ph.D. and Master’s Degree in electrical engineering. And not only that, she’s spoken at a variety of international conferences and held multiple tech patents in her name for her innovations. Nesrine is active among product communities, passionate about sharing her experience, and loves promoting product management as a career. Nesrine, welcome to the show.

Nesrine [00:02:34] Hi. Thank you. Thanks for hosting me.

Paul [00:02:36] Yeah. So just kick us off, your product journey has taken you down a really amazing path. Lots of amazing, innovative names in your resume, from Skype to Spotify and now Google. How much unlearning, I’m curious to know, did you have to do between those big organizations as steps in your career, compared to how much of your experience translated one-to-one as you grow throughout your career?

Nesrine [00:03:04] Sure. So actually, let me start with the beginning. When I changed a job for the very first time, it was so hard, both mentally and physically, like accepting to get out of your comfortable quotidien and getting to prepare interviews for something that you completely don’t know was terrifying. But at the same time, it was very exciting because in my case it was fully driven by curiosity and by my personal motivation for unlocking and expanding new knowledge.

Nesrine [00:03:34] So to be specific about this question, a successful change is very rewarding. So what kept me doing it again is the fact that it’s very rewarding. Of course, you get the chance to significantly increase and enlarge your network in a very strategic way. You also increase your skills, your learning capability, and you validate to the world your ability to learn and to know new skills. But I would say the most interesting part of changing jobs is you get more references. So you compare your present to the past and you get to know more what you want to do more of and what you want to do less of.

Nesrine [00:04:12] But at the same time, a successful change has to come with some rules or some costs. So I would say the very first rule in my case is, of course, let’s say it has to have a meaningful continuation. You can’t just hop from one job to another. So in my case, I’m an expert in media. So I was trying to change companies, but within the same domain, like Skype, Spotify, Google Meet. So that’s something that you could value when you move from one job to another. The second thing is, of course, it’s about the good start. If you want to have a good transition, it’s very important to get a great quarter start. So in my case, I was fortunate enough to get to know a very interesting book. It’s called The First 60 Days, I think. It’s an amazing book because it gives you good tips on how you could validate those first 60 days to set yourself up for success, like finding alliances or gaining the trust of your team, et cetera.

Nesrine [00:05:11] And the third bullet I want to highlight for successful job change is, of course, no hopping. But what I mean by no hopping is that you’re not supposed to change jobs within a year or two. So in my specific case, I never spend less than four years lucky, either at Nokia, Microsoft, Spotify, and now I’m currently at Google. And the reason is because it’s very important to value what you learn. So most of the time, the first year is about learning. The second year is about productivity, and the third, fourth are more about promotion and validating what you already acquired. So jumping, let’s say less than two years most of the time is not an interesting career change.

Sean [00:05:51] If I could pull on that thread a little more, what is the decision structure that you’re using to determine where you’re going to go next?

Nesrine [00:05:58] Yeah, a lot of it is driven by the network itself, [inaudible] to extend. Like, for example, I get offers. I get to learn what the offering is about, what will be the benefit compared to what I have today? Is it going to let me gain more knowledge or let me learn more skills? So most of them have been offered, not me looking for them, let’s be honest about that. And then the motivation is, of course, sometimes driven by the feeling of being bored. This is very personal. I’m not saying that everyone will feel bored after three or four years with the same career or the same role but usually most of the time, after validating those three first years and getting to the level of productivity I want to achieve, I’m very motivated about getting something new, and if I’m not able to get that something new within the same organization, I will definitely explore outside my organization.

Sean [00:06:50] So I think the profound thing there is that for you, and I think this is the case for most product people that have been successful that I’ve come across, it’s about the learning.

Nesrine [00:06:59] Yes.

Sean [00:06:59] Continuously learning and growing and finding opportunities, not just for yourself, but for your ability to contribute to others’ growing and learning.

Nesrine [00:07:06] I think, as I mentioned earlier, the first year is so rewarding in learning that you very quickly miss it. So when you get to your third, fourth year within the same company, you miss that very intense learning experience within the first year and I always look forward it to renew every time.

Paul [00:07:24] You used the word learning at least a half dozen times in your answer. And I think that that comes through clearly. In the talks that you’ve given, you are clearly passionate about leveling up the community as a whole and helping others both break into the product management path, as well as grow and level up the careers of those already in it. Can you tell us a bit about how you just came to be such a natural teacher, whether it’s something that you sought out or just an innate drive? What about this practice of helping others around you is important to you?

Nesrine [00:07:52] I think this comes from my background. So I started my career in research, as you already mentioned. So 15 years ago I used to be a research engineer, and as a researcher, the work actually consists of being active within the research community. It’s actually part of the work. It’s not like extra work. So it’s about innovating and sharing your innovation to the community to get feedback and to learn. So the learning aspect or expertise that I have comes from the fact that I’ve been a researcher for quite some time. And during my five years as a researcher, I published like 18 research papers. I’ve been in international conferences many times and that was just part of my regular job.

Nesrine [00:08:35] When I moved the role and I quit the research to become like a PM role, being active in the PM community was not part of my regular job. It was not mandatory. I was so much focusing on learning PM skills by myself that for seven years after quitting the research field, I never gave it any thought. I never took part in the PM community, and it was until a day where I was reached out to by my engineering school and they just asked me if it’s okay to come and present, what’s the PM role? for the students within their student forum. And it was an easy ask, so I did it, but I also enjoyed it a lot and it just immersed me back into that sharing and presenting area that I used to enjoy a lot. So I did it a couple of times. I presented the PM role in many universities, like in France and in Sweden, and things went super fast. Like by doing that, by being active in the community, I was reached out to by a lot of events to give talks in conferences, podcasts, of course, as today, participate in blogs, and I actually value it a lot now that I’m becoming extremely active, I try to be as active as I can because it’s also in parallel with the PM’s regular work. But it’s so rewarding from the learning perspective, as I said earlier, but also now I value a lot the networking part of this community participation, so it’s very rewarding.

Paul [00:10:10] I have one more follow-up on that because you talked about this almost serendipity event where your university reached out and it catalyzed you into this public speaking career. Did public speaking come naturally to you, or was it something that you had to overcome? It seems like there was a moment in time when you felt like you were just growing yourself internally, and then there was a catalyzing event when you were asked to come speak, and then you really started to grow your public speaking career over the course of the pandemic. What did you learn about yourself and what it’s like to be a speaker in this space?

Nesrine [00:10:42] Yeah, it’s very interesting because one piece that I wanted to also share here is that the beginning of my second phase of public speaking came exactly at the same time of the beginning of the pandemic. So at that time, most of the events and conferences went virtual and that for me was a very big bonus, a very interesting point, because in order to get back to the stage and get back to public speaking, it’s a lot of effort. But since all of those have been virtual, it’s actually less of a stress so that I only have to focus on the topic, on the importance and the value of the content, and less, of course, on the audience and the stage itself. So I think it’s a story of coincidence and serendipity, as you mentioned, that made my come back to the community easier for me. But I’m not saying that it’s going to be easy for all. It’s a lot of effort and it’s very important to have a strategy for it, like, “how can I start? What’s the baby steps I need to take first? And what do I want to get in two years’ time? So what will be my contribution I will be happy about in two years time?”

Paul [00:11:49] Love that.

Sean [00:11:49] Yeah. So along the same theme of learning in terms of the people that you surround yourself with in your own personal learning and growth, you know, Paul and I are particularly intrigued by your time at Spotify, so I’m going to ask a couple of questions along those lines. Like, one thing that Spotify is known for is sort of their emphasis on iteration, making fast mistakes, and really autonomous teams, like giving people the ability to learn and grow on their own. And we’re curious, how much change management and curation of the Spotify framework was done purposely or how much of it was like truly democratic experimentation with process? How did that unfold while you were there?

Nesrine [00:12:29] Absolutely. In my opinion, and that’s my opinion, I don’t think there is such a Spotify framework, as we call it now. It’s more as principles and values. So people working at Spotify really work and live by the principle and value of the company. And by the way, there is a famous quote by Daniel Ek, like the founder of Spotify. He said that “we aim to make mistakes faster than anyone else.” And during my time on Spotify, we really worked and executed by the fail fast principle.

Nesrine [00:13:00] Let me give some examples and share some of what we had been doing that time. I’d been at Spotify for about four years, and fail fast, for me during that time means taking risks, but not taking risks, like, randomly, we have to plan. We have a very clear plan to validate that risk. It’s very important to validate it early as well, through regular and very fast feedback from the end user. So that’s also part of the iterative process. So iteration is not about using Scrum or Kanban or any of the specific Agile methodologies, iteration is about being able to stop, you inspect, and you adjust. And the adjustment is going to be based on user feedback, and most importantly, it should be evaluating your initial hypothesis because sometimes we stop, inspect the solution, and continue to improve it. And sometimes people miss the step of getting back to your initial hypothesis and asking yourself, “was it the right hypothesis or should I just pivot to a new direction?”.

Nesrine [00:14:01] By the way, something that surprised me a lot during my Spotify time is when I joined, all squads had been using and operating differently, like they had been using different methods. Some are using Scrum of our using Kanban, of our using like XP, like, extreme programing, and at the same time some are using physical boards for the daily, some are using JIRA, Trello, or just like a spreadsheet. What matters really is that the team defined the right way that worked best for the team. So this is also just to highlight that iteration is in the discovery, is in the execution, but also in the ways of working. So this is just to give you some answer regarding this methodology or these principles and values that everyone has been living with.

Paul [00:14:48] I have one follow-up because I think that that summarizes really clearly almost the whole body of work that you’ve been putting together in your talks and what you’ve been sharing, that delivering value is not a process per se, it’s a mindset of the team. It’s not something that you can plug in or find a silver bullet and solve all your problems. Talking back to your research roots, you have a clear connection to the people on the other side of the problem that you’re solving, and that value delivery isn’t just a framework that you can install. It’s a continual mindset that you have to cultivate and grow within a team. Is that fair to say?

Nesrine [00:15:25] Absolutely. I agree with you. There’s no perfect process. It’s absolutely not the process, it’s more of the techniques. And also it’s about being aware not to forget what the problem is, but to solve and fall in love more with the problem than the solution, as we say. But maybe I can share some of the techniques and the things that have been extremely helpful throughout PM career to build successful product. The very important thing that I kept doing for many years is having a very clear discovery roadmap. Sometimes we end up having like one roadmap that emphasizes everything and we don’t know exactly, what’s the execution roadmap, what’s the discovery roadmap? The importance of having a discovery roadmap versus an execution roadmap is that’s not going to be a list of solutions. The discovery roadmap, in my case, is more a list of problems: “what do we want to solve?” Because we haven’t reached the solution discussion yet. “Is it really a problem? Is this something we should solve for?”

Nesrine [00:16:25] So having a clear discovery roadmap is very important. And during that discovery phase, it’s a lot of value validation: going and reaching out to the user, asking them a lot of questions in order to understand, what’s their pain point? What’s their challenge? Is there really a problem we need to solve for, or not at all? And during that discovery, I personally as a PM work very closely with UXR, like user researchers. I work with a lot with designers with eng. That’s all about validating, first, the value, validating whether it’s going to be usable or not. And that’s why I need a lot of the designers’ help, and, of course, the feasibility. I mean, a great solution needs to be feasible and that’s why, like, working with eng counterparts is extremely important. So during that discovery phase, we’re going to be addressing those risks and we’re going to be trying to understand if a potential solution is going to be possible or not.

Nesrine [00:17:22] And regarding the operating model, of course, the entire process should be iterative and the iteration sometimes is more emphasized into the execution, a less into the discovery. So when we do discovery, we do iteration in the sense that, as I mentioned earlier, like, it’s a lot about validating hypotheses and making sure that the problem is still a problem for the personas that we are solving for.

Paul [00:17:47] Hey folks, please excuse the quick break in our conversation, but I have some exciting news to share with everyone. Save the date: it is the ITX Product and Design Conference. We’re back, so mark your calendars. It’s going to be June 22nd and 23rd, 2023, right here in Rochester, New York. Also back for this year’s conference to M.C. is the one and only Mike Bellsito of Product Collective. We’re going to have workshops, keynotes with industry thought leaders, opportunities to network with fellow product and design professionals. It’s just going to be a great environment and we’ll be right in the heart of all the action during the opening weekend of the Rochester International Jazz Fest. We’re still working to finalize the speakers for this year’s lineup, but to give you a taste, last year we had Adam Lawrence and Mark Stickdorn, who were also guests on Episode 87 here of the pod. They talked to us about service design. We had Cindy Alvarez, the Director of UX at PowerPoint and the author of Lean Customer Development, and she gave a workshop on conducting better customer interviews. And Holly Hester-Reilly was also there. She joined us on Episode 33 of the pod. She shared a Day Two keynote on ways to leverage continuous discovery to become a high-growth product leader. So whether you choose the product track or the design track, there’s something for everyone. If you want to learn more, head over to ITX.com and there’s a link right at the top of the page. You can register to stay in touch and also check out the archives from 2022. All right, back to the conversation.

Paul [00:19:12] So one thing that I love that you’ve woven into many of your talks is the difference between iterative processes and incremental delivery. And even though, you know, it would take probably another 20 minutes to unpack all the implications of those two kinds of mindsets. On one side, you’ve kind of captured the, you know, sometimes it’ll be building a rocket ship and you start with the fuselage and then the fins, and all along the way you have a nonworking product until the very end, as opposed to the bottom iterative approach where you have a kite and then a plane and then a jet, and then finally a rocket. And it’s a continuing iteration of an MVP along the way. You’ve spent a lot of time unpacking this. Can you give us one or two sort of practical takeaways that, you know, a product manager mid-career might be able to bring to their teams today in a refinement if they’re running something to help deliver value? What’s a mindset shift that they can take away practically in one of their interactions with their team right now?

Nesrine [00:20:10] Yeah, absolutely. I think the best question that the PM should ask herself or himself about is, like, how might we improve a user’s life? Any process or any great process that you will be using has to build for that question or has to operate with that question. So every time we are executing, all the process phases and all the iterative phases should always come back to that question: Are we solving for the users? Are we improving users’ lives? So when I spoke about, like, iteration is not incremental, process is not an iterative process, it’s because it’s very often we see a lot of teams falling into what I call the Scrum fall trap. So the Scrum fall trap is a way of operating where we actually operate with Scrum, but you end up incrementing to your product. You’re not offering yourself the opportunity to question whether your hypotheses are valid or not, whether your building is exactly solving what the user needs or not. So this is the most important piece: asking ourselves: Is this something that user needs or not?

Nesrine [00:21:16] By the way, I want to emphasize more the importance of UXRs because UXRs are telling us a lot about what the user wants. However, I did not mention anything about the importance of data, and data is extremely important because that’s what’s going to tell us what the users do. And sometimes we see a difference between what the users are asking us for and how the users end up using the product. So it’s very important, especially as a PM to get insight from UXR to understand what the user really needs, and at the same time, cross-check with data to see if there is alignment, if users are just lying to us by telling us that they want this amazing feature, or it’s exactly solving for their problem. So the best way to cross-check and check the value you’re bringing is to have alignment between what the user wants and what the users do.

Paul [00:22:12] Love that.

Sean [00:22:13] Excellent. All right. So we’re kind of close to the end of our time together, and I’ve been collecting sort of takeaways for the audience because my job is to extract as much as we possibly can from your beautiful mind and make it useful to our audience. So I’ve got some things I’ve captured. I’ll do a couple and then I’ll give you a chance to reflect, sound good?

Nesrine [00:22:31] Absolutely.

Sean [00:22:32] Awesome. So the first thing I captured is that great product careers are really built around a growth mindset, not just your own personal growth, but also your ability to contribute to the growth of others, and being part of a community that’s really, truly, authentically committed to shared growth and learning. The second was, you know, in your time at Spotify, all squads actually used different tools and processes. It’s less about the process and more about having shared principles like fail fast. So the third thing is about constantly reevaluating your hypotheses. And I love the little moniker there, I don’t know if that came from Spotify, but, stop, inspect, adjust, so that you make sure that you’re asking the right questions, really.

Nesrine [00:23:11] Yeah, a great summary. You got the great bullets.

Sean [00:23:15] Okay, so the fourth one I got was the iteration should also be about ways of working. Like we’re obviously always thinking about iterating on the features and the problems and the customer and that sort of stuff. But we don’t stop to think about, “Hey, how is our team actually working?” Number five, have a clear discovery roadmap that does frequent value evaluations, like, is this a problem we should be solving? I’ve seen a lot of teams fall into that trap of just building what we’re told to build or, you know, taking this piece and iterating on a feature, but is this feature even valuable to the customer? Number six, What will improve the user’s life? I just love that question.

Nesrine [00:23:52] I mean, I fully agree with the summary you’re coming up with. One thing that we did not mention at all, but I think it’s very, very important and it’s extremely aligned with the improving user’s life, is the delightfulness part of your product. I have been working a lot like, especially in Google Meet, on, how can we bring delight to the video conference? Video conferences are not known to be delightful, and how can we make that delightful so that we are out of being bored, being engaged, and actually delightful products are a big driver of engagement and activation. So there is a high correlation between delightfulness and engagement. That’s a very, very interesting piece that could be aligned with improving users’ lives.

Sean [00:24:40] I love it. The Scrum fall trap, you know, we hear about, you know, water Scrum, Scrum fall, we talk about it, but I don’t think too many people really put thought into what it means. And I love the way you kind of framed that it’s about striving for iteration versus this incremental improvement. Kind of like Paul described it beautifully with the rocketship and the kite and sail. We got to like step back, look at the bigger picture, and figure out, “could we iterate here completely on this feature?” Which really goes back to the earlier point about always be testing your hypotheses. So I love that. And then lastly, don’t underestimate the power of user research. Like, you got to have a practice that’s evolving around really asking the hard questions and getting out there and observing what customers actually care and say and feel, so…

Nesrine [00:25:26] Yeah. I mean, not everyone has the luxury of having a UXR, like a user researcher. I do, and I really value a lot that luxury. That’s why we’re working very, very close. Like I think UXR and PMs need to work like hands and hands. We do our planning together, we do our discovery roadmap together. I mean a lot of PMs do the user research themselves, but UX are trained, they have tools, they know exactly how to do that with the right words. Even the questions, the way how you ask the users are appropriate and they are very well-trained to do the right user research. So that’s why, like, if you have the luxury to hire a UXR it is absolutely beneficial for the company. And not everyone, of course, values that.

Paul [00:26:11] That’s wonderful. I think all this has been really inviting just to get back into some of the basics of product management, get into a different mindset of pulling ourselves out of the rut of some of the frameworks that just keep us focused on jumping from meeting to meeting to meeting and never really elevating and finding that delight that you emphasized. As we wrap up, we’ve just got two last questions for you that we ask of all of our guests. One, to tie us up here is, what are you reading? You mentioned a couple of books that you’ve found influential over your career. What would you say should be on the desk of every product manager that would be helpful to crack open if they haven’t found it yet?

Nesrine [00:26:45] Very interesting question. But at the moment, if you’re asking about what am I reading now, I’m reading the Discovery Discipline by Remi [Guyot]. It’s a new book. It’s a lot about discovery, of course, but Remi is a product coach and he used to be the VP of BlaBlaCar and it’s my new baby on the desk. And before that I just finished Teresa Torres’s book, Continuous Discovery Habits, of course and that’s one of the musts that I think has to be on PM desks.

Paul [00:27:15] Big fan of Teresa’s book. That’s a great one. Great recommendations.

Nesrine [00:27:18] Thank you.

Sean [00:27:19] All right. The last question we always ask our guests just to get some different perspective on this word, innovation: how do you define the word innovation?

Nesrine [00:27:27] Oh, that’s a very interesting question, because that brings me back 15 years ago, even if we are trying, of course, to do innovation now. But at the time as a researcher, innovation is about bringing something new that no one has thought about before. So of course, as a researcher, you do a lot of what we call state-of-the-art. State-of-the-art is an intensive, it’s very similar to UXR, by the way, intense days where you look around and see what people have done so far. So we try to understand how people addressed the problem before, and how can we address it differently? So innovation for me is about solving the right problem with the right solution. So it’s a mix of efficiency and effectiveness.

Sean [00:28:11] Excellent.

Paul [00:28:11] No matter how many times we ask that question, I’m always surprised at how many variations we can get. I love that answer.

Sean [00:28:17] Yeah.

Paul [00:28:17] Right solution to the right problem. Well Nesrine, that’s all the time that we have for today. I really appreciate you taking a moment to share your journey and insight with us. It’s been a delight.

Nesrine [00:28:25] Thank you. It was my pleasure, too.

Paul [00:28:28] Cheers.

Paul [00:28:31] Well, that’s it for today. In line with our goals of transparency and listening, we really want to hear from you. Sean and I are committed to reading every piece of feedback that we get. So please leave a comment or a rating wherever you’re listening to this podcast. Not only does it help us continue to improve, but it also helps the show climb up the rankings so that we can help other listeners move, touch, and inspire the world, just like you’re doing. Thanks, everyone. We’ll see you next episode.