Today I’m continuing my conversation with Nadiem von Heydebrand,CEO of Mindfuel. In the conclusion of this special 2-part episode, Nadiem and I discuss the role of a Data Product Manager in depth. Nadiem reveals which fields data product managers are currently coming from, and how a new data product manager with a non-technical background can set themselves up for success in this new role. He also walks through his portfolio approach to data product management, and how to prioritize use cases when taking on a data product management role. Toward the end, Nadiem also shares personal examples of how he’s employed these strategies, why he feels it’s so important for engineers to be able to see and understand the impact of their work, and best practices around developing a data product team. 

Highlights / Skip to:

• Brian introduces Nadiem and gives context for why the conversation with Nadiem led to a two-part episode (00:35)
• Nadiem summarizes his thoughts on data product management and adds context on which fields he sees data product managers currently coming from (01:46)
• Nadiem’s take on whether job listings for data product manager roles still have too many technical requirements (04:27)
• Why some non-technical people fail when they transition to a data product manager role and the ways Nadiem feels they can bolster their chances of success (07:09)
• Brian and Nadiem talk about their views on functional data product team models and the process for developing a data product as a team (10:11)
• When Nadiem feels it makes sense to hire a data product manager and adopt a portfolio view of your data products (16:22)
• Nadiem’s view on how to prioritize projects as a new data product manager (19:48)
• Nadiem shares a story of when he took on an interim role as a head of data and how he employed the portfolio strategies he recommends (24:54)
• How Nadiem evaluates perceived usability of a data product when picking use cases (27:28)
• Nadiem explains why understanding go-to-market strategy is so critical as a data product manager (30:00)
• Brian and Nadiem discuss the importance of today’s engineering teams understanding the value and impact of their work (32:09)
• How Nadiem and his team came up with the idea to develop a SaaS product for data product managers (34:40)

Quotes from Today’s Episode

• “So, data product management [...] is a combination of different capabilities [...]  [including] product management, design, data science, and machine learning. We covered this in viability, desirability, feasibility, and datability. So, these are four dimensions [that] you combine [...] together to become a data product manager.” — Nadiem von Heydebrand (02:34)

• “There is no education for data product management today, there’s no university degree. ... So, there’s nobody out there—from my perspective—who really has all the four dimensions from day one. It’s more like an evolution: you’re coming from one of the [parallel business] domains or from one of the [parallel business] fields and then you extend your skill set over time.” — Nadiem von Heydebrand (03:04)

• “If a product manager has very good communication skills and is able to break down the needs in a proper way or in a good understandable way to its tech lead, or its engineering lead or data science lead, then I think it works out super well. If this bridge is missing, then it becomes a little bit tricky because then the distance between the product manager and the development team is too far.” – Nadiem von Heydebrand (09:10)

• “I think every data leader out there has an Excel spreadsheet or a list of prioritized use cases or the most relevant use cases for the business strategy… You can think about this list as a portfolio. You know, some of these use cases are super valuable; some of these use cases maybe will not work out, and you have to identify those which are bringing real return on investment when you put effort in there.” – Nadiem von Heydebrand (19:01)

• “I’m not a magician for data product management. I just focused on a very strategic view on my portfolio and tried to identify those cases and those data products where I can believe I can easily develop them, I have a high degree of adoption with my lines of business, and I can truly measure the added revenue and the impact.” – Nadiem von Heydebrand (26:31)

• “As a true data product manager, from my point of view, you are someone who is empathetic for the lines of businesses, to understand what their underlying needs and what the problems are. At the same time, you are a business person. You try to optimize the portfolio for your own needs, because you have business goals coming from your leadership team, from your head of data, or even from the person above, the CTO, CIO, even CEO. So, you want to make sure that your value contribution is always transparent, and visible, measurable, tangible.” – Nadiem von Heydebrand (29:20)

• “If we look into classical product management, I mean, the product manager has to understand how to market and how to go to the market. And it’s this exactly the same situation with data product managers within your organization. You are as successful as your product performs in the market. This is how you measure yourself as a data product manager. This is how you define success for yourself.” – Nadiem von Heydebrand (30:58)

Links

• Mindfuel: https://mindfuel.ai/
• LinkedIn: https://www.linkedin.com/in/nadiemvh/
• Delight Software - the SAAS tool for data product managers to manage their portfolio of data products: https://delight.mindfuel.ai

Transcript

Brian: Welcome back to Experiencing Data. This is Brian T. O’Neill, and we have part two of an episode today. We haven’t done a two-part episode ever, I think. What, 120 episodes in on this show? But the conversation was going so long, there was so much solid meat in it that I felt like we needed to break this into [laugh] two. So, Nadiem von Heydebrand from Mindfuel, welcome back.

Nadiem: Thank you very much, Brian. I’m really happy to be back.

Brian: Yeah, yeah. You went off to the mountains. Did you have any enlightenment between our two episodes? You were just telling me you were on a trip. Did you have any enlightenment about data product management [laugh] that you wanted to share today [laugh]?

Nadiem: [laugh]. Thank you. No, I [crosstalk 00:01:13]—

Brian: Did you get a sign [laugh]?

Nadiem: Yeah, yeah. So, what I can say is that I had an amazing time off in the mountains. I’ve been to the Alps here, south of Munich, for a hiking trip. And I have to admit, I do think a bit about work when I’m hiking. It is, kind of, restructuring and reviving and thinking about new things and I get inspired by the mountains. But I keep that for our R&D department for now [laugh].

Brian: [laugh]. Okay, sounds good. Well, we talked a lot about data products. And then we talked about data product management as a skill and as a role. And what happened in our last episode is, I intended to kind of—you have a model of this, which is, it kind of starts with skills and then eventually, you might need a dedicated role for this.

And we ran out of time after going through, kind of, the skills part. So, I just want to ask you today, before we jump into the roles part, is there anything we didn’t really cover that you wanted to finish up in terms of the skilling part of this before we kind of talk about more what happens at scale when you actually need to staff for this position and all of that? Is there any other skill-related stuff you wanted to talk about?

Nadiem: I also thought about that, and a bridge might be also then discussing the role later on as to sum it up once again. So, data product management, from my perspective, is a combination of different capabilities or skills which are coming, on the one hand side from product management, and from design on the other side, from data and data science and machine learning. We covered this in viability, desirability, feasibility, and datability. So, these are four dimensions, if you want, so what you, like, combine or aggregate together to become a data product manager. The point I want to set here is there is no education for data product management today, or there’s no, you know, university degree or something like this.

I mean, there’s some courses out there, course providers who are teaching, if you want, so educating data product management, but you can become a data product manager when you coming from one of—out of these four domains. So, you can come from business and learn more about design and tech and data; then you’re coming in from the viability side. Or you can come from the desirability side, from the design side of the house, and you learn more about management and data and tech. Or I’ve seen a lot of good tech people, regardless now from software engineering or from data science, who grew into the management role and learned about viability and desirability. So, there’s nobody out there—from my perspective—who really has all the four dimensions from day one. It’s more like an evolution: you’re coming from one of the domains or from one of the fields and then you extend your skill set by those dimensions over time.

Brian: I would agree with that. I see that with product management in general, almost all of today’s digital product managers came out of some other field and it’s a very—it’s a wide and shallow kind of field; you need to know a little bit about a whole lot of stuff to kind of get something out the door that’s valuable, so it’s a broad skill set. I’m curious of your take. I mean, I just had—Kyle Winterbottom was just on the show here, who runs a data and analytics recruiting firm and he helps find talent and place talent. And the thing that I’ve heard, and I’ve heard this from people I’ve been interviewing for the data product leadership community that I’m launching as well as just generally in the market.

Dear data listeners listening to this, you need to let go a little bit, if not a lot of the technical requirements that you expect candidates to have to do this work. I find they’re still way too much focus being put on tech stack that they know, languages that they know. But, can you code in Python? If your product managers are coding in Python, you’re probably doing it wrong. Something is probably wrong because that’s not the kind of work that they should be focused on doing. I’m trying to make this super black and white. Argue with me if you feel differently, but I’m hearing way too much technical focus.

Nadiem: I mean, this is maybe a bit boring for the audience, but I do agree with you. I would love to argue. But once somebody said to me, “Nadiem, you’re a little bit like a duck who’s not able to fly or swim properly.”

Brian: [laugh].

Nadiem: That’s exactly—this is the way how I feel sometimes. But at Mindfuel, we are educating our people in something which we call a [unintelligible 00:05:42]. So, from a personal development perspective, so people have a lot of different capabilities, but not in full depth. You know, like a [unintelligible 00:05:50]. This is super crucial to us. So, people have a very good understanding about data and tech, but at the same time, for me, it’s very important that they have a broad skill set instead of being an expert in one dimension.

And this is still a challenge out there in the market, especially when we’re looking into the data industry. Experts sometimes are overwhelmed by the fact that when they’re switching their role or position from, let’s say, a classical expert role in the team towards a leading function or management function, even a PO function, where they have… all of a sudden they have meetings, right, management meetings and [recording 00:06:27] meetings, and they have to take care of others stuff and prepare the backlogs, or even report to a CFO and so on and so forth. And this, it’s nothing bad about it, it just needs different skills. And you can be very brilliant than that. One of our credos here at Mindfuel and my personal leadership style is, focus on your strengths and manage your weaknesses.

It means if you are very good at something, then you can become probably the best, but at the same time, you always have to make sure that you’re not just neglecting your weaknesses, but keep them managed, either enriching you by colleagues or other people who can fill the gap, or you are just aware that you have your strengths and you have your weaknesses and you try to activate them the right way.

Brian: Are you familiar with any experiments or companies that you’ve talked to where they have hired data product managers who came, not from analytics or not from data science, and they put them into a data team? And not going well? Like, they came out of design, they came out of digital software product development, they came out of sales, I don’t know, but they came out of a non-technical place, but they have either worked in data, they’ve worked around data a lot, or they have a passionate interest for it. Have you heard any examples of that not working? And I’m not talking about somebody so green they have no id—like, they’re completely clueless. I’m talking about someone that’s had some experience working with data products, but they did not come out of the technical field. Are you familiar? I haven’t heard any examples of anyone even getting a chance to wor—like, a leader who said, “Yeah, we hire all of our product managers out of non-technical.” No one’s ever said that to me.

Nadiem: No, no, no, no, I’ve seen that in my career, and I’ve seen that, also, actually, quite recently. A person who takes the role of the data product manager is not very techy, if you want. So, I mean, has a good basic understanding, can communicate, and can talk to the people, but has no real understanding of the technical, let’s call it implementation. I think it can work out super good if there is a tech lead at the site, or a tech lead, an architecture lead, or a data science lead, or a machine learning leader, or whoever, who can cover this and build the bridge towards the product manager so that they play more or less like a duo. Because I think personally, the crucial success of data products when we think about now, the success of a data product initiative where we want to go break even and want to build a great data product for an internal department.

At least 50% are customer communication and are understanding the needs of the customer, of the recipient of the product, as we discussed in the last episode. This is super important for the success of the data product. So, if a product manager has a very good communication skill and still is able to break down the needs in a proper way or in a good understandable way to its tech lead, or its engineering lead or data science lead, then I think it works out super good. If this bridge is missing, then it becomes a little bit tricky because then the distance between the product manager and the development team is too far, if you know what I mean.

So, they don’t… yeah, I don’t want to say they don’t accept him or her, but it’s very—it becomes more difficult to gain the necessary authority and respect, maybe sometimes, if you’re not be able to communicate in a technical way. This is the challenge I see sometimes, and this is even crazier if you’re not responsible just for one data product, but if you are responsible for entire portfolio because then the management piece of it is even more important, but then you need a very good connect to the execution engine [unintelligible 00:10:09].

Brian: My model, I guess, is I tend to think in terms of teams and not so much that—and maybe you can talk about this in your model where there’s an assigned role who’s a data product manager—I see that as even if that role exists as a single person, that has one leg of a minimum three or maybe four-legged stool, the other two legs, again, maybe they’re not a single person, it could be a shared duty, but you have design, you have that product responsibility, and you have engineering or technical. But in data products, I tend to think of you might need engineering and data science separately because those are fairly distinct and both important. But all four of those disciplines need to be represented. And it’s a shared understanding of the problem space. So, the product person might be the tip of the spear, but they should be very good at the problem discovery piece, as you said, the communication skills—which is largely about listening and processing what’s heard. It’s not about talking when we talk about communication. We’re actually mostly talking about listening, in my opinion, asking good questions.

But the team would collectively own the problem space, as opposed to the data product manager is the only one who owns the problem space and everyone else is just there to bang solutions out. That’s where to me things go wrong because the team gets so focused on delivering the outputs on a schedule that they lose sight of why are we doing this, and how will we know if we did a good job? How do we know if we made an impact in someone’s life? Because ultimately, that’s what we’re doing. Someone is going to use this.

Did we make an impact or not? If they don’t feel that and they’re just, like, “I’m just for delivery. I just deliver what was asked.” I don’t know you—talk to me. Maybe there’s time to jump into this role thing about shared product problem ownership versus the DPM fully owns the problem space and is just responsible to communicate it down or across.

Nadiem: So, to discuss this properly, Brian, I think we have to take it back into the situation of a data product manager within a data unit of a corporation because this is the 90% of the cases; the data product manager is installed or this role is installed within a data unit. And to properly discuss this kind of shared problem space, discovery and all that stuff, we have to come back to what we also discussed in the last episode, what is a data product? Because if we’re talking about data as a product, for example, when we talk about data assets, then the problem discovery piece of it is very, I wouldn’t say clear, but limited. Because the way how the user or the recipient of the data product is consuming the product at the end is predefined. It is through an API or it’s through a provisioning service or a microservice or whatever.

So, then we are talking very much about the technical data product if you want to simplify it. We talked about the classical analytical use case as we defined it in former times, then the data product manager is the go-to guy for the business person, you know? We have a person who acts as a customer, or who is the person with the need. And the person with the need from the line of business, they go to the data product manager and they talk to the data product manager about their needs and requirements and all that stuff. In reality, I have to admit, these kinds of meetings are very often very business related to the needs of marketing or sales or supply chain or whatever line of business the colleague is coming from, he or she is coming from, and it is not—it doesn’t provide too much gains or insights for a tech lead, you know what I mean?

It is more like the data product manager is to first go-to person to which the line of business is going to. They are converting their needs into a, kind of, requirements and then the data product manager takes it more to the team and explains what they have discussed and so on and so forth. True exploration maybe happens then in the workshop two or three weeks after, where then a few people from line of business come together, a few people from the data team come together, and then they exploring together the problem space and breaking down the leads. I agree with you, in the moment when we build a data product for the external market or if we build a true data-driven service, where we have these, kind of, big discovery spaces where we have to talk to various customers to various users to running through interviews and so on and so forth, then it makes total sense and I’ve seen that in my career, where we truly developed data-driven digital products with a true business case and with, really, go-to-market and so on and so forth. [with 00:14:59] this kind of data product, you definitely need a shared problem space discovery where you have all the people alongside your design and your tech lead, and so on and so forth.

But then for these kinds of products, there is a true business case behind that to run that. Because the efforts to have always your designer [attentive 00:15:18] always your tech lead at hand, this must be also reasonable from a certain point of view. And the reality, when you build several data products or several data use cases, there is not always the justification to bring five people into a discovery meeting, due to the fact that there’s a lot of work on the table, you know?

Brian: Yeah. And I want to be clear, I’m not talking about meetings. And when I say shared ownership, I don’t mean everybody does everything together. That’s not what I’m saying. I agree, for efficiency, the business wants a point person; they don’t want to talk to five people every single time.

But there’s a difference between everything gets run through this funnel. In my head, I was beginning to disagree, and then you circle back and you said the real thing a couple of weeks later, we actually bring the people who have the need together with the people who make the stuff, and I’m like, “Yes, as long as that’s happening at some point, as long as the team who’s making it has direct exposure to the people who are going to use it at some point and they understand why we’re doing this and what the shared problem is, that’s fine.” I don’t care how the meetings are run.

We’re back to—like, talk about skills—like, do you need Python or do you need to figure out who needs to be in this meeting? What is a good use of time here? Do I need my tech lead here? Do I need my data scientist here? This is the kind of skills that you need to have to figure out how to be efficient and move quickly, especially if you do have a portfolio. That’s exactly what I’m talking about.

So, I think we’re in agreement that as long as we’re exposing the makers to the people who have the need, when that’s not there, there’s no empathy for what’s going on and we just kind of go into our silo. And it’s like, “I don’t know, someone requested this over in the Europe office, and it’s some sales guy, and Spain wants this field and it wants a model, or I don’t know, so I’m just going to do that and move on.” At that point, people have gone native and this is why data teams are not delivering value, I think; they’re so disconnected from who’s using it. But I agree with you, we do need to point of the spear; there needs to be someone that’s running this and maybe it’s time to talk about this role.

So, tell me about this role now in this. You have this portfolio concept there about you’re running multiple experiments, just like your stock portfolio. Some things may work, some may not. I love that analogy. Do you need to wait until you have multiple data products going on your team before you hire a DPM, a staff DPM? Or is that the sign that you need one? Is that the triggering moment that someone needs to have a portfolio view?

Nadiem: Yes, I would say so. As we said, there are activities, the activities are covered by someone, and before you think about hiring a dedicated person for this set of activities, I would say 80% or even 90% of all the activities usually lie in the beginning with the head of data or with the data leader. Because a data leader in a classical data organization within a corporate or big corporation, they have these, kind of, okay, how many use cases can I do? How many data products can I produce? Where should I put my resources in? I have maybe certain amount of budget, I have certain amount of people, and I have usually more demand than I can supply.

So, this kind of optimization problem relies with typically the head of data to a certain degree. And then when it overwhelms or when it becomes a lot of work, it makes sense to think about hiring a data product manager who takes off the load from the data leader or from the head of data. And this usually happens when the data organization have a certain size or a certain number of use cases up and running or wants to build a certain number of data products, then you start building up your portfolio. I think every data leader out there has an Excel spreadsheet or a list of prioritized use cases or the most relevant use cases for the business strategy. So, they have this kind of prioritized list, you can think about this list as a portfolio.

You know, some of these use cases are super valuable; some of these use cases maybe will not work out, and you have to identify those who are bringing real return on investment when you put effort in there. And with investment, I don’t only mean money, I mean brain capacity, resources, people, time [of the 00:19:33] lines of businesses. So, everything can be measured in that kind of investment following an idea for a use case. And to manage this out, there need someone who’s taking the responsibility for this. And this is typically the data product manager.

Brian: You bring this role in. I think a lot of leaders right now are wondering about oh, is this whole data products thing, is this a fad? Like, it sounds good. We do have a low adoption problem. Our stuff’s not getting used. Will this help me?

If you bring one in, like, if you were a DPM coming in, are you going to be looking to show some wins quickly or are you going to be looking to work on the highest business value problem that’s riskier, that may not work, that may be a lot more work. It requires AI, for example, but it’s high risk. Where do you go? Do you get some wins on the board or do you focus on I need to show some bottom-line cost saving or revenue increase or something? I tend to be more of the camp of early on, you want to get some wins on the board because that buys you the time to have the bad stock picks in your portfolio and have some misses. But if you’re starting out with giant projects and everyone has inflated expectations, that’s when things go wrong. But I’m kind of curious your take on how we prioritize picking the use cases as a DPM?

Nadiem: Typically—this is super good question because there are different ways how to address this. Typically as a data product manager, when you start, you build up your portfolio. Either there is an existing portfolio. Let’s say… I don’t know, we have a backlog of 50 use cases, 50 ideas, whatever we want to call them, which maturity level they have, maybe out of this, we already have built five products, ten products. So, let’s assume our portfolio consists of ten delivered products running in the market, 20 use cases, 50 ideas. So, you have different majorities among your portfolio, and now the data product manager has different strategies to follow up.

So, number one is the adoption strategy. You take the existing products already in the market—and the market means already live with one of the line of businesses—and you try to increase the adoption. So, you have sales recommenders—a sales price recommender somewhere for Market A. You try to bring as many other lines of businesses to this product, make them use, increase the adoption so that instead of five people are using the product, you want to increase the number of users up to 500 people using that product. So, this is one strategy a data product manager is always hunting for because he wants to [have 00:22:01] as many, what we call it, business opportunities on data products to increase the adoption.

For the rest, for example, existing MVPs or use cases or ideas, you typically build up the use case matrix, right, or the prioritization matrix. On the y-axis, you have the business impact. On the x-axis, you have the technical feasibility, the datability, whatever you want to set as the dimension for the tech domain, and then you build up the metrics, right? So, use cases or ideas on the upper right of the corner are the ones which are easy to realize or easy to adopt or easy to implement and bringing a high business impact. And this is what we call the juicy lemons [laugh].

So, these are the ones you really try to pick up. When you have this kind of matrix view on your portfolio, there are different so-called selection strategies, depends on your risk. So, you can also start with the ones with the super high impact, but very risky or difficult to implement. You could take one of these products and saying okay, if I’m able to build this product within the next six months, it creates super good added value to my P&L, measurable. For this maybe I need now an LLM, so a large language model, which we don’t have today.

But we know if we build up this capability, the rest of my portfolio is shifting towards the right, becomes easier because if I deliver on the most difficult one, my assumption is that the rest will going to be easier as well because I learned a lot on this case. And so, depends on your business strategy and also a little bit on your risk affinity. It really depends on which selection strategy do you go. Most of the data product managers are risk-averse, as you said. They tried to set quick wins, get trust, gain time, convince that there is added value in data. So, they typically go with the right upper quadrant if you want. So, identifying data products and use cases and ideas, which are measurable, easy to realize, with a high impact on the P&L. And this is where they set their money on.

Brian: To me it’s actually a strategic approach if you realize that product role is a role of relationships. And so, you need to form relationships, and trust is a big part of that, and delivering on what you said is a part of that. And that’s why it’s like, to me, there’s a lot of risk going out with the giant bang project with really high expectations and not delivering on that because now you’re kind of negative. You’re starting out in a negative position, unless you’re in a highly mature environment that’s used to experimentation, who sees experiments as just, “Oh, what did we learn? That didn’t work. Great. What did we take forward from this? Round two. Let’s go.” I don’t think that’s in the—especially traditional enterprises, that is not the environment people are usually operating in, you know. Like [laugh].

Nadiem: Yeah, but I can say, I can mean, I had a chance last year to be head of data myself at interim for a few months because a client of ours wanted to hire someone, they wanted to, like, gap the waiting time—

Brian: Close the gap. Yeah.

Nadiem: And I jumped—close the gap and I jumped in. I have skin in the game, you know? That time, I truly had to deliver business value. And I had very little number of resources, I was limited in resources. I had just a few people in the team. And budgets were also, like, not overwhelming.

So, at the end of the day, I was able to pick out of the portfolio—so I built up a portfolio at the end with around 70 use case ideas, and I prioritized three use cases. One was a cost-saving use case, the other one was an added-revenue use case, and the third one was process support use case. One out of three failed. The process support use case didn’t work out, but the other two ones after the MVP had measurable contribution. So, I was able to reduce operations costs by 15% and I was able to create added revenue, seven-digit number per year, in euros, which was a huge case for this company.

So, I was able to increase the sales side of the house to sell more products with the help of AI, and this had very significant contribution to their P&L. I achieved this within, like, nine months and I did this exactly following this matrix and prioritization approach. And what I want to say with that story is it’s not about magic [laugh]. So, all I did was not like, I did a lot of—I’m not a magician for data product management. I just focused on a very strategic view on my portfolio and tried to identify those cases and those data products where I can believe I can easily develop them, I have a high degree of adoption with my lines of business, and I can truly measure the added revenue and the impact. For those, I invested and one out of three failed. So, I have to accept that evidence is small, but 33% failed if you want. So.

Brian: Let’s just stop for a second. In the US that would be a C-in school.

Nadiem: Yes. Okay.

Brian: And in business, we would probably call what you did a home run, potentially, in baseball lingo, or winning the world cup. So, for those you listening, like 66%, we’re not in school anymore. And this is kind of a joke back to machine-learning model accuracy. We did an episode called “When is 51% Accurate?” A home run with a machine learning model, it just needs to be better than a guess and it can have a large impact.

Congratulations on that. I’m curious, when you’re doing your analysis to pick use cases, thinking about this low adoption problem that is a real challenge for a lot of teams, is the adoptability or the usability of—or the utility—the perceived utility or adoptionability in the future one of these variables that you look at? How hard will it be to get people to change what they’re doing and use the new one? Is that ever a factor in your calculus?

Nadiem: Absolutely, it is. It is. From different perspectives. One thing is the so-called opportunity mapping towards the product I want to build. So, how many lines of businesses, how many people do see a need in the product, and how many business opportunities are mapped to this product?

Because a business opportunity is not necessarily always just one line of business. But within a line of business, there are several opportunities they can address when they have this data product. So, the number of opportunities mapped to one data product is, of course, one thing I look at heavily. And then of course, how many potential users or how many people will even need this product I’m building?

And so, this is another number I’m looking at. If my product is only addressing three people, don’t get me wrong, these three people are also important, but I prefer use cases, products, whoever, where I have a potential, we would say total addressable market, total observable market of a few 100 people. And because then I know that I have to convince, convert, adopt, enable a percentage of, like, five to ten to fifteen people who get used to the product, and then hopefully it takes off from there, it comes all together. You look at these kinds of dimensions. As a data product manager, you always try to maximize the outcome of your portfolio.

As a true data product manager, from my point of view, you are someone who is, on the one hand side, empathetic for the lines of businesses, to understand what their underlying needs and what the problems are. At the same time, you are a business person, right? You try to optimize the portfolio for your own, kind of, needs if you want, so because you have business goals coming from your leadership team, from your head of data, or even from the person above, the CTO, CIO, even CEO. So, you want to make sure that your value contribution is always transparent, and visible, measurable, tangible. And so, I think this is super crucial in [unintelligible 00:29:58].

Brian: I think, too, that’s why, again, we talked about using the comb analogy where all the teeth on the comb are these different skills, marketing is also relevant in internal data product management. Because you talked about there’s 500 salespeople; maybe I need to get ten of them to show some value, but I really need to get most of them to use this to really have the big impact. How do I get the salespeople to stop doing it the old way?

Nadiem: Exactly.

Brian: That can be a marketing problem. It can be a design problem; maybe you can solve it with design by just making it overwhelmingly better, easier, faster to use the new way, or it could be a marketing thing about data, where it’s like it’s a story, it’s about how you’re going to get more commissions because look at how everyone else is doing it now? They’re not spending time in Excel anymore. They’re on the phone with this awesome insight, every time they pick up the phone. Like, I don’t know, but that is another skill, which is like—[laugh].

Nadiem: If we look into pro—yeah, absolutely. If we look into classical product management, I mean, the product manager has to understand how to market and how to go to the market. And it’s this exactly the same situation with data product managers within your organization. You are as successful as your product performs in the market. This is how you measure yourself as a data product manager. This is how you define success for yourself.

And by the way, this is also what your development and delivery team needs to hear because they love to develop something, but they also feel satisfaction if the product they’re producing, they’re building, they’re coding, they’re predicting, is used by someone. I mean, we have to be very honest, also developer is super happy and satisfied if he has the knowledge that his product, her product is used and creates added value. I mean, this is why we’re doing what we do. And so marketing, if you want to call it like that, or go to market, or storytelling, or explaining the added value, or creating win-win situations, or even win-win-win situations, even for the leadership team of the company, this is what product management and data product management is all about. This is our role.

Brian: I like that you mentioned this about the technical teams, too. I feel like I’ve been hearing a change, even just since I started the podcast—and maybe Covid is responsible for this, and Kyle talked about this a little bit, too, but more and more skilled technical people want to have impact. Maybe this is bias towards younger people with less years of experience, but they want to work somewhere meaningful, they want the work to get used, they want to know what it’d account for. I don’t know if that’s because everybody’s remote. Even if you’re a developer, it’s like, “Well, you hang in the”—I remember Lycos was, the side of the building with all the lights off.

That was, like, engineering. They didn’t like the lights on. But you know what? They all liked that together and they were all there together. In quiet, but they were together. And I don’t think that’s the same as being at home alone all the time. And I wonder if Covid, like, made that thing where it’s like, “I can code anywhere now. What do I want to do with my life? I can make good money from anywhere. But why am I here?” I think that’s really important to know that your work counts now, even for really strong technical people.

Nadiem: I can just tell you a story from Mindfuel. You know, we are developing a SaaS platform for data product management, and we have an engineering team. I would categorize them as classical software engineers. And you know, they are amazing what they’re doing in coding and all that stuff, but I can also tell you, their eyes are sparkling and they are very happy when we win a customer or when a new feature is used, or—they truly want to understand how it is used, what they can do be better, and how the product can evolve. And it’s not just, “Eh, okay, I finished my code. Have you done the review yet? I checked it in, I published it, and”—

Brian: “Not my problem anymore.”

Nadiem: Exactly. “Not my problem anymore and where’s the ops guy? Okay, I hand it over, and ciao.” They are following our Slack channels about customer adoption, customer success. They read all that stuff, they post things on Slack in the evening when they learn about customer success and how we can improve.

So, my experience with engineers these days, they are fully into the game and they fully understand how their contribution can be. And this is, from my point of view, because we have a great product management team at Mindfuel, and they also value these engineers the right way. So, I’m very happy about that, that engineers at Mindfuel feel that they’re not just coding, but they’re contributing to success. And this is, I think, what do you have to do in times like you just mentioned. You’re in Covid; engineers can work from wherever, [unintelligible 00:34:35] fight for resources or for good skills, people. So, I think that’s super important.

Brian: I’m going to quickly jump to your SaaS product that you’re developing. So, I’m going to visualize this for people really quickly, which, jumping back to the portfolio conversation about the DPM having this portfolio, like your stock portfolio, except it’s actually your data products. You want to know a little bit about what the underlying technology is behind these, who’s using them, what the value of these things are. So, you guys actually built a software application, a SaaS tool for DPMs, correct, that are using this portfolio approach. So, I tried to visualize that for people so they can kind of see this.

Can you tell us a little bit how you went about deciding to make this and designing this thing? And I’m talking about just the UI, but you came up with this. It’s a little bit of a meta conversation, but maybe tell us a little about the origins of the SaaS product that you’re rolling out? In June, right?

Nadiem: Mindfuel is a SaaS company from day one and the entire company is set up as a SaaS company. We did—or we do professional services for data product management to even learn more about the discipline. When we started, there was no clue. Like, I did my research in the US, I mean, from Germany, talking to people on the west coast in the US to understand how they do their product management. How did we came up with the idea for the SaaS product was in digital product management. Even there, a lot of things are still manual.

Nowadays, there are good digital product management solutions in the market supporting the digital product manager. There is software for digital product management, but when we looked into the data world and the world where I’m coming from in data organizations, everything is done manually, either in Excel spreadsheets or in PowerPoints, or, like, you have people running around collecting the information of how far are we with the product, who is using the product, you’re doing a lot of interviews and trying to find out what the adoption rate is, and so on, and so forth.

So, the idea from day one was, when we know how the processes look like, when we know how to prioritize the right way, how to manage the portfolio, we should provide a technical solution right away from day one, so that data product managers can not only learn about the methodology, but they can also leverage this directly with a technology or with a SaaS solution. It came all together one, hand-in-hand actually, the methodology, way of working, how to become a data product manager, how to do this, how the activities and all the work is looking like, and at the same time, the software is supporting you day-in, day-out to keep transparency and clarity on your portfolio until the next steps you have to do.

Brian: Is that something that you’ve been testing and building along the way with people that are going to use this? Was it hard to get feedback?

Nadiem: So absolutely, we developed this with more than 40 data leaders. So, we did then the discovery ourselves [laugh] again, for our own product. So, we interviewed; three, four major discovery rounds with data leaders. We split up the groups. With one we did the problem discovery, with others, we did the problem validation, and we went into the solution discovery. So, we really developed a solution along the market.

I told you once, it all bases on our mindset framework, and this framework is more or less an R&D piece, if you want. So, it’s a guidebook: it explains how the product management works. And overall, more than 10,000 hours of work went into this framework to understand how data product management should be done. So, we’re sipping our own champagne, I think this is what you call it, yeah, right? So—

Brian: Eating your own dog food.

Nadiem: Yeah. No, I—

Brian: [laugh].

Nadiem: —don’t know how polite we are.

Brian: You have the French version.

Nadiem: Okay, yeah. Yeah. Exactly.

Brian: I like that one better than dog food.

Nadiem: Yeah. So, we’re sipping our own champagne. And we are, of course, following product management principles to build our own product the same way. And we did this with data units and data leaders all over the globe.

Brian: Is there a particular story you could share about maybe some initial direction you went with the design of this solution that was wrong, and you got feedback, and you’re like, “We thought that was going to be awesome. That’s not working.” Like, backpedal. I want people to understand the iteration that goes into this, you know, and I imagine you had some of those.

Nadiem: Yeah, we learned a lot along the way, let’s say it like this. In our case, the most craziest or difficult part of it was, we are data product managers ourselves, so we are experts in the field, and we had this amazing group of people who supported us in the discovery. Whenever we designed a solution where we thought it is the right way because we are experts in the field and we showed it to the people, [laugh] we actually failed. Because we are biased. We are already biased when designing the solution.

Although people at Mindfuel worked as data leaders for different number of years already, but within our bubble at Mindfuel, we misunderstood sometimes the market need and then we designed a solution where we thought it’s super nice [laugh], where we thought if I would be back in my old job, I will do it exactly that way. And when we showed it to the data leaders, they just said, “You know what? Who needs that, exactly? Because I don’t.” To start even with the simplest visualization pieces, how should the portfolio look like, how do the stages in a portfolio look like from I don’t know idea to MVP to next maturity level, next maturity level.

So, there were so many minor things and details how you should visualize it, and how many, I don’t know, levels a portfolio should have, and is it a level do we build portfolio of portfolios? So, something like this, if you have different lines of businesses, we always had a good idea how to do it, but whenever we don’t did proper discovery, we did it twice, let’s say [unintelligible 00:40:11]. [laugh].

Brian: [laugh]. Yeah it’s temp—“We’ll just get it out there,” you know?

Nadiem: Okay [laugh].

Brian: Yeah. And the problem is a lot of people don’t want to go back and throw the old one out. The sunk cost bias: the more you’ve put solid effort and engineering into it, it’s really tough to throw it away and start again, so this way, you want to work low fidelity as long as you can. I really appreciate you coming on, Nadiem, to talk about all this. It’s been great. Where can people learn more about you and the company?

Nadiem: Everything about me, you’ll find probably on LinkedIn. Just look for my name: Nadiem von Heydebrand. And then more on mindfuel.ai. There you’ll find information about professional services, about our software. So, the software is called Delight. So, delight.mindfuel.ai is the software page. So, happy to get back to me for any further information.

Brian: Cool. Well, we’ll put those links in the [show notes 00:40:58]. And Nadiem, thanks for coming on for part two. This was really fantastic. I’m glad we got through all this [laugh].

Nadiem: [unintelligible 00:41:03]. Thank you very much for having me, Brian, and take care. Talk to you soon, yeah?

Brian: Sounds good. Cheers.