Today, I chat with Manav Misra, Chief Data and Analytics Officer at Regions Bank. I begin by asking Manav what it was like to come in and implement a user-focused mentality at Regions, driven by his experience in the software industry. Manav details his approach, which included developing a new data product partner role and using effective communication to gradually gain trust and cooperation from all the players on his team. 

Manav then talks about how, over time, he solidified a formal framework for his team to be trained to use this approach and how his hiring is influenced by a product orientation. We also discuss his definition of data product at Regions, which I find to be one of the best I’ve heard to date. Today, Region Bank’s data products are delivering tens of millions of dollars in additional revenue to the bank. Given those results, I also dig into the role of design and designers to better understand who is actually doing the designing of Regions’ data products to make them so successful. Later, I ask Manav what it’s like when designers and data professionals work on the same team and how UX and data visualization design are handled at the bank. 

Towards the end, Manav shares what he has learned from his time at Regions and what he would implement in a new organization if starting over. He also expounds on the importance of empowering his team to ask customers the right questions and how a true client/stakeholder partnership has led to Manav’s most successful data products.

Highlights / Skip to:

• Brief history of decision science and how it influenced the way data science and analytics work has been done (and unfortunately still is in many orgs) (1:47)
• Manav’s philosophy and methods for changing the data science culture at Regions Bank to being product and user-driven (5:19)
• Manav talks about the size of his team and the data product role within the team as well as what he had to do to convince leadership to buy in to the necessity of the data product partner role (10:54)
• Quantifying and measuring the value of data products at Regions and some of his results (which include tens of millions of dollars in additional revenue) (13:05)
• What’s a “data product” at Regions? Manav shares his definition (13:44)
• Who does the designing of data products at Regions? (17:00)
• The challenges and benefits of having a team comprised of both designers and data scientists (20:10)
• Lessons Manav has learned from building his team and culture at Regions (23:09)
• How Manav coaches his team and gives them the confidence to ask the right questions (27:17)
• How true partnership has led to Manav’s most successful data products (31:46)

Quotes from Today’s Episode

• Re: how traditional, non-product oriented enterprises do data work: “As younger people come out of data science programs…that [old] culture is changing. The folks coming into this world now are looking to make an impact and then they want to see what this can do in the real world.” — Manav 
• On the role of the Data Product Partner: “We brought in people that had both business knowledge as well as the technical knowledge, so with a combination of both they could talk to the ‘Internal customers,’ of our data products, but they could also talk to the data scientists and our developers and communicate in both directions in order to form that bridge between the two.” — Manav 
• “There are products that are delivering tens of millions of dollars in terms of additional revenue, or stopping fraud, or any of those kinds of things that the products are designed to address, they’re delivering and over-delivering on the business cases that we created.” — Manav 
• “The way we define a data product is this: an end-to-end software solution to a problem that the business has. It leverages data and advanced analytics heavily in order to deliver that solution.” — Manav
• “The deployment and operationalization is simply part of the solution. They are not something that we do after; they’re something that we design in from the start of the solution.” — Brian 
• “Design is a team sport. And even if you don’t have a titled designer doing the work, if someone is going to use the solution that you made, whether it’s a dashboard, or report, or an email, or notification, or an application, or whatever, there is a design, whether you put intention behind it or not.” — Brian 
• “As you look at interactive components in your data product, which are, you know, allowing people to ask questions and then get answers, you really have to think through what that interaction will look like, what’s the best way for them to get to the right answers and be able to use that in their decision-making.” — Manav
• “I have really instilled in my team that tools will come and go, technologies will come and go, [and so] you’ll have to have that mindset of constantly learning new things, being able to adapt and take on new ideas and incorporate them in how we do things.” — Manav 

Resources and Links:

• Regions Bank: https://www.regions.com/
• LinkedIn: https://www.linkedin.com/in/manavmisra/

Transcript

Brian: Welcome back to Experiencing Data. This is Brian T. O’Neill. I have Manav Misra on the line today who is the Chief Data and Analytics Officer of Regions Bank. How are you?

Manav: Doing well, Brian.

