The conversation with my next guest was going so deep and so well…it became a two-part episode! Today I’m chatting with Nadiem von Heydebrand, CEO of Mindfuel. Nadiem’s career journey led him from data science to data product management, and in this first, we will focus on the skills of data product management (DPM), including design. In part 2, we jump more into Nadiem’s take on the role of the DPM. Nadiem gives actionable insights into the realities of data product management, from the challenges of actually being able to talk to your end users, to focusing on the problems and unarticulated needs of your users rather than solutions. Nadiem and I also discuss how data product managers oversee a portfolio of initiatives, and why it’s important to view that portfolio as a series of investments. Nadiem also emphasizes the value of having designers on a data team, and why he hopes we see more designers in the industry.

Highlights/ Skip to:

• Brian introduces Nadiem and his background going from data science to data product management (00:36)
• Nadiem gives not only his definition of a data product, but also his related definitions of ‘data as product,’ ‘data as information,’ and ‘data as a model’ products (02:19)
• Nadiem outlines the skill set and activities he finds most valuable in a data product manager (05:15)
• How a data organization typically functions and the challenges a data team faces to prove their value (11:20)
• Brian and Nadiem discuss the challenges and realities of being able to do discovery with the end users of data products (17:42)
• Nadiem outlines how a portfolio of data initiatives has a certain investment attached to it and why it’s important to generate a good result from those investments (21:30)
• Why Nadiem wants to see more designers in the data product space and the problems designers solve for data teams (25:37)
• Nadiem shares a story about a time when he wished he had a designer to convert the expressed needs of the  business into the true need of the customer (30:10)
• The value of solving for the unarticulated needs of your product users, and Nadiem shares how focusing on problems rather than solutions helped him (32:32)
• Nadiem shares how you can connect with him and find out more about his company, Mindfuel (36:07)

Quotes from Today’s Episode

• “The product mindset already says it quite well. When you look into classical product management, you have something called the viability, the desirability, the feasibility—so these are three very classic dimensions of product management—and the fourth dimension, we at Mindfuel define for ourselves and for applications are, is the datability.” — Nadiem von Heydebrand (06:51)
  
• “We can only prove our [data team’s] value if we unlock business opportunities in their [clients’] lines of businesses. So, our value contribution is indirect. And measuring indirect value contribution is very difficult in organizations.” — Nadiem von Heydebrand (11:57)
  
• “Whenever we think about data and analytics, we put a lot of investment and efforts in the delivery piece. I saw a study once where it said 3% of investments go into discovery and 90% of investments go into delivery and the rest is operations and a little bit overhead and all around. So, we have to balance and we have to do proper discovery to understand what problem do we want to solve.” — Nadiem von Heydebrand (13:59)
  
• “The best initiatives I delivered in my career, and also now within Mindfuel, are the ones where we try to build an end responsibility from the lines of businesses, among the product managers, to PO, the product owner, and then the delivery team.” – Nadiem von Heydebrand (17:00)
  
• “As a consultant, I typically think in solutions. And when we founded Mindfuel, my co-founder forced me to avoid talking about the solution for an entire ten months. So, in whatever meeting we were sitting, I was not allowed to talk about the solution, but only about the problem space.”  – Nadiem von Heydebrand (34:12)
  
• “In scaled organizations, data product managers, they typically run a portfolio of data products, and each single product can be seen a little bit like from an investment point of view, this is where we putting our money in, so that’s the reason why we also have to prioritize the right use cases or product initiatives because typically we have limited resources, either it is investment money, people, resources or our time.” – Nadiem von Heydebrand (24:02)
  
• “Unfortunately, we don’t see enough designers in data organizations yet. So, I would love to have more design people around me in the data organizations, not only from a delivery perspective, having people building amazing dashboards, but also, like, truly helping me in this kind of discovery space.” – Nadiem von Heydebrand (26:28)

Links

• Mindfuel: https://mindfuel.ai/
• Personal LinkedIn: https://www.linkedin.com/in/nadiemvh/
• Mindfuel LinkedIn: https://www.linkedin.com/company/mindfuelai/