Brian: Great, great. Well, we met through Tom Davenport, who recently published some articles and you guys did a webinar with IIA about this idea of what he calls product orientation to doing analytics and AI and machine learning work. This is obviously a core thing that we talked about on this show is how do you bring software methodologies to doing analytics and AI work and what I broadly call decision support applications and data products? So, what I wanted to get from you today to share with the audience is, what does it mean to do the work this way? What are the benefits of doing that? Maybe what are some of the challenges if you’re trying to change from whatever the status quo method is to this model?

So, that’s really what I wanted to dig in with you today. So, in order to understand what it means to do this work when we talk about products and user-centered machine learning and analytics, what does the not version of that look like?

Manav: Yes, Brian. So, that’s a great question. Traditionally when the world of decision science, as you called it, got going, it was a number of statisticians who we’re building predictive models. And their philosophy was more of a research-y philosophy. They would explore through the data, try and find interesting insights, build a model.

And their approach was that, “Look, we’ll build a model, but it’s somebody else’s business to figure out what to do with it. You know, they can use it if they want; they can figure out how to put it in deployment, but somebody needs to figure that out. We’re above all that, we’re kind of figuring out all these neat scientific things here.”

Brian: “I can’t be troubled with that usability stuff.” Like—[laugh].

Manav: Yeah, exactly. [laugh]. And—which was fine, in the early days. You know, it was more of a research-y approach to things. But as things matured, it was really important to figure out how do you actually get these models to make a difference.

And then you had to start thinking about who’s going to be using the outcomes of these? Do they understand what the impacts are? How do we get them to adopt these? How do we get them to use it on a regular basis, on a daily basis? And all of those concerns, therefore, led to this idea of product orientation and user-centered design.

Brian: Got it. And do you think that the overall culture and climate of—you know, when we talk about enterprise data teams—has that culture and climate changed, and now the issue is, “No, no, no, we don’t want to just do research-y type work that theoretically might be useful to somebody, but it’s not my job to—no, I really want this work to matter, I want this work to get in production, but we don’t know how to do that, or we don’t care?” Like, because clearly, there’s still, as you know, there this plague of low adoption of models, applications, data products; a lot of them, don’t ever see production, let alone create any tangible value. Or teams just have no idea whether or not they’re creating any type of value or getting used. This is still a problem, so is the problem the culture is still the way you described it, or they don’t know how to do this? Like, do you have some theories about that?

Manav: Yeah, and I think the culture is changing. And as younger people come out of data science programs where they’ve taken both computer science courses as well as, you know, the foundational data science courses, that culture is changing. The folks coming into this world now are now looking to make an impact and then they want to see what this can do in the real world. And so, as that population group changes, the philosophy is changing, and therefore the impacts that each of these efforts drives is changing dramatically.

Brian: Do you primarily think the methodology to solve this is through hiring different kinds of people to do this kind of work, or is there also a model of training them, or is it tough to change the old blood? Like, any thoughts about how you’ve done that? Because I’m sure you don’t just start with a greenfield. Like, “We have zero team at a bank. Now, I get to start brand new.”

Like, that’s just—so many people do not walk into that environment as a leader, I’m sure. So, what was your approach because I imagine not everybody had this mentality when you came in to Regions?

Manav: Yeah absolutely. So, I think it’s a combination of both. There were people that were part of the existing team that were eager to adopt this kind of mentality, they just didn’t have the frameworks, the tools, the training to be able to do that. And then as we brought in some new people, they came in with that mindset already. So, it was a combination of both.

And the important thing was to make it easy for them to adopt this approach and make it a way of doing work on a regular basis. And that requires a combination of tools, systems, processes that are in place, and people can just pick those up and adopt them, get them going right away, and be able to be productive in that kind of environment, day one.

Brian: What are some of the—particularly in the process area and some tooling, maybe not so much on the technical tooling, but in terms of frameworks and methodologies and things like this to do, you know, very user-centered work, what are some of those? And secondly, how do you get individual contributors, and even principals, to actually take the time to do some of this non-technical work that needs to happen in order to make sure the technical part of the work actually gets used? I find this as a challenge is that there’s always this perception of it’s, too slow, we need to go faster. And the thinking is that fast is associated with well, if we’re writing code and wrangling data and doing technical stuff, we’re therefore making progress. But my thing is, like, well, you actually slow down upfront a little bit to speed up overall productivity, which means better stuff comes out to the end of the pipe.

And it will start to come out faster, but it will actually matter as opposed to just this illusion that you’re doing stuff quickly and it’s making a difference. How do you get the team to do that, especially people with very technical backgrounds that may associate their—my hands, my technical knowledge is what I’m here for?

Manav: That’s exactly right. So, you know, a lot of that onus falls on the leader, and it’s on the messaging and the repeated communication of that message. My leadership team does a tremendous job of that in terms of communicating to every new person who joins the team that this is really important because if we do it right this way, if we follow these best practices, and the frameworks and tools that we’ve put in place, the outcome is going to be so much better. It’s much faster, it’s a much more agile way of actually delivering the solutions to the end customers of ours. So, it’s the communication and getting that buy-in from the team, and then once that momentum starts to build, any new person coming in, or if there is somebody from the existing team at the bank who joins our team, they naturally lean into that and they get to adopt that approach right out of the gate. So, there’s a lot of communication that is necessary and buy-in that you get from the team members in order to drive this forward.

Brian: Did you have to bring in people that have product backgrounds, like from software product management, software product design, in order—because I imagine, like, you alone can’t change that entire organization on your own—if it’s just generally new to the culture of data people, how do you get that snowball going, this train moving up to, you know, cruising speed?

Manav: I actually created roles which didn’t exist at the bank prior to me getting there, which were focused on this. And we brought in some people from outside, but more than anything, it’s people that buy in into that philosophy and approach and are willing to learn and read up and get going with that out of the gate. So, it was a combination of both. So, we did bring in some people from outside that had the product mentality and experience, but then again, we had the frameworks in place and the material to read up on. And if people had that mindset, they adopted it, and then they got really ingrained in it.

The other thing is that as we got the right people going, these roles became very critical. What I call a data product partner, these are our product managers, the owners of these products. We brought in people that had both business knowledge as well as the technical knowledge, so combination of both they could talk to the quote-unquote, “Internal customers,” of our data products, but they could also talk to the data scientists and our developers and communicate in both directions in order to form that bridge between the two.

Brian: It sounds like you have some, kind of like, internal training or something like this, so if you were hiring someone that maybe didn’t have this native product mentality, you can run them through the Regions’ recipe so to speak? Is that right?

Manav: Yeah. So, we’ve created that framework and the documentation around it. It’s taken some time to get that standardized because different product managers had different internal customers that they were dealing with and different pressures. So, in turn, initially, it was, “Hey, let’s just get going,” but then we’ve started to document that and put that into a formal framework that any new person, both in the data product partner role, but also on the data scientist role, or the visualization role, or data engineering role, picks that up and then understands how all of this comes together.

Brian: Tell me a little bit, about how many of these data product managers do you have? And maybe, like, percentage rel—like, is that something you could talk about? I’m trying to help the audience get a sense of size of how large your team is, and then proportionately, how many of these people operate in this role.

Manav: I would say about 10% of the team is in that data product partner pillar.

Brian: And now that you have that there, you mentioned that it is a very critical role… obviously, it’s like, “Well, this is a new thing. Why do we need this?” Maybe you had to sell this up the chain, I don’t know, to have this new type of role. So, someone’s probably wondering, “Well, what am I going to get, Manav? What do I get for this extra headcount? Like, how is this going to help me?”

What are the benefits that you get from this kind of thing? And is there any baseline by which you can compare, you know, now that you’ve been kind of running with this for a while? Can you talk a little bit about those?

Manav: Yeah, so absolutely I had to sell this. It wasn’t a role that existed in the bank, so I had to convince the powers that be to get the allocation of headcount to that function. But the benefits that were laid out was that, look, each data product we will build will deliver some sort of critical impact to the bank. This could be a financial impact, it could be a strategic impact to the bank in terms of driving us along our overall strategy, each data product we’ll take on, there will be a business case that will be built. And we will ask for a role associated with that, but I will make sure that it generates more value to the bank than the investment that goes in.

And we will measure each data product as a P&L on its own, so to speak. So, there’ll be a certain cost involved in terms of creating the team, but we will measure and show the value that it will deliver. And that approach, we’ve been very methodical and religious about following. And for each data product, we show what kind of value will it is delivering. And therefore, the creation of these roles and the investment required is justified and people get more comfortable with it.

Brian: Are you able to quantify any of that? And secondly, are you able to share any of that information with us?

Manav: Yeah, so at a high level, not going into individual numbers, but—

Brian: Right, right.

Manav: —I would say that each of our data product has delivered a significant positive value to the bank. You know, there are products that are delivering tens of millions of dollars in terms of additional revenue, or you know, stopping fraud, or you know, any of those kinds of things that the products are designed to address, they’re delivering and over-delivering on the business cases that we created.

Brian: We should probably step back here and ask you what’s a data product, at least at your bank?

Manav: The way we define a data product is it’s an end-to-end software solution to a problem that the business has. It leverages data and advanced analytics heavily in order to deliver that solution.

Brian: So, just yesterday, I saw a definition that a data product is simply a set of data that you deliver to a user, and then maybe that’s exposed through a bunch of, like, API endpoints or applications. But the focus was on thinking that it was just a set of data, so I thought it was very interesting, two words you said: it’s a software solution, and it’s also an end-to-end software solution, which suggests that the deployment is built into the success. It’s not, do the data science work and then someone figures out how to deploy it and that’s a second thing. At least that’s what I think I’m hearing. I’m a big fan of this idea—and this is a very design-oriented approach—which is the deployment and operationalization is simply part of the solution. It’s not something that we do after; it’s something that we design in from the start of the solution. Do you also take that approach, or do you think of this little bit differently?

Manav: Yes, absolutely take that approach. And I have seen that other definition as well. I think it comes from that the data mesh world. But I think it’s really important for at least us at Regions to define data products in the way that I did, which is, it is an end-to-end software solution and therefore requires a design orientation from day one. It requires putting the quote-unquote, “Customer,” of that data product at the center of what you do.

You have to think about what that customer is trying to achieve, you have to think about what that user experience is going to look like, you have to then define and design the user experience appropriately. And that requires the right user interface, it requires the right kind of performance characteristics. A lot of that product orientation thinking that goes to building a software product is translated and put in into this data product that we create. So, the other definition you describe, while valuable, I think is limited in its overall impact to what we can do.

Brian: I completely agree with that. I think this was a—actually I think it was a McKinsey… it was a McKinsey article in HBR if folks want to look it up. There are four authors writing about it. Was one of the big four firms. They were actually talking about a bank case study as well in there. Probably [laugh] not your bank.

There is some good stuff in there, actually, that I really liked in it, I just felt like it was the baseline idea of what they’re talking about, like, it’s—at least for me, it’s a different language. We’re not talking about the same definition there. But that’s them. I want to talk to you.

So, you mentioned design, user experience, user interfaces. When I teach my training on this, I always tell data professionals, design is a team sport. And even if you don’t have a titled designer doing the work, if someone is going to use the solution that you made, whether it’s a dashboard, or report, or an email, or notification, or an application, or whatever, there is a design, whether you put intention behind it or not. There’s no nulls in this activity. So, who does the design at Regions? Is it design [unintelligible 00:17:08] with titles of design? Is it, we’ve trained our data professionals to do this? Is it a team approach? Talk to me a little bit about the design and user experience piece.

Manav: So, it is varied amongst the different data products we built out. In some cases, we brought in people from our digital team. So, our digital team builds our mobile app, our web experience, you know, all our customer-facing digital properties, and they have this expertise of designing for the end customer. And we’ve leaned very heavily on them to work with us as we interface with our internal customers—and most of our data products are designed for our internal customers—then help do the wireframes, do the mock ups so that we can then present them to our internal customers, get feedback. The data product partner is the one who’s orchestrating all these and driving towards an end result, but we lean on the expertise of our digital team to be able to create that user experience that we’re looking for.

And with that, we’ve been able to generate some really good user experiences for our data products. In other cases, if it’s a simpler product, the data product partner may do the wireframing themselves and get that out there, but for the most part, we lean on our digital team to be able to do that design work for us.

Brian: How do you know those experiences were good?

Manav: Well it’s, again, the voice of the customer. So, we present them to our internal customers, get feedback, we watch how they interact with the user interface. So, we’ve had to make changes based on that. You know, again, we try and instrument everything that we built so that we can see where they’re spending time in the application and where they may not be spending time. So, we try and get all that information back and then incorporate it into next versions of our product.

Brian: It sounds like you’re also doing what I call low-fidelity prototyping, potentially. So, potentially some non-digital prototyping. I’m a big fan of, like, how fast can we do learning cycles, and what’s the minimum amount of product or interface or experience can we create that we can start to get information back so that we don’t spend, you know, three months doing plumbing work, and then finally we pop an interface on top of the model and this little tool that we made, and then finally we get it in front of somebody at which point there’s four months of sunk costs. Working with it your UX team, do you guys do this kind of low-fidelity work?

Manav: It’s an agile cycle where our business users, our internal customers are actively engaged, so we can present things to them with each iteration and get feedback rapidly. So, all the wireframing and mock-ups are put together without actually doing all the back-end plumbing initially so that we can get those initial feedback points and then incorporate them into the next version.

Brian: What’s it like when you put together a bunch of designers and a bunch of data scientists and analysts? Like, has this been a nice happy soup that everyone likes to eat? Are there challenges? Are there growing pains on both sides there? Like, if I was a leader, like you, and I’m like, “This sounds really great. Maybe I should call my digital department and get some resources on this next project,” what should I expect? Should I expect there to be, like, a culture clash here and it’s going to take time? Tell me a little bit about that dance.

Manav: By setting the right expectations for the whole team to start with, I think it makes it a whole lot easier, so everyone’s rowing in the same direction and know what we’re going after, we’re going after building a product and there’s an excitement around it. I should also mention that we’ve also built a data visualization team within my organization. And so, this isn’t your typical business intelligence kind of team. This is a set of people that are focused on how do you present data in the best manner in order for people to consume it, find insights, and be able to make decisions based on it. So again, depending on the product, right, so there are certain types of products that have heavy data visualization components that go in, and our digital team wouldn’t know how to best present that for an audience.

And so, our visualization team has the knowledge of the science of visualization and they create those components that our digital team can incorporate into what they’re presenting to our customers. So, it is a team sport. It is, you know, lots of people that we lean on their expertise and their experience to be able to put together that final product.

Brian: Sure. Yeah, that makes total sense to me. That’s fairly common, too. And for listeners, larger teams, even design teams will have certain very detailed specialization skills in them which may or may not include that data viz piece. I do think it’s very important that the dance between user experience, user interface, and data viz well orchestrated because the date viz, especially when it’s not going to be a print, a PDF, a hard artifact, that’s not changeable, as soon as you add interactivity into that, whether it’s using BI tools or whatever the deployment method is, that’s where things start to come out of the data viz world and into the user experience and interaction design world. So, it sounds like you’d have a nice blend of these teams working together with their specific specialties.

Manav: That’s right. And you’ve got it just right. And as you look at interactive components in your data product, which are, you know, allowing people to ask questions and then get answers, you really have to think through what that interaction will look like, what’s the best way for them to get to the right answers and be able to use that in their decision-making.

Brian: If you were to start over, like, right, now, you just decided to take a new job somewhere else, you walk in the door to the old culture again, are there some growing pains that you know not to repeat, or some learnings that you can reflect on, some challenges having put this approach into place that Regions that you don’t need to repeat again?

Manav: Over time, I did have to swap out some of the talent that existed. And it just became apparent that some of the folks just couldn’t adapt to this new world. I would probably get to that decision a lot sooner once it was clear that it wasn’t going to be a good fit. To get the right kind of talent in there and get going faster, I think is probably something that I would have done. The other piece is that—this isn’t so much a learning but then an evolution of tools that has happened from a technical standpoint, from a machine-learning ops and deployment of AI and machine learning tools, it’s a much richer set of tools today than existed four years ago. So, we brought those on now. I think if you were starting off, you would have those in your toolbox right away and you’ll be able to make much better progress there.

Brian: On the—everyone’s wondering what are the names of those people so I don’t hire them. [laugh]. But I won’t ask you that. However, I will ask you, what are the signals that you’d be looking for now such that you would act sooner? Are there some clear signals that say, “You know what? This person’s method here is just not a fit for the way we dance over here.” What are those signals?

Manav: The clear one is that if they’re religious about a particular tool or a particular way of doing things, and just refu—and they keep saying, “I’ve been doing this for 30 years; this is the best way of doing things.” And that’s a red flag that you need to pay attention to right away. There were people that said, “Hey, you know, I’ve been using this tool for 30 years. It’s the only way of building models in a bank,” various excuses and explanations that they would come up with, you need to jump on that pretty quickly. So, I have really instilled in my team that tools will come and go, you know, technologies will come and go, you’ll have to have that mindset of constantly learning new things, being able to adapt and take on new ideas and incorporate them in how we do things.

So, I feel very good about the team mindset that we’ve created. It’s one of constant learning and being able to adapt and grow very quickly. So, I think that’s the key thing to look out for and get those kinds of people as part of your team, that are willing to learn and see that as an imperative in their job.

Brian: I mean, I imagine there’s probably some leaders wondering, like, how did you get all these people on board with this, especially like—when I—I’m going to stereotype, you know, the people that I’ve seen, you know, come through my training, and I know that a lot of them, they want to get better at this stuff, but inherently, they struggle with things like the customer’s quote—well, I’m going to use ‘internal customers—the internal customers don’t know what they want. We’re trying to get the requirements and they don’t know what they want. And they want us to figure that out, but I don’t feel comfortable asking, “Why do you want a dashboard about which ATMs are underperforming?” They don’t want to dig into that because they feel like they’re prodding into something that’s not their business or they don’t understand that business domain. This whole necessity of surfacing, especially the latent unarticulated problems and needs that may not be in a quote, “Requirements document,” this type of work is foreign, or it’s uncomfortable for a lot of data professionals.

Besides these data product managers that I know they’re probably maybe on the front lines of this, but I imagine if they’re the only ones doing this, that’s maybe a bottleneck, and at some point, your data scientist and maybe your visualization people, they probably need to be part of those discussions, too. So, how did you do that? Or is that—maybe my stereotype is wrong, and it’s just not a problem.

Manav: No, no, it is something that we had to coach even our data product partners, you know? So, they were at some point interacting with some of the most senior people at the bank, and they would be in a room where they were the junior-most person. I had to really inculcate in them that you may be the junior-most person but this is your product. You have to ask the questions to get the answers in order for you to build the best product.

So, don’t be afraid of, you know, asking questions. Don’t be hesitant in terms of, “Hey, I’m kind of new into this.” If you have ownership and you want to build the best product, you have to have the answers to the questions that you have. And so, I had to encourage them to speak up, to ask questions, and they’ve done that—for the most part—really well. They’ve taken that on.

The other question that you had in there was that it’s not just them; it’s the data scientists asking those questions as well. So, we have our data scientists, or data visualization folks, data engineers, in those meetings with our internal customers, and I give them the same message: “Look, for us to build the best product, each of you need to know what those business imperatives are, what are the big challenges that they’re facing? What are the things that they’re trying to address? So, don’t hesitate to ask questions.”

And I also lead by example. I mean, I’m a curious person and I keep asking questions in meetings. And I may not have been in banking all my life and so I may not know every little detail, but that doesn’t stop me from asking questions. I express to my team that you have to have the confidence that you’re a smart person; if you’ve got a question, it’s likely a good question, so don’t be afraid to ask that question.

Brian: Yeah, I think that’s great advice. I try to remind people that if you think of this, instead of prodding into something that’s not your business or looking stupid, and instead, like, first of all, if I ask the right questions, my work is probably going to matter more and it’s much more fun to work on stuff that ships and makes a difference, but secondly, if you’re elevating the internal customer that you’re working for, if the questions you’re asking are going to, frankly, literally help that person looked better and their own job and empower them, or reduce their workload, or make them look good to their boss, or show better results, or whatever that may be, think of your questions as a gift instead of a “I’m getting information out of you and I’m challenging you.” Instead, it’s an act of service. And it’s a different mentality. I think it’s hard to maybe feel that when you first started this, but that’s how I’ve always approached this as a designer. It’s like, “This isn’t to serve me, it’s to serve you, and the more I understand what you need, the better I can do my work which is going to serve you. So, let me ask these questions. And that’s why I’m—it’s not to challenge you; it’s to further your pursuits.”

Manav: Different data products, the customers have a different level of engagement. So, the very best ones, the business owners have bought into this as well, and so they’re working side-by-side, shoulder-to-shoulder with our team. And they’re encouraging them to ask questions as well. So, you get that bidirectional partnership that happens. And once you get there, it’s just a beautiful thing to see.

Brian: A hundred percent agree with that. I actually recently heard a designer frame this too as like, you know, even as design teams, we’re not designing the products for the customers. We’re designing it with the customers. And that’s such a critical thing to understand is this is design is an act of facilitation. It’s something that we’re actively doing with people. We’re not off in a corner or in a basement somewhere or in a cubicle doing it, and then we kind of have the big reveal.

There shouldn’t be a big surprise at the end. It should—

Manav: Exactly.

Brian: Be, like, “Oh, there it is.” Like, “I’ve been waiting for that.” Like, [laugh]—

Manav: Yeah.

Brian: —you know, like, no surprises. Like, “When can I touch it? When can I use it? We’re excited. Give me more.” You know, that’s kind of what you’re looking for.

On that note—I want to wrap up here in just a minute, but I wanted to ask you, is there a story you can share about a particular customer who maybe went through this journey with you? Maybe they were used to the old way and maybe had a flip where it’s like, “Oh, God, I got to ask the quants another question.” Like, “Ugh.” And now it’s, like, different. They felt the impact. They’re seeing the value. Any happy story that you could share with us about a customer that’s been through this with your team and has something to share?

Manav: A few of our products have just been tremendously successful. And we’ve gotten to that happy state where the business leaders, the users of the product all buy into this. And they’re looking for those meetings with our teams so that they can figure out what that next module should be, or the next set of features should be, et cetera. Now, it wasn’t like that day one, right? Again, to your point, they were used to this kind of, “Hey, I have a question. I’ll put it out there and then you know, you guys can come back in three months and hopefully, you’ll have given me the answer I needed.”

We had that engine that we had to rev up, you know, with regular meetings, regular interactions, executive team leadership. So, we would have myself and the business leader in quarterly meetings, reviewing what the team was doing so that both teams saw that this was a joint effort and we’d be working together to achieve a goal. And so, some of our most successful products have that true partnership that has really emerged. And they’re constantly looking for, you know, we’ve now got multiple modules in some of these products and we continue to add new ones, so it’s a push-pull. Our team comes up with some ideas, the business team comes up with some ideas, we prioritize them, we put them on the roadmap, we work together to build the next module and next set of functionality. Not every data product is like that, so some still require that engine is still in the process of getting revved up, but some of them we’ve achieved that state and it’s really great.

Brian: It’s been great to talk to you. Do you have any closing advice for our data science analytics and technical product management leadership audience?

Manav: Focus on this approach of creating products that solve real problems. And once you do that, with that customer at the center of it, it will drive a lot of your processes, your tooling, your mindset. The impacts are just tremendous. The outcomes are tremendous. You’ll have teams that are extremely engaged, teams that are really excited about the work they’re doing because they see the impact, they see it being talked about by the CEO of the company, the top leaders of the company. So, it’s a real win-win because you’re really making a big impact on the business side of things, but you’re also building a very engaged, excited team that’s really interested in solving problems.

Brian: Awesome. I love it. Manav Misra, Chief Data and Analytics Officer from Regions Bank. Thank you for coming on the show. Where can people get in touch with you, follow your work, any events, books, speaking anything that people might want to check out that you’re doing?

Manav: The easiest way is through LinkedIn. So, you can always contact me through LinkedIn and you’ll see things that I am either speaking at or involved with.

Brian: Great. Awesome, I will put your LinkedIn profile in the [show notes 00:34:48]. Thank you so much for coming on Experiencing Data. It’s been great to talk with you.

Manav: Thank you, Brian.