Transcript

Brian: Welcome back to Experiencing Data. This is Brian T. O’Neill. Today I have gotten Nadiem von Heydebrand from Europe, from Mindfuel. You’re the CEO of Mindfuel, and you guys are super focused on data products, so I’m, like, totally stoked to have this conversation [laugh].

Nadiem: Hi. Hi, Brian. It’s great to see you and great to talk to you today.

Brian: Yeah, yeah. If I recall from when we had our, like, first conversation, you came out of data science or analytics, some kind of data background, and then you went into product management, and now you’re a CEO of a consulting firm slash, you’ve got a product going, a SaaS product going as well. Do I get that journey right?

Nadiem: Exactly. No, absolutely. My name is Nadiem. I studied Business Information Systems here in Munich—so I’m located in Germany—the technical university. And I work in data science and my career, my entire career so far, switched then into something which we call today data product management.

So, I got hooked by product management. Later in my career, I found out that this is a topic. Yeah, I founded a startup together with my co-founder, Max. He’s a little bit like the wife you’re always looking for, right? So, he brings all the strengths and fulfilling my pieces, I would say. So, he’s brilliant product manager. And so, we combine data science and product management into what we call data product management today, yes.

Brian: Just to ground this talk because there’s different definitions. When we talk about data products, in general, and maybe even data product management, there’s different definitions, I think everyone’s kind of feeling, like, well, everyone has a different one. I’ve put mine out there for my audience, but I’d like to hear what yours is just so when we talk about this episode, we kind of know the grounding that we have.

Nadiem: Definitely nailed it right away from the beginning because the definition of data product is so broad still in the market. And whoever you talk to, especially with the backgrounds of the person you’re talking to, there is a very technical definition when we’re talking about data products which we would then also rephrase as data as a product, where we reuse, verify data, or prepare data, cleanse data in a very structured way and make sure that the adoption of these data sets or cleansed data sets is very high. And to other people, when you talk about, for example, machine learning models or dashboards, or what we traditionally would named as use cases, realized use cases, are then so-called data products. This is also a little bit the definition I typically use. So, for me, a data product is something where I have a real user, consumer, someone who’s really leveraging the outcome of my product.

And this typically happens when we unlock the value in the lines of businesses or in the business field. And they usually use, I don’t know, dashboards, models, algorithms in an integrated way in their processes, for example. So, there are different definitions of data products. I live with both of them, the data as a product definition from a technical perspective—validated datasets—but then also the product, which is really usable, consumable by a non-technical person, if you want to.

Brian: Yeah, I would agree with you. When I hear data as a product, I usually jump to, like, “Oh, I’m a marketing person. I want to buy 50,000 email addresses of IT professional leaders.” That to me is data as a product. It’s a zip file you can download for 19.95 [laugh].

Nadiem: [crosstalk 00:04:04] it is.

Brian: And that’s fine. There’s places at times you need that kind of stuff and that’s totally fine. That’s not what I’m generally talking about on this show. And—

Nadiem: Yeah, I mean, there was a definition now as you’re talking about it, so there was a paper I read a couple years ago already, where there were actually three definitions of a—back then—data product. It was called ‘data as product,’ where you use the raw data and consume them through an API or through a web service or whatever. Then there was ‘data as information.’ So, transformed data where you’ve been able to consume the information out of the data. And third was ‘data as a model’ when you use the data, put it into a function, and you get a prediction out of this data.

So, these were definitions which already existed, like, a decade ago. And as of today, I would say we mix it up, like, with data as a product or data product where you consume, from a business perspective, the outcome of data. Yeah.

Brian: Yeah. And I think we’re aligned on that outcome piece and not so much on the manufacturing of technical output is required, but that’s not actually the end of the game. That’s not scoring the goal, you know [laugh]? The goal is the outcome. I know you have an interesting framing here about the job title and role of data product management separate from the disciplines, the activities, and the behaviors of applying product management to data science and analytics work. So, doing data product management activities in the same way—I look at this the same way with design, which is you can’t not design solutions. Like, there’s always a user experience, even if you didn’t put an intention behind it.

So, we can begin to learn how do we put more intention—even if we’re not a trained designer—we can put intention behind the work. Let’s put the data product manager things aside. We’ll talk about that later. But let’s start with the skill set thing. What are the skill sets that, if someone that wants to jump into the space, that they might need to let go of, if let’s say they’re coming out of data science and analytics, or maybe engineering, what are the skills that they need to have here that they can begin to practice today? Or if you’re a leader or management, that you know, if you wanted to get training or help, what are those skills that they need to do to start getting this high adoption, high business value?

Nadiem: To explain the skills even better, let’s look back just for a second where we coming from. When we look into the last decade, we were used to do a lot of projects. And don’t get me wrong, I don’t want to, like, judge on projects today. Project management is a super important job role, a lot of activities. But when we think about products and product management, one important thing is that looking into this discipline, there are different characteristics, skills, and strengths needed and different activities are applied.

The product mindset already says it quite well. When you look into classical product management, you have something called the viability, the desirability, the feasibility—so these are three very classic dimensions of product management—and the fourth dimension, we at Mindfuel define for ourselves and for applications are, is the datability. If we briefly jump through these four categories: viability, a classical topic where we try to find out if the product we’re building, has a business case to create added value, creates an outcome for the recipient of the product. And the desirability, I mean, most of the audience here coming probably from design as well. You have to understand the underlying needs of your consumer of the user who’s consuming your product. The feasibility, where data people or where tech people overall, we know can we build the product from a technical perspective?

And if we deep dive down into the data space, we have to think about the data-ability, which means is the data good enough? Do we have enough data? What about data quality issues? Do we have access to the data? And is the data well balanced? And can I even do something around maybe advanced analytics with the data because I have enough correlations in the data?

So, all that data-specific questions, is something we summarized in data-ability. Looking into classical initiatives today, you cannot do not product management [laugh] as of today already. Because if you look, for example, to a very experienced product owner who’s running a data initiative and has a cross-functional data development team, with a scientist, machine learning engineer, and data engineer, and so on, and so forth, these kinds of product owners typically already asked the right questions.

So, on their individual initiative level or use case level, they’re already doing it maybe implicitly. Now, the question is, how can you structure and generalize and also make it more transparent what these activities are and how to address them? Because I personally believe, and this is actually the reason why we founded Mindfuel as well, is I truly believe that this famous 90% of all data use cases fail, or data science initiatives don’t create impact or business value, whatever statement you’re listening or reading to, truly depend on the fact that in the beginning of the initiative, we are lacking product management activities. We’re not putting enough effort in desirability, viability, and all of that stuff, which result at the end in a maybe solution result of the project of the initiative, which is not creating the expected business outcome we promised, maybe, from the beginning. So, that’s the reason why I think data product management is a super valid and very important set of activities in this case.

Brian: Got it. And I’d really like to focus this talk on that what you’re calling the desirability vector here. Actually, most of my audience, just so you know, I think is actually non-designers. They’re going to—I think they’re more people listening from the, you know, analytics and data science field, consulting, things like this. I think that audience understands what’s viable, technically to make. I think a lot of the times the problem with this, the 90% story that you tell is, the problem is not really understood down at a granular level.

So, it might be something like, “We want to have more effective marketing campaigns. And so, we want to make sure we’re targeting the right message at the right people,” or something like this. And where a lot of times these things fail, in my experience, at least my perception from talking to people is that they don’t really understand what the humans-in-the-loop are actually doing—the marketing people—on a day-to-day basis. They are so disconnected from what’s it like to be a CMO. What’s it like to run an ad campaign, when you’re making the decisions on messaging, when you’re making the decisions on targeting? They don’t really understand the workflows of those people.

And so, even if you get the modeling right and you have the data and all that stuff, if you don’t understand the problem space properly and where they want help and maybe where they don’t, where they’re just going to guess because it’s too hard to use the, quote, ‘insights’ of your solution to make a better decision, that really last mile—or it’s really the first mile in a way. It’s the last mile of the project, but it’s really the first mile where we figure out what’s needed. That to me is what—I don’t know, talk to me if you disagree, but I feel like that—

Nadiem: No, no, no, I—

Brian: Problem discovery is where we’re missing things

Nadiem: I have two comments on that, but maybe we start with bringing this all into practice a little bit because it’s very theoretic.

Brian: Yeah, yeah.

Nadiem: So, if we look into a data organization today, let’s assume a classical organization or classical company, a corporate maybe. So, if we refer to your audience, what is the role of a data unit or a data organization? We are usually a support function. In a traditional organization, my assumption is a data unit is a support function. So, we have lines of businesses, they coming around with their business challenges or with the business problems or with their business opportunities, as we call it in our framework, and our job as a data unit is to understand their needs to support them.

Because how do we prove our value? We can only prove our value if we unlock business opportunities in their lines of businesses. So, our value contribution is indirect. And measuring indirect value contribution is very difficult in organizations. I mean, look, you can compare this to a people department or to a legal department, what is the true value contribution of a legal department? They are the support function and you always need to justify this contribution through the lines of businesses.

So, now when we look into the data world, we typically invest a lot into AI, into data, we’re hiring very experienced people. So, you could say, it is a kind of investment to build up a very professional data organization as of today—especially if you build it centralized in a data hub, or whatever—to justify these investments; we have to create a return on investment. And this is happening through facilitating use cases, products, whatever, in the lines of business. So, for this, we need to understand what these guys need. So, if my marketing lead, or if my CMO comes around, my job is as a data product manager to understand his problem—his or her problem—the viability, the business case he wants to fulfill, and how I can support him by leveraging my experience and my skill set using the data to create this business case for him.

And therefore the desirability once again. So, what does the CMO truly needs is a very important piece of work at this stage. In former times, we used to run something like a use case workshop, you know, a one-day workshop, where we collected the requirements, maybe a little bit like in the technical word where we try to collect requirements in a very structured way. But as you said, in product management, we have something like discovery, we have discovery work, which goes on continuously. It is not just the work which is a work package of, like, two weeks requirements engineering and then we develop something in the delivery, but it’s a continuous effort, and this continuous effort is super crucial for the success.

And this takes me to my second point. Whenever we think about data and analytics, we put a lot of investment and efforts in the delivery piece. I saw a study once where it said 3% of investments go into discovery and 90% of investments go into delivery and the rest is operations and a little bit overhead and all around. So, we have to balance and we have to do proper discovery to understand what problem do we want to solve.

Brian: I mean, that takes a very leadership-oriented lens because if the entire tribe feels like my job is simply to deliver, and if they don’t want it or care, that’s not my problem because I was tasked with delivery, that culture does not work with this mindset, right? There’s a different mindset, in my opinion, that’s required. We actually have to care about downstream consumption and use and creating value. And long-term, it’s much better for the makers and for the users and for the stakeholders to create—to me it’s going to create better culture because the work has meaning. And I just talked to, at the time we’re recording this, the next episode that’s going to come out of the show is with Kyle Winterbottom who’s a recruiter in the data and analytics space.

And he talks about how a lot of staff now, because of remote work and all that, data professionals want to work on stuff that’s going to ship. I want to have impact, I want my work to have meaning, I don’t want to just write code in a silo by myself, especially now that I’m remote. I want to be part of something. So, there’s actually, maybe the stars are aligning [laugh] a little bit there; the work has to actually count for something now. But as you said, 3% investment on this, I find that fascinating.

I’ve not heard that statistic before; it sounds about right to me. There’s not a regular amount of time being there’s not a routine of regular customer exposure time. And that is so important, right? Routine exposure to the people that you’re serving, whether you’re in consulting—which is effectively what a data team is doing inside the business; you’re kind of like this mini consulting team—but if you don’t have that exposure time, you have no idea what you’re doing. And requirements are a lie. They’re a friendly lie [laugh].

Nadiem: Yeah, and even on top of that, what we have to maybe address at this moment in time—this goes also out to the lines of business people listening to this—because they also have to understand that they have to invest some time into this. I had a chance within my career now to deliver more than 300 data use cases. So, I’ve seen a lot and I’ve worked on a lot of different initiatives myself, as a data scientist, as a project lead, as a steerer on different initiatives, and what I experienced very often is that the line of business side of the house also said, “Yeah, you know what, I only have three hours a week to contribute to this, so my preference would be I just drop over, or I just throw over the requirements and then you do the magic, and then you come back.” And in terms of, like, maybe even customer-supplier relationship. But the reality is the best initiatives I delivered in my career, and also now within Mindfuel, are the ones where we try to build an end responsibility from the lines of businesses, among the product managers, to PO, the product owner, and then the delivery team.

This is something which your operating model needs to facilitate as well. So, your operating model in the data organization and the collaboration with the business, I mean, we were talking here cross-functional collaboration. Sometimes we even have to break down silos or, like, now the whole organization topic and SRE topic plays into. So, there’s a lot of, let’s call, dimensions we can sort out, or we have to sort out, to truly deliver measurable impact from data.

Brian: I’m totally aware of what you’re saying there and I know that’s a challenge for, you know, people I’ve talked to routinely in my space as well, is sometimes getting access to the people who are going to use it can be difficult. This is actually a classic problem for designers and user experience professionals as well. Sometimes our gate is, like, a sales team that doesn’t want us talking to a customer who’s going to buy a million-dollar piece of hardware. They’re so afraid we’re going to ask the wrong thing, or what—you know. And what they don’t realize is the best solutions come when we’re designing with our users and not for them.

We’re not really doing it for them, we’re doing it with them, and it’s so hard to get it right if they’re not an inherent piece of both the problem discovery part and the solution part. It really breaks down because they’re sending you a lie when they send you requirements. And it’s a friendly lie. They’re trying to help you by telling you, “This is what I need,” but they’re usually expressing that as a solution. And they are not data professionals that know how to build data products.

They are a marketing person that’s in charge of getting the messaging right and creating demand. And they’re trying to help you. But it’s a lie. Lie is maybe not the right word, but I want people to internalize that there’s a missing thing in these requirements. They’re a hint at what might be needed. And we need to start treating it that way and dig into what’s behind the quote, “Requirements.”

Nadiem: Also, bring this back into reality—because [unintelligible 00:19:05] that we’re talking about ideal scenarios here. In reality, everyone is busy, everyone has the full schedule. So, I think what a product manager or data product manager is one of his best abilities is to create these, kind of, win-win situations. So, a win for the line of business, a win for the guy who is super busy all day long, and a win for us as a data team, as a data organization, to deliver the best possible outcome out of this. A data product manager, in its role, when you establish the role, not only covering the activities for someone, or a data leader specifically, we are kind of a connecting person who is connecting to the line of business, connecting to the management, we talking to controlling, we talking to finance.

So, in a lot of my initiatives, I’m not only interfacing with the line of business and the PO, but I also have to manage the financial side of the house when I’m running more than one initiative. Took now the example for one use case, one product, whatever, but as a product manager, I typically have a portfolio of products, I have a portfolio of investments, and I’m talking to so many different people to facilitate the viability and desirability. And I typically may be also accompanied by a designer, who’s then, like, in classical product management, running this kind of discovery stuff for me or with me. As a technical team, we need to learn to understand these challenges and tasks because we’re all educated from our backgrounds.

So, I can just say this for myself, I don’t want to generalize it, but I can say for myself, I went to super good university, but they teach me to solve problems. So, always think in solutions, they throw me over a problem and I have to build a solution because I’m an engineer. But what I truly learned within the last few years is, stick in the problem space, understand the discovery, or try to understand the problem through the discovery, and bring this into a context of P&L. How can I contribute really to the P&L of my customer which is the line of business, and how can I build a true business case all around that, to scale it and out? Because nothing is—actually, it is worthless if I cannot scale it at the end. I need to make sure that it is adopted to product. I need to make sure that people are truly using the product at the end to unlock the value at scale. This brings us break even as a data unit and turns a data unit from a cost center actually into a profit center.

Brian: Exactly. I think that’s another mindset, especially if you’re in AI and machine learning in this space in particular. There’s big expectations for this spend, right, this investment that we’re making, and it’s in a space where a lot of executives don’t really understand what’s possible or feasible, but the train has left the station and everyone wants to get on board that, right? It’s a time where we have the capability to—there probably are opportunities for that. And if you don’t want to waste it, I think you really have to get that, especially in data science, you really need to understand this problem space and think in terms of that.

And not just P&L, too. I think—you made a good point about the P&L space, but it’s also, in consulting we kind of talk about the transformation of the client. Like, what’s the change the client wants to have? But that can be applied internally, too. So, if the chief marketing officer is your client, or the head of advertising campaigns, or whatever, getting to know that person and how is your thing going to empower them, cut down on busy work that they can’t stand doing, or prevent me from shooting myself in the foot and making another mistake.

How can you help take work off their plate, make them look like a champion or whatever. That’s how you get them to spend time with you in those nitty gritty meetings where you’re down in the weeds about what’s going to go on the dashboard or whatever because you keep reminding them, like, we’re here to get this work off your plate, we’re here to help make sure the next spend on this campaign is not 3% success, it’s 6%. It’s double what it was last time. That’s why we’re asking you these questions. And you got to remind them why we’re here, right [laugh]?

Nadiem: Yeah. [unintelligible 00:23:04] no, fully, exactly. And facilitating the user, the customer, whatever you want to call it, this is how we as product managers are rewarded, right? So, we’re just as good as our customers are. And especially if I look now into the data space where it’s very difficult to be this kind of translator, as you said, the line of business cannot come around and tell me what the analytical use cases is.

He comes around—he or she comes around with a business problem and my job as a data product manager is to understand the business problem and translate it into an analytical problem, but from a discovery perspective. And I don’t have to do this only for one problem, but I have to do this for many problems, for several lines of businesses. So, as I said, very successful data product managers, they have a very good overview of their portfolio. So, they play the portfolio game because they know that not every data product can have a hockey stick value contribution at the end, or even be successful at the end. So, in scaled organizations, data product managers, they typically run a portfolio of data products, and each single product can be seen a little bit like from an investment point of view, this is where we putting our money in, so that’s the reason why we also have to prioritize the right use cases or product initiatives because typically we have limited resources, either it is investment money or it is people or resources or are time.

So, we have different limited factors. So, we can typically not run all the initiatives. We cannot solve all the problems of all stakeholders coming around to me and telling me about their great business opportunities they’re having. And so, when you play this right or when you establish a proper approach, if you want to manage these kinds of portfolio in your data organization, regardless now if you already have a data product manager or not, then me as a data leader, I need a clear overview and understanding of my portfolio and in which initiatives, I’m investing my resources at the moment.

And this needs to be very explicit. And I can recommend to do this in a very structured way so that you can always do two things: you can always report wherever direction you need to report, either to the customer, to the team, or to your direct report of [unintelligible 00:25:17] or whatever, but also it gives you clarity and transparency on where you put your resources in, so to optimize your system as a data leader and in your organizational field. So, I think there’s a super important. Otherwise, you’re, you have—yeah, you might lose momentum if you want. So.

Brian: And I want to dig into this portfolio and kind of talk about—now we’re talking about a role, a person that’s really owning this entire suite of problems and tasks and responsibilities. Just to wrap up the previous thing, though, one thing—can you unpack for me because I think you had talked about bringing design in to do some of these facilitations and research sessions and problem-finding sessions. This is still not something, a lot of teams do not have any exposure to design or user experience unless they’re coming out of the digital s—you know, digital natives tend to be more comfortable or familiar with this. What does that look like? Can you just visually tell people, what’s happening in the room? Who’s there? What are they doing? How is design or user experience research helping you, like, your business? Or how are you helping your clients by deploying those skills there? What does that look like?

Nadiem: I have to make a remark and wish at the same time, at this point in time. Unfortunately, we don’t see enough designers in data organizations yet. So, I would love to have more designing people around me in the data organizations, not only from a delivery perspective, having people building amazing dashboards, but also, like, truly helping me in this kind of discovery space, when it comes to questionnaires, unders— customer experience workshops, understanding the problem space even better. I mean, there are so many great methodologies from, really, user experience or research design where you try to understand the problem underneath the problem. There’s this one thing where designers are at my site in very big initiatives, where it is also viable to bring a full-time equivalent into these kinds of projects.

And the other thing is then also when it comes to, even to the business case, about, for example, willingness to pay efficiency management, how do we integrate the solution from our data product into the operational process from a user experience perspective? So, imagine we’re building an algorithm for predicting churn—very simple, very simply said—and the results of the churn algorithm or the output—now we’re talking specifically of the output of the model—needs to be integrated into the CRM system again. So, whenever a sales manager or within the call center, the person, the user of the CRM system is opening the tool or the platform, and we want to show him very easy way the output of the algorithm. So, will this customer churn yes or no? What is the churn probability? Shall we make them a great offer? Yes or no.

So, these are design experiences or user experience topics where people from the data team are typically overwhelmed. And product manager can do this to a certain degree, but here it is super cool if you have a dedicated designer on onboard. And otherwise, you try to make the best out of it together with the design team from the digital platform integrating that stuff. But design is a super critical topic when you really want to scale out a solution you have built in the data space and if you really want to integrate it.

Brian: Why are the data people overwhelmed? Unpack that for me.

Nadiem: I don’t want—again, I have to be careful. I don’t want to generalize. I’m pretty sure there are great data people out there who can live in both worlds. But the classical data person is a tech person who feels very comfortable in his engineering world and not be overwhelmed with meetings, with communication tasks, with talking to customers too much, or to users too much. Because the challenge is big enough to find a great model or to build a great data model or to build a great prediction or whatever.

I would consider data people more like engineers [laugh] or technical software developers. We are typically not used to talk to business needs too much. I don’t want to get too specific here, but classical data people usually are rational people. Building great products sometimes needs also emotional piece of it. And design has two dimensions for me: it has one the also very rational and technical piece of it, but also a little bit the emotional side of it. And you need to manage this the right way. This is maybe the explanation where we sometimes are overwhelmed, talking as a data scientist myself.

Brian: Yeah, yeah [laugh]. Is there any particular—and I do want to jump to our, kind of the second part of the conversation, but is there any particular story or anecdote you can share about an experience working with a designer, or where you discovered something, or we kind of landed on something that we didn’t think of?

Nadiem: I can share a story where I wish I would have had a designer. I remember a case, it’s years ago, when the line of business was super involved into the analytical problem. So, we wanted to do a prediction in logistics, you know? It was about part management in the car manufacturing industry. We wanted to build a solution where we predict which parts are needed and should be stocked in which area of the warehouse to optimize the entire logistic flow.

At that time, I was a product manager for the data space, so I was the data product manager, and I was also steering the development team. So, I had a split role between product ownership and product management. So, I was talking a lot to the client or the customer from the line of business. I had a lot of work at that time, and so I left the design definitions of both the KPIs and the look out of the dashboard we wanted to deliver to my lead data scientist. They were running meeting after meeting after meeting after meeting and he always reported to me, “Everything worked. We had a great alignment. I totally understand the problem. I know what we need to deliver.”

And then we were coding and we were developing the solution, like, for three weeks in the first sprint, and we showed the first prototype after three weeks, and the customer was like, really, really, really disappointed at that moment in time. Because both the customer and my lead data scientist, both have the experience that—or had the feeling that they’ve understood each other, but my data scientist was just thinking in solutions and KPIs and he developed, I don’t know, 50, 60, 70 KPIs and he predicted a lot of stuff, and not a single KPI helped my business stakeholder. I wish I would have someone who tries to understand the underlying problem because also my business was not capable. So, it’s not only about the data scientist, but also the guy from the business was not capable to express what he actually needs. So, there was a lot of ping-pong going in between these two roles.

I think at this moment, I wish I had a designer with me on site who can convert this expression of the lines of business into the true need we should address and which we should solve. Yeah.

Brian: Yeah. And I think just to wrap up this topic, I think, if you’ve had that experience before, and you’re listening to the show, it’s normal that you’re not getting the right requirements because people don’t think in terms of expressing problems to people, they think in terms of saying, “Ah, I need a new whatever,” you know? But they’re not telling you the underlying reason why I really want a new car because, “I’m going to see my friend and it’s a college reunion, and, like, I want my status to be reaffirmed that I drive a BMW and then I’m successful.” They’re not going to come and tell you that. You might get to that in a research conversation at some point over some time, but they’re never going to come to you with that.

A good salesperson can tease this stuff out, just like a good researcher can tease this stuff out, but they’re never going to walk in the door with that. But there’s always unarticulated needs and that’s where the money and the value, and like, that’s where real value creation happens and delight. That’s where we actually have a big impact on people’s lives, is because they don’t even know that that’s why they’re doing it. But when you uncover that, it’s, “Yeah, that’s actually what I hate. I hate this busy work of running ad campaigns. It’s driving me—I spend all my time on this. I hate this.”

And they didn’t come in with that. They’re like, “I need a dashboard.” Really, what they were saying is, I can’t stand how much time we have to spend coming up with ad creative and not having any idea what language is going to work because we don’t know what worked in the past. Even though we’ve running campaigns for a hundred years at this company, what if we knew about what worked in the past and why [laugh]? And it’s like, but they don’t come in with that. They come in with, “I need a dashboard.” [laugh].

Nadiem: I mean, a very, a very funny story for wrapping up the topic is, as you know, we’re building our own SaaS platform. And as a consultant, I typically think in solutions. And when we founded Mindfuel, my co-founder forced me to avoid talking about the solution for an entire ten months. So, in whatever meeting we were sitting, I was not allowed to talk about the solution, but only about the problem space. And this was horrible for me.

It was really horrible, but we were designing in the problem space for over ten months and I was not allowed to talk about solutions. And for me, it’s like, “Okay, I’m worked in sales. I worked as a consultant. I think in solutions.” But this really helped me, once again, to learn to stick in the problem space for a while, although I was suffering [laugh].

Brian: Yeah. [laugh]. Well, it’s tough and it’s the gray space. It’s usually not super black and white, although we can get to some very get concrete things eventually, you can surface those needs. We have to get comfortable with the gray part of this and that’s I think we’re designers and user experience people, we’re used to living in that wishy-washy, unclear, vague kind of space.

And it’s just a skill that you have to get more comfortable with. So, yeah, I totally can relate to that. Nadiem, I have a question for you. How would you like to just come back and do, like, a part two here? We’re at 40 minute—I knew this is going to happen because we have so much to talk about. Would you like to just maybe come back and do a part two, and we can jump into the role of the DPM and kind of this portfolio? I think that’s an awesome topic.

Nadiem: I’m happy to do so. I think it makes sense because now we talked a lot about design—

Brian: Yeah.

Nadiem: And I really, truly like it. And this—but also, I’m not the best design person, I have to admit. So, my background is not design, so I was just able to explain this from a product manager perspective, more or less.

Brian: That’s actually exactly what I wanted because I don’t—a minority of my audience, I think, are actually designers and user experience people. They’re more people like you. So, getting your language and experience around it, I think is great, actually. So, thank you for sharing all that. In the meantime, we’ll figure out a time to do part two. But where can people learn more about you? Are you on LinkedIn or Twitter? What’s your website? Can you tell us where how to find Mindfuel and you personally?

Nadiem: I’m on LinkedIn. You’ll find me there, please feel free to add me and to connect with me. Otherwise, Mindfuel is working mainly in Europe, so in the German-speaking region, what we call the [unintelligible 00:36:25] region. You can follow us on LinkedIn. Also, Mindfuel has a quite prominent LinkedIn page. You can connect with me, and otherwise, you find everything on mindfuel.ai.

Brian: Cool. Nadiem, this is awesome. I look forward to part two here. Thanks for taking the time to come on the show today.

Nadiem: No worries. Thank you for having me, Brian. I’m really looking forward to part two. It’s going to be fun.