Today I’m chatting with Bruno Aziza, Head of Data & Analytics at Google Cloud. Bruno leads a team of outbound product managers in charge of BigQuery, Dataproc, Dataflow and Looker and we dive deep on what Bruno looks for in terms of skills for these leaders. Bruno describes the three patterns of operational alignment he’s observed in data product management, as well as why he feels ownership and customer obsession are two of the most important qualities a good product manager can have. Bruno and I also dive into how to effectively abstract the core problem you’re solving, as well as how to determine whether a problem might be solved in a better way. 

Highlights / Skip to:

• Bruno introduces himself and explains how he created his “CarCast” podcast (00:45)
• Bruno describes his role at Google, the product managers he leads, and the specific Google Cloud products in his portfolio (02:36)
• What Bruno feels are the most important attributes to look for in a good data product manager (03:59)
• Bruno details how a good product manager focuses on not only the core problem, but how the problem is currently solved and whether or not that’s acceptable (07:20)
• What effective abstracting the problem looks like in Bruno’s view and why he positions product management as a way to help users move forward in their career (12:38)
• Why Bruno sees extracting value from data as the number one pain point for data teams and their respective companies (17:55)
• Bruno gives his definition of a data product (21:42)
• The three patterns Bruno has observed of operational alignment when it comes to data product management (27:57)
• Bruno explains the best practices he’s seen for cross-team goal setting and problem-framing (35:30)

Quotes from Today’s Episode

• “What’s happening in the industry is really interesting. For people that are running data teams today and listening to us, the makeup of their teams is starting to look more like what we do [in] product management.” — Bruno Aziza (04:29)
  
• “The problem is the problem, so focus on the problem, decompose the problem, look at the frictions that are acceptable, look at the frictions that are not acceptable, and look at how by assembling a solution, you can make it most seamless for the individual to go out and get the job done.” – Bruno Aziza (11:28)
• “As a product manager, yes, we’re in the business of software, but in fact, I think you’re in the career management business. Your job is to make sure that whatever your customer’s job is that you’re making it so much easier that they, in fact, get so much more done, and by doing so they will get promoted, get the next job.” – Bruno Aziza (15:41)
• “I think that is the task of any technology company, of any product manager that’s helping these technology companies: don’t be building a product that’s looking for a problem. Just start with the problem back and solution from that. Just make sure you understand the problem very well.” (19:52)
• “If you’re a data product manager today, you look at your data estate and you ask yourself, ‘What am I building to save money? When am I building to make money?’ If you can do both, that’s absolutely awesome. And so, the data product is an asset that has been built repeatedly by a team and generates value out of data.” – Bruno Aziza (23:12)
• “[Machine learning is] hard because multiple teams have to work together, right? You got your business analyst over here, you’ve got your data scientists over there, they’re not even the same team. And so, sometimes you’re struggling with just the human aspect of it.” (30:30)
• “As a data leader, an IT leader, you got to think about those soft ways to accomplish the stuff that’s binary, that’s the hard [stuff], right? I always joke, the hard stuff is the soft stuff for people like us because we think about data, we think about logic, we think, ‘Okay if it makes sense, it will be implemented.’ For most of us, getting stuff done is through people. And people are emotional, how can you express the feeling of achieving that goal in emotional value?” – Bruno Aziza (37:36)

Links

• As referenced by Bruno, “Good Product Manager/Bad Product Manager”: https://a16z.com/2012/06/15/good-product-managerbad-product-manager/
• LinkedIn: https://www.linkedin.com/in/brunoaziza/
• Bruno’s Medium Article on Competing Against Luck by Clayton M. Christensen: https://brunoaziza.medium.com/competing-against-luck-3daeee1c45d4
• The Data CarCast on YouTube:  https://www.youtube.com/playlist?list=PLRXGFo1urN648lrm8NOKXfrCHzvIHeYyw

Transcript

Brian: Welcome back to Experiencing Data. This is Brian T. O’Neill. Today, I have Bruno Aziza from Google on the line. How are you?

Bruno: I’m great. Thanks for having me.

Brian: Yeah, yeah. I’m looking forward to this. I was just watching one of your—do you call it CarCast?

Bruno: Yeah. It’s a friend of mine, actually, an industry analyst from Gartner, Merv Adrian who should get credit for this. Because, you know, I’ve been doing this stuff for a couple of years and he said, “Hey, you should call this a CarCast.” I never thought of that. Because it’s true. I do it every Sunday from my car. It’s low production, it’s nowhere near what you’re doing. But yeah, it’s called the CarCast.

Brian: Yeah, they’re short little, like, news briefings almost, topics, things that are, I guess, floating around in your head and things that you’re seeing. And I was digging into one of those about data products and data product management, which will kind of be the focus of our chat today. So, it was good to kind of see what was going on there. And you were in São Paulo coming back from a customer visit or a conference or something, I think, was the first one I saw.

Bruno: Yeah, that’s kind of the concept of this, as you know, a few years ago, I was meeting with Chief Data Officer and they were explaining to me that, you know, it’s a really crowded space, lots of buzzwords, and they’re trying to figure out, okay, what’s real, what’s not. And given that, you know, my life is really spending with customers and partners, and you know, I get a good sense of the top trends that are happening. There’s a whole lot of people on LinkedIn that tag me on relevant posts. And so, that’s what I do, is I basically, on Saturday, I read everything that I might have missed throughout the week, I do a little synthesis for myself, and I just extract the top five things that happened in data and analytics that week. So, it’s not like I said, it’s not meant to be this big production.

It’s just, ideally, it’s here are the top things that happened this week that if you’re a data leader, VP of analytics or Chief Data Officer, you probably want to know about. And that’s the idea. It’s not—for people listening, it’s not an opportunity to send me your marketing material, you know? I’m not promoting my company, I’m certainly not going to promote your company in those. It’s just a service to the community. And frankly, selfishly, I’m also learning a lot because people reach out to me and they say, “Hey, you know, here’s what I think, and here’s what I’ve seen.” So, we’re all kind of learning through the whole process.

Brian: Just to give some context, my understanding is you manage a team of product managers who each own or co-own a set of the various Google tools that fall under the Google cloud space, is that correct?

Bruno: That’s correct. So, I run outbound product management for data analytics. And you know, the apps products I focus on are products like BigQuery and Dataproc and Dataflow and Looker. And so, we have a great team of very seasoned product managers whose job is to really, one, you know, understand what’s happening with customers, lots of customers that innovate across our platform. So, we have a global presence, as you might guess and so we really tried to gather the best practices, and then turn out to the rest of the audience to say, “Hey look, this is what we’re seeing.”

So, spend a lot of time with that spend a lot of time with partners, and then of course, spend a lot of time making sure that we provide the best products, services, and we’ll make it as easy as we can for customers to innovate quickly on top of our platform. It’s a topic I’ve been really passionate about for, I want to say, 25 or plus years, you know? I’m the data guy [laugh]. I’ve only been in the data world. That’s kind of the idea of this team is how do we help accelerate innovation for customers across the world? And my team, like you said, are product managers who have been industries just as long, sometimes some of them longer than I have been, so we can help customers with that level of experience.

Brian: I want to jump into this topic of data product management in a moment. But what does just good software product management looks like to you? Or good software product managers? Particularly because you’re working in this kind of vendor tool space. And I want to also know about are the traits of a data product manager who is explicitly building a solution that might be built on top of a stack of tools is that a similar skill set to someone who’s actually creating vendor tools, the traditional software product manager? What does a good one look like?

Bruno: Yeah, it’s a great question because what’s happening in the industry is really interesting. For people that are running data teams today and listening to us, the makeup of their teams is starting to look more like what we do for product management. So, this idea of the data product manager is become very evident for a lot of our customers, and it’s pulling from the discipline of Product Management. I think there was research from Harvard recently that said, “If you treat your data like a product, you can reduce the time it takes to implement these new use cases by as much as 90%.” So, this idea of implementing the discipline of product management that your organization is very useful.

Now, of course, I’ve been like you said in this space for a long time, so product management in software is something that I’ve hired for, I was a product manager myself when I started. And there are a set of attributes that I think are essential for, you know, what an excellent product manager looks like. [unintelligible 00:05:20], you know, the resource that I point people to is a great blog that I remember reading—I think there’s a blog that’s 12 years old, by the way, so this is not a something that just published last week—by Andreessen Horowitz—actually it’s Horowitz that wrote it—and called it “Good Product Manager/Bad Product Manager”, if you want to Google that. It is, I mean, right on, you know?

When I started as a product manager that attributes were—the first one is, you are the CEO of the products. And that idea, I think, is essential because, as a CEO of the product, you don’t just think about the engineering or just the software; you think beyond the bits, right? You think about how are people just adopting this, you know? And what’s required to make them successful? Geoffrey Moore has this idea of the whole product, you know?

Your product is not the solution in isolation; your product is part of a bigger picture, where you know, you’re trying to help the consumers of this product be successful with what it is that they’re trying to do. Another attribute is, in my mind, the product manager understands the jobs to be done. So, this is a—again—other theory. I don’t know if you read the book, The Innovator’s Dilemma. The author of this book is MIT professor and he talks about this idea of jobs to be done.

A job is essentially what you’re trying to do as a customer. And you’re trying to identify what are the circumstances the customers are dealing with and what are the obstacles that they have. And how is your product solution or the combination of the product with other people’s solutions, enabling that job to get done? And so, the attributes of, one, ownership, you’re the CEO, you own the experience of the products, and two is work backwards from the customers. What is the job they’re trying to do? Is, I think, is essential to be successful in this discipline. I mean, certainly, the ones that I’ve hired the ones that I’ve seen really become exceptional product managers have these two attributes: ownership and customer obsession, I would say.

Brian: Yeah, that tracks very logically with my experience working with many PMs over the last 20 years, and also the way we approach it in human-centered and user experience design, which is always kind of starting with the end, right, and you’re working it backwards from these goals and objectives that people have: “I want to reduce my work,” or, “I want to give a better presentation and I needed evidence to support my choices,” or whatever, you know, the data use case is, but we’re working backwards from that and then compiling the right set of technology solutions that need to be built or bought or whatever in order to facilitate that. We don’t start with let’s haul this data from 15 systems, let’s put it all together into something and then clean it up, and then we’ll have all these spigots ready to serve stuff out of them if someone needs something. That’s a very data and engineering-focused approach to doing things this. So, the product orientation, I think, is just like you said, it starts at the end; it’s being very well aware of what the objectives are.

I guess another part of that, right, is not necessarily giving people what they asked for. So, I’m kind of curious how you guys digest this because I’m sure you’re getting feature requests coming from customers that want, like, “Oh, if only Looker had this X capability,” or, “If only BigQuery could do X,” or whatever. And so, you’re probably routinely getting feature requests that have to be unpacked, correct, and you have to do the same thing, even for maybe the audience that’s listening to the show, who are the users of some of these solutions, you’re probably presented with the presenting problem sometimes without context. Is that true and do you guys spend a lot of time unpacking what’s behind those requests?

Bruno: You used a term that I think is just critical here is context. By the way, you know, I realized I talked about his book, but I’m talking [laugh] about the author is Clayton Christensen, the author of The Innovator’s Dilemma. And the book where he really details the jobs to be done is this book called Competing Against Luck. And I blogged about it, I think a couple years ago, but I’m a big fan of that type of theory. And the idea of context is really trying to investigate what is the problem we’re trying to solve.

What’s interesting about this jobs-to-be-done theory really is that the problems themselves have not changed; is the way that we’re solving the problems that change and get better over time, right? So, if you take the simple problem of transportation, for instance—I know it’s outside of the enterprise world—this idea of I need to go and meet with Brian. That’s always been the problem. In the past, I might have solved it with the horse, then I moved to a car, and then all of a sudden I moved with well, this platform we’re using. We’re not in the same city, we’re not in the same timezone, but we are connecting.

So, this need of what is the job to be done here is Brian and Bruno have been able to talk together and brainstorm a set of solutions with the community. That is a problem that really hasn’t changed much. The way we are solving it is the most important thing. So, I think when you’re a good product manager, you look for that, which is, what is the core problem? From that, look at, okay, well, how is this problem solved today?

And if I understand how it’s solved today, what are the areas of frictions that are experienced by the people trying to accomplish this job? What are the ones that are accepted that probably should not be accepted, right? I think another attribute of a great product manager is there’s a point of friction—like today, for instance, you know, we all accept going to the store and buying milk. We probably all do that by eggs and milk and so forth. A good product manager would probably say, “Is that an acceptable thing that I have to get out of my house, get into my car, drive to just buy this one item.”

Like like many of us are going to the store multiple times a week to just buy one or two items. And we have done this for 10 years, 15 years, so we just accept it as a way of we worked. And I think a good product manager looks at a process like that, and says, “Okay, the job is not go to the store to get milk. The job is I need milk because I’m maybe I’m making coffee, or maybe I’m making a dish or anything like that. How do I accomplish that job in the most effective way in 2022 or 2023,” right?

That’s the context you need to focus on. Often, I think the issues that a product manager might struggle with is that they’re so focused on their product that they think that the product is the answer, or you know that it’s the absolute only way to solve the problem. The problem is the problem, so focus on the problem, decompose the problem, look at the frictions that are acceptable, look at the frictions that are not acceptable, and look at how by assembling a solution, you can make it most seamless for the individual to go out and get the job done. I might have over-answered your question than this, but I really think that’s the attribute that we look at as really good understanding of the problem itself. You know, the other trap of product managers is getting into solutioning very quickly and then you end up solving the wrong problem.

And so, spending this time by listening to the customer. Identifying trends, you know, I think one of the things that we do very well and I’ve seen work really well as well as the customers know what they want to do in terms of the job they’re trying to accomplish. They might tell you that they think they should solve it with this tool or that tool or this solution or so forth. That’s the bit where you have to be careful because you got to get to the core of the problem first and then you go to from the trends you’re seeing across multiple customers, multiple use cases, and so forth, then you can solution effectively. I think that’s where people get tripped up a little bit. The job of the product manager is to know how to do that extremely effectively.

Brian: I think—at least what I think I’ve seen frequently is, especially in the data science and analytics space is that we are jumping into solutions because we think that problems come to us. And they’re actually expressed as tactical solutions; they’re not expressed as problem. And then we directly address the ask without knowing what’s behind the ask. The issue there is often we really don’t know what someone needs and the prerequisite customer exposure time has not been taken to go and figure out what’s behind this request.

Is this a one-off thing? Is this something they do all the time? What’s their real objective behind asking for I need a machine-learning model that will do X, which is a loaded term and assumes that that’s the right approach to it. Which it may be one way to do it, but it may not be the only way or the right way, or the fastest way to get some progress going. I’m sure you’ve noticed, I think that being able to see the world as you talked about, abstracting, like, what’s my real objective here is to have more time with my family at breakfast, which means I don’t want to have to go get in the car just to go get one item, which means how can I improve the amount of family time I have that’s not driving in a car to go get one.

Abstracting the problem like that I think only comes with exposure to the customers to see the world through their perspective, and all that. Which I know you’re doing a ton of if you’re on the road all the time, you’re hearing and watching all the time what’s going on in order to inform what gets drilled down into products and features and stuff at some point.

Bruno: You nailed it with your definition. This idea of deconstructing the job itself. In fact, the book, Competing Against Luck that I was referring to earlier starts with this example of the milkshake. This company that is trying to produce a better milkshake for their customers and they’re realizing that maybe we shouldn’t make the milkshake sweeter, and maybe we should—you go into solutioning very quickly. And in fact, when Clayton Christensen and his team, when they kind of went through deconstructing the problem, they realized, well first of all, there’s two populations people are getting the milkshakes.

There’s early people going through the drive-thru getting the milkshake and as people coming in the afternoon buying the milkshake. Okay, what’s the difference between these two audiences? One of them is driving to work wants a breakfast that is going to sustain through their drive. They want to use it with one hand while they’re driving, so okay, the alternative would have been to do what? Get a bagel. Now, you get to eat it with both hands while you’re driving. Very inconvenient and so forth.

The second population is actually coming in the afternoon with their child. Now, you start seeing, okay, this solutioning is not make the milkshake thicker or sweet or anything like that, you know? In the afternoon, maybe it’s about combining with the toy because they’re coming with the child. And in the morning, it maybe it is how do you make that milkshake last and be more filling because what it competes against is full breakfast and so forth. And so, the ability for a product manager that [unintelligible 00:15:22] thinking is, look at how you deconstruct the problem first and think about what friction points you would remove in order to provide an exceptional experience for the user, if you will, so they can achieve their job.

I mean, in the way, you know, I always joke with my team is, as a product manager, yes, we’re in the business of software, but in fact, I think you’re in the career management business. Your job is to make sure that whatever your customer’s job is that you’re making it so much easier that they, in fact, get so much more done, and by doing so they will get promoted, get the next job. So, if you start thinking about it that way, how do I see the reality from their eyes? How do I see their point pressure? How do I see their friction, the issues they might have getting things done, and how do I make that easier, then I’m the best partner for that customer. That’s what a product manager should be.

And then owning the delivery of that from A to Z is a huge attribute, right? Because it’s so easy to say, “Hey, I just own this part of the equation,” well the customer doesn’t care about that, right? You should be looking at the solutioning of a well-understood problem from A to Z. That’s a mindset that is very unique.

Brian: Yeah. I mean, that tracks well, with a lot of what’s happening in user experience design, which is so intertwined with product management. And it’s this idea of creating outcomes for the people. How can I improve somebody’s life? And if you can do that by reducing work or giving them status or increasing their perception as being a thought leader in the business because they’re making decisions driven by data or whatever it may be, but part of the idea is, like, how do we make this person’s life better in some way?

And if you’re focusing on that, you’re going to be delivering real value to them because at the heart of it, all the objectives are aligned around the business value and all of that. That’s ultimately their wish, too, is to get business value out of it, but the path to that is to actually deliver value at the user level, at the human level, right? Get the adoption going, create the value in their eyes as they see the world and the business value will follow on top of that. So, it’s a very human-focused approach, right, as opposed to just seeing it as here’s this logical—we built this model, the data is great, it has high predictive power and we’re talking about all the attributes of the technology, but we’re not talking about how does it fit into the jobs to be done or that the work the tasks that the person who’s going to consume it and use it—or who’s going to get value from it indirectly—how are we improving their life with this solution, even if it’s technically right?

Bruno: In our field today, you know, there’s no question that there’s a lot of data, it’s growing, et cetera, and we can be talking about. But the number one pain point is extracting value out of this data. I think this research is showing, like, 68% of [unintelligible 00:18:06] still can get value out of their data. And I think the way to unlock that is to really deconstruct the problem. What’s in the way between my data and its value?

We’ve seen this, like, specifically in database technology or the data platform and concept of the modern data stack. And a simple way to think about it is serverless, right? So, in the past, well, okay to work with data, you have to think about servers and capacity and so forth. Well, serverless kind of take that problem away; you shouldn’t have to do that. Now, if you double-click into other types of tasks that are getting in the way, administration, right, so the creating indexes worrying about partitioning your data, all these things, you know, as a product manager, you started thinking, “Okay, here’s a list of things that a really talented data individual has to go through in order to get value of their data. How can I just take those things away?”

Another example is Spark. People want to work with Spark, well, standing up infrastructure for Spark takes 50 to 60% of someone that wants to work with Spark. So, is this an acceptable friction? As a product manager, you should probably devise a system that just takes that right off the bat. Like, why aren’t we able to just work straight with Spark?

Why isn’t just secured with the rest of the platform? Why isn’t billing at the job level rather than the infrastructure? So, those are the questions that product manager who works really closely with their customers starts asking these why’s. Why does this need to happen? If it’s not the main job, is this a task that actually needs to be done by this particular individual?

We’re right in the middle of that right now. It’s a beautiful time to work in data in 2022 and 2023 because we have all the technology that can unlock this, which is now the solution around it—appropriately—for the problem at hand. And I think that is the task of any technology company, of any product manager that’s helping these technology companies is don’t be build a product that’s looking for a problem. Just start with the problem back and solution from that. Just make sure you understand the problem very well.

I’ve had my fair share of failure in the career [laugh] building the wrong products. That’s where I just go south is that you get enamored with the solution and unfortunately, the solution is inappropriate for the problem. Because you misunderstood what the problem was.

Brian: To echo what you said in the design framing, or at least—Jared Spool is a great label for this, which is Goal Time versus Tool Time. And so, your Spark example is a great example of there’s a lot of Tool Time requirement before I ever get to do anything with Spark, which we can call my Goal Time, right? The actual analysis of the data or getting the insights getting the value, but I have all this labor and tax that goes with it upfront. And I would suggest to teams, like, building, if you’re working on a data platform and that’s kind of your product is looking at high-frequency tasks, right? What stuff is happening all the time by the consumers and users of the data or of the plumbing itself and addressing things like that, either high-value use cases that are maybe infrequent, but they’re very high value, or maybe low to medium value, but they’re repeated so often by so many different people that if you solve those, you’re going to get nice value that comes out of that because you’re addressing real pains that are felt by many.

But the point is, it’s still driven by the sense of friction, right? Where’s their friction? Where’s their difficulty? How can we reduce that there? So, especially relevant, I think, to platform teams, anyone that’s building tooling that might be used, like, by technical users, in particular, data scientists, for example, building models or whatever, how do we get them focused on model building and not the model plumbing? How can we remove some of that tax that they have to pay?

I want to jump into data product management for a second, but in order to do that, I have to ask a question I ask a lot of my guests, which is what is a data product? Because you can’t really have data product managers without having a data product. But this phrase means different things. And I’m just kind of curious if you have a somewhat succinct definition, just as we talk about this, we have a common understanding. Do you have, like, a way to define that you’d like to use or think about?

Bruno: For me, the best definition of a data product is the undeniable artifacts of a data-driven culture. And undeniable measured by value. There’s just too much stock of is your company data-driven. But we don’t know, what does it mean to be data-driven? And then for me, I think what I’ve seen organizations do is that they are able to deliver solutions that derive value for your business, repeated practices. You have to be able to do at once, you have to be able to do it twice, and you have to do it multiple times.

Because, you know, what you’re trying to solve for is also a huge cultural shift inside your organization where now your data team, your IT organization, is no longer responding to requests that are coming in and kind of this treadmill of building data solutions. You’ve changed the game by what you’re leading with the solution. And you’re focused on creating this, if you will, this factory of deploying solutions that are making the creation of value out of data a lot more repeatable and seamless, you know? And there’s two ways that you create value in the organization is save money and make money. And so, that’s the easiest way that I would look at it is, if you’re a data product manager today, you look at your data estate and you ask yourself, “What am I building to save money? When am I building to make money?” If you can do both, that’s absolutely awesome. And so, that’s the data product is an asset that has been built repeatedly by a team and generates value out of data. I don’t know if it’s a good definition. I kind of improvised as we go here, but that’s what I’m seeing.

Brian: If you have a data product manager on your team, does this imply that means a product-driven approach to building data products is being used? Are those non-decouple-able? Is that what that means? And so, tell me a little bit about this data product manager role as maybe you’re observing and in the wild. Does that have anything to do with the process of how the sausage is being made, or not necessarily?

Bruno: Well, absolutely. The great news for, I think, for people listening to us today is that you don’t have to invent this, right? Product management has been a discipline for many, many years. You just have to bore that into your organization construct. What are the attributes of the data product manager.

We’ve already talked about the mindset. Mindset of ownership and the mindset of understanding problem before the solutioning. That’s a key one. PRDs, Product Requirement Documents. That’s an artifact that your product managers should absolutely be in charge of that describe here is the press release if we were to deploy this, right, because regardless if you’re building this product for your internal audience or your external audience, the idea is the same, which is, how do I explain what it is that I’m building and what is the value to my constituents?

So, the PRD is an important document that every product managers should write. It expresses the vision that they have for the product and it forces him to think end-to-end on what’s required to deliver such a great outcome for the audience. The way you organize your engineering efforts related to this product manager, right? Because a product manager is always—any product organization, there’s a ratio of product managers, software engineers. What is it?

So, here’s a way to fail. You believe in this product manager mindset, but you have no engineering resources associated to this product manager. You will not be able to output this product once, and you certainly will not be able to output it repeatedly. Now, the construct is, how do you organize yourself with a software engineering? And then there is this idea that when you build the products, you don’t just release it.

The minute the product is launched, the product manager needs to think about what’s the next version. They’ve already thought about it. Ideally, they have a roadmap because this is a living thing, right? The idea behind the product is we are designing for things that we understand but don’t understand with perfection because the more you produce answers, the more questions you’re going to get. The mindset of the product manager is saying, “Look, this is V1, and V1 is going to accomplish removing unacceptable piece of frictions I’ve established, but inevitably as it’s getting to market, I will identify other things, a friction that maybe my solution is not effective at solving for, but maybe I’m introducing other frictions that now I need to take into account.”

And so, this whole idea of making a full lifecycle and an ongoing one is really important. That’s why I think about it’s not just about having your product manager; it’s also about having the mindset of the full lifecycle that come back, fixing the bugs, and always thinking about this as a solution that is a living solution inside your organizations. I mean, you take any consumer product today and that’s certainly how you expect that they would behave. Take any product you use today, the minute they’re shipped, you’re going to have new requirement. And that’s what you want, right?

I used to have, when I was at AtScale, the leader for engineering, a friend of mine, Matt, always used this sentence and said, “I want my users to use my product in anger.” Maybe it's a Canadian expression. He’s from Canada. But that’s what you’re looking for because it shows that the audience is depending on this product, it is effectively starting to solve a problem for them, and now they want to advance this. And they’re angry about and then they’re impatient about it. That is the best type of tension you want as a product manager, so you can ultimately get the job done. That’s the idea.

Brian: You’ve described what I call the difference between this project orientation and our product orientation. So, the way I frame this design is that the product design work is never done, we’re never done; there’s just checkpoints and milestones along this path. It’s an infinite game. There’s no end of the game. The game just goes on forever.

That requires a different management approach, though, as well because now you’re talking about supporting this custom software solution that’s living inside the organization, there can be resource issues because a lot of times I think the DPMs don’t have access, they don’t own dedicated resources, just like sometimes the CDO doesn’t necessarily own resources. Can you talk a little bit about what—I don’t know if you’re seeing this much—is there friction here, okay, now, we know we want to do it this way, but the organization isn’t set up for us to do that because engineering is owned by IT, or it’s owned by digital, which is under the consumer arm and that’s not the internal operations, which is where we fall under. But that’s where engineering is and they have a different agenda because the consumer product has this roadmap, but we’re trying to build a machine learning model to do X, Y, and Z. Can you talk a little bit about how these teams are playing together or not, and some of the growing pains that might be associated with implementing this product orientation inside an enterprise?

Bruno: There are three patterns I have witnessed and the first one is the pattern of internal alignment of teams, just like you talked about in there. You know, the way this pattern typically solved is you’re not looking for sponsorship here. You’re looking for mandate. You’re looking for someone at the top saying, “This is an important solution that we’re building. You don’t want to hear projects. That’s a bad word. You don’t want to use an experiment. That’s not what you’re looking for.”

So, that’s the ideal situation pattern, number one, alignment between product managers, engineering, there is a roadmap for building it the first time, there is a roadmap for following through the roadmap and supporting the users of that solution. It is a solution and it’s monetized through, you know, whatever vectors you organization. So, that’s the internal model.

The second model we see is this the external model, where the product manager essentially hires an organization to execute on this particular solution and similarly, he has a plan to pay for the work of the external organization. Typically, the place where it breaks is when the product manager delegates the definition of the strategy. That is a good way to get a sideways type of results. You don’t ever want to do that. You know, the core job as a product manager is understanding the vision, how you align with the business goals and derive value from it. So, that is not what I’m talking about outsourcing; the building of it might be.

The third one is when you actually are able as a product manager to own the definition, the building, the launching, you know what I mean? There are—if you talk about machine learning… machine learning industry has really struggled, it’s very low, I don’t have the stats in front of me, but very low success, right? So, half of the machine-learning models are getting into production. And I think what I’ve witnessed there is that it’s about being unable to reduce the barriers of building a solution and putting it into production. Today, machine learning is fairly hard for the average organization.

It’s hard because multiple teams have to work together, right? You got your business analyst over here, you’ve got your data scientists over there, they’re not even the same team. And so, sometimes you’re struggling with just the human aspect of it. It’s just the human nature; it just happens. When you have two different teams like that, then they’re ineffective at collaborating. That’s barrier number one.

Second, beyond the human silos, you have technology silos, right? So, you have the data scientists, maybe they’re using Python or Spark, and then the business analysts, they’re just using SQL, right? So, they have different languages and so now you got to create some translation there. And there’s a whole issue around infrastructure, typically getting your data scientists, data analysts work with the same, understanding same data, you got to move data, maybe you’re using different infrastructures, old technology stack here, that’s not making this collaboration easy. What we have witnessed is the organizations that are able to actually drive innovation faster, they use the same infrastructure and they have a platform that understands all these languages so you can effectively collaborate.

And they have figured out from a technology, human standpoint—human standpoint can be shared OKRs, for instance—they have figured out a way to reduce the cost of experimentation to nothing. So, now more and more people are able to contribute to the solution. You get more tries, if you will, maybe you get a lowest hit rate, but the process is simpler. I think one of the issues today is, particularly for machine learning, there is this need to orchestrate for perfection. And sometimes we make the simple problems complex and now you get what you get today, which is half the models it make into production because, you know, there might have been perfect in this environment, but in the real world, they actually are dealing with a bunch of other issues you have not designed for. So, these I think making it really hard to succeed.

So, three models that we see the first one is, of course, the best one. But again, even in that one, when you have resources aligned, the word that you’re looking for is not sponsorship. Sponsorship is saying, “I’m with you. I agree its important. I’ll sponsor this, but if it fails, it’s not existential.” Mandate says, “That’s it. That’s the way we do business. We will have a product that will deliver this value based on these terms.” And you’re the product manager, you get to define what the solution is. So, that’s an important one, you want to find the leader in that organization that is behind you on that.

Brian: Yeah, I think that’s required, too, especially with the lack of, quote, “Power,” or ownership over the resources to do the execution work. I think the other thing that comes with that as a clear sense that the product, the DPM, and whoever the other key stakeholder—peer stakeholders are, whether it’s someone from engineering, or data science, or design, or whoever in SME, that they collectively feel like they own this problem space. Not just the solution, but they actually feel ownership of the problem. Like, we are aligned because if we don’t help sales reduce the number of bad outbound phone calls are making, then this whole thing has failed. That is our mission is to improve the hit rate.

We don’t know how to do it yet. Maybe dashboards? Maybe. Machine learning models? Maybe. And a—maybe. Who knows what it is. But that mission is, we got to reduce the wasted time that the sales team is spending. If the engineering person feels that as they’re championing that, and the design and the data engineering and the data science and the DPM.

And it really comes down to the DPM making that statement clear to everyone. And I think sometimes they have to make it even more clear than maybe leadership did because maybe leadership’s, like, “We need to do stuff with AI. We need an AI strategy.” And it’s pretty vague. Maybe it’s a little bit more clear than that, but the DPM gets it down to, “Okay, really what they’re saying is, the salespeople are wasting time.”

That’s really what—when they say that they mean this. This is now what our agenda is going to be. And I think that it really falls on the DPM to be the clear champion of that and to make that clear in language that all the parties can understand that are going to have a stake in it. And if you get that part, right, it’s much easier to get alignment on the solution because everyone knows how we will measure it. “Well, did we make less outbound bad calls or not?”

What are the metri—and you said OKRs—what are the metrics? We can measure this now because we all know what it means to get it wrong. And I think a lot of times that’s missing. When I ask people what are you trying to do? They express it to me in terms of the solution they’re trying to build. Like, they have this tennis match someti—I got to keep extracting it back to what the problem space was.

And then finally they state it and it’s something that’s never been written down anywhere. If you ask five people, they don’t all know this. They don’t—it’s not like—they should have one sentence that all of these leaders could repeat to me on the snap of a finger. It shouldn’t be that hard, but so often it’s missing because everyone is so focused on the solution space and usually some ship that left the dock, which was we’re going to build X thing, it’s going to have a dashboard on it and then there’s going to be a piece of a little AI widget that’s going to tell you something with the chatbot. They all are so focused on that artifact that they think is the answer [laugh].

Bruno: It’s natural, right, because in our industry, when you have high-performing individuals that are used to solving problems, you know, it’s a natural thing to go and say, “Oh, I know a solution to this.” You want to naturally just go to a shortcut. But I think just going back to your point on OKRs, right—for people who don’t know, OKRs are Objective Key Results—is what is the goal? And so, for that, there’s a few things we’ve noticed is first of all, I didn’t say, “What are the goals?” I said, “What is the goal?”

If you can reduce it to just one thing, it’s a great way to galvanize everybody towards a few metrics. And I think the last thing we want is somebody to come out with, “Here are the 50 things I’m going to measure.” Don’t do that because then you will create a bunch of noise, that is an ultimately not helpful. So, that’s practice number one we’ve seen. When it comes to OKRs the few OKRs the best.

Second is, when I’ve said shared OKRs, the best practice I’ve seen—at least with my customers—when there’s a partnership like that between the CIO and let’s say the CMO, they each give each other an OKR they cannot control. The CIO will take a lead conversion OKR. That CIO cannot effectively control the outcome unless they partner with the CMO. It’s an effective way to just engineer, if you will, collaboration inside the organization. And then over-communicate.

What is the feeling of accomplishing these goals? Is the company—I think this is public because it’s, you know, Tesla. You know, they were looking at their training—this is something I heard recently in the public [unintelligible 00:36:57], so I think this is fine to share—but I thought it was very indicative way of how to think about the goal. They’re trying to think about how do I enable my salespeople to think about what I’m trying to achieve during test drives and things like that. And the goal was, I want them to talk about their experience at dinnertime.

So, that’s an interesting way to express kind of how the goal feels. Of course, the metric is the conversion of test drives to people purchasing, but the way you accomplish that is by creating a memorable experience. So, now you’re telling your salespeople in the test drive, how do you make that amazingly, you know, memorable? And so, as I think as a data leader, an IT leader, you got to think about those soft ways to accomplish the stuff that’s binary, that’s too hard, right? I always joke, like, the, you know, the hard stuff is a soft stuff for people like us because we think about data, we think about logic, we think, “Okay if it makes sense, it will be implemented.”

For most of us, you know, getting stuff done is through people. And people, you know, are emotional, how can you express the feeling of achieving that goal in emotional value? And so, in this case, in the Tesla example, conversion of test drive to purchase is through creating this amazing customer experience. So, think about it like that as a product manager: what’s the experience you want to try to bring?

Brian: That ties in well to kind of my wrap-up questions here, but I was curious about you mentioned product and engineering. What’s the role of design and user experience in, like, your Google Cloud products? Like, I think there’s still a fairly large community that maybe thinks these technical tools don’t really need design, they shouldn’t be complicated, like, I don’t need help and all this. And I’m like, a data engineer is also a user of services, as is data scientist. And I guarantee you, there’s work they do not want to be doing.

Just because they know how to do it doesn’t mean it’s time well spent or desired. It can just be a tax even though they know how to do it. So, talk to me a little bit about that experience. Does user experience play much of a factor in how you design these technical tools that you work on? And what do you see in terms of the DPM, your customers in terms of whether or not they are using user experience designers to help make sure that these data products actually get used?

Bruno: Absolutely. If there’s one thing I learned in 25 years in software engineering, is this principle: what is the best UI? The best UI is no UI. What I mean by that is, yes, there are tasks to be achieved. What is the best and most effective way to do that?

I mean, here’s a product many of us use: iPhone or Android phones. We went from having to unlock it, entering your code, to just looking at it and just opening [unintelligible 00:39:38]. That’s an example of no UI. Like, was this a task that was required for you to enter a passcode? If your ID is your face—and so I think as a great product manager, you got to go back to this idea.

Look, people don’t want to do the tasks. People want to do—they want to get the benefit of the solving problem they’re trying solve for. The fact that you’re making them go through these tasks, you really got to questions which are the ones that are absolutely necessary for them to go. You know, we talked about AI. It’s what I love as well because when do you know that you use AI?

And everybody says, oh, you know, AI stands for artificial intelligence, right? And actually, you know, my contention with that acronym is actually AI is should stand for applied and invisible. You know, you’re using AI when you actually don’t see it. That is the value of it, right? All these tasks that you’re trying to do that today take your process, what if I could take this process away, either go away because it’s automated, either go away because it’s not necessary?

Simple examples, you know, there’s a lot of things going on TV right now, the World Cup is going on. Even two years ago, for us to watch a game, you’d have to be in a living room, you’d have to turn on a TV. And now you witness so many people don’t even have a TV. They can just watch it from their phone while you know they’re doing a bunch of other things. I think that’s what I think about as a product manager is really [unintelligible 00:41:04], right?

What is the job that needs to be done? What is the list of friction points that your audience is experiencing? What is absolutely unacceptable? You’re designing for 10X, the experience got to be completely different. And how does your UI participate in the elimination of these tasks that are just tax?

That’s the best way I think, to think about product like Waze, for instance. You know, when I pull up my phone and I get in my car and it knows to my calendar that my next meeting is coming up, it just puts the address and tells me, “Here’s the route.” That’s awesome because that is the job I’m trying to get done. Other alternative in the old days, run to your computer, print out the map, look at the map, right? I don’t have to think about it.

I just pull out my phone, all of a sudden, “Oh, your next appointment is at this location. Here’s the most effective route.” That’s correct. That is the problem trying to solve get to my meeting on time, not what is—I don’t care to know what the effective route is. I just trust that we have the technology to get there. That’s I think the mindset here.

Brian: I think sometimes people feel like, oh, because their technical tools or this is—we aren’t really going to see it and all this kind of stuff, that there’s not a role for design. But design is also about subtraction, right? A good design is really about what can we take away from this experience as well, not about decorating, right? It’s about really thinking about that experience, which is, I have no goal to use a wayfinding app. My objective is not to use the wayfinding app. My objective is to get to point A to point B in the fastest amount of time with the least amount of traffic with the least amount of clicking and all that.

So anticipating, like, well, maybe you are going to the next meeting and I can tell that you’re not located in the same area, so therefore, I am going to prompt you to go to the next meeting automatically, even though the software we’re using right now—if I’m on mute, and I start talking, I’ll get a message it says, “By the way, you’re muted.” That’s not something you find out until you’ve talked to customers because it doesn’t seem like a logical requirement. Like, well, they hit mute, so nothing’s going to happen. No, they hit mute accidentally and forgot that the host—like Brian—was on mute. And he forgot.

So, sometimes those—that only comes though if you’ve actually talked to customers, and realize that they’ve forgotten to do this. Sometimes we have the stroke of genius and we think about that, we anticipate that kind of requirement. These kinds of hidden things is just as much they need to be intentionally designed. They don’t just fall out of the sky as freebies necessarily, right?

Bruno: It’s about those invisible features, right, that enable this incredible experience. That’s what you’re going after with the jobs-to-be-done theory is about that. I mean, I haven’t used a car key in four years. I just walk up to my car and it just knows it’s me and I open the door and I drive off. I park it, I close the door, it just locks.

Why do I need the key? Five years ago, I’d have to put in the key, or maybe I have to have the key with me. Those are I think the people are leading on UI is they’re thinking about the job to be done. What gets in the way? How do I make it easy or how do I make it disappear?

Brian: Do you find more your of customers are deploying intentional design into their teams that are building their data products? Or is that still pretty nascent? Are you seeing any trends there?

Bruno: Yeah, and again, I think we go back to that’s the job of the product manager. That’s why I was saying, you know, they are the CEO of the product manager, is you design with this experience in mind, which means you do start with the UI and the experience of the current solution. Because you’re trying to find the friction points and often the friction points is how people interact with your software either because it is purely interface—there’s a few routes you can take route one is the task actually needs to be done and how is it done today? Or there’s 15 steps to get it done? How do I get it down to three? You know, simplification of the UI is the way to do it.

The example I talked about the map here is a great one because they do need to be able to look at the map before the drive off and so forth. Well, in the past, they needed to enter the address they go to, look at a particular website and maybe print it and bring it into their car. It’s almost dangerous to have the [unintelligible 00:44:59] and how many of us did that, printed map and looking at the map, or if you don’t have a co-pilot—it’s all those things are bad. Alternative to this is you get in your car, pull up your phone, “Are you going to this location?” “Yes. What is the best route?” You’ve clicked on it twice. Now, essentially done a very efficient way of using technology. That’s one way.

The other way is the task actually doesn’t need to be done: partitioning, building indexes, and so forth. Why doesn’t the data environment understand that? It should, right? And so, can you build a system by which I just throw any data at this thing, I don’t have to think about is it structured, unstructured, does it need to be partitioned? Do I need to bring indexes? How many machines? Do I need to support that? G—why, as a data person, do you have to think about that?

Yes, it’s true. You used to. There’s a great poster from, you know, the demotivational company, I think it’s a company called Dispair, those posters that have great photos. And they take you, like values, like tradition, and they make fu—ambition—and they make fun of that?

Brian: The sarcasm, yeah.

Bruno: There’s one that’s about tradition. And I have in front of me here, and it says, “Tradition: just because you’ve done it that way doesn’t mean it’s not incredibly stupid.” Right?

Brian: [laugh].

Bruno: You know, the great thing about tradition, but as a product manager yourself, question yourself: is this the best way to get this job done? If the answer is no, then, you know, reinvent. If the answer is yes, then make it easier. And if I was a product manager, I would probably print that, put it in front of my desk, and that’s the value of 10X thinking is what’s amazing in this time of technology, anything’s possible. We really can solve any problem.

At the same time, we also have to think because anything’s possible, anything can be designed, anything can be built, and the last trap you don’t want to fall into is build something that nobody needs. And so, that’s the discipline of product management is understanding the difference between these two scenarios.

Brian: Bruno, it’s been great to talk to you. Do you have any just closing thoughts about data product management or data products you’d like to share, maybe some projections where you see things going? I’m particularly curious about whether or not this more digital-native approach to building data products is just going to kind of become normal at some point in the legacy enterprises, or whether that’s going to be one of many ways to do things.

Bruno: The main thought I would leave people with is this data product idea is a key for them to unlock the data-driven talk track that they’ve heard for many years. To some extent for many data leaders, it’s been impossible to get a handle on, like, am I data-driven or not? How do I assess that? The best way that I know how to help companies like that is to ask them, “What are you building that is effectively driving value to vectors, or it’s saving money and making money?” And so, I would, if I was a CIO or data leader today, I would take a look at that trend and look at my organization and how I’ve structured the organization works for you, but also the organization that you support.

A lot of questions we get is should I have everything decentralized? And I think organizations have moved to now this federated system where you have people in the central team, but you have people also in the various business units that you’re serving. And so, I’d say, as a CIO, Chief Data Officer, VP of analytics, look hard at data products. The good news is, it’s leaning on a practice that has been in existence for a very long time. This is not a buzzy, new marketing word; it is an effective way for you to drive your organization to the next phase.

And then the great news. I mean, when I started in data, very few people really were interested in databases, analytics, so all this stuff was back office. We now have the opportunity to be front office driving value for the operations. And so, it’s a great time to be in data. So, even if you’re starting in this profession, this is probably a profession that is going to grow the most.

You know, ten years from now, the Chief Data Officer is going to be as essential to the organization as the CFO is today. People will not ask me, “Why do I hire Chief Data Officer?” [unintelligible 00:49:09] like, ten years ago is was 12% organizations had CDOs. Now, it’s 60-plus. I don’t have to stat in front of me, but it’s an insane amount of people now have the CDO.

So, we’re moving to that culture of data first. It’s super encouraging. And then I would invite anyone to ping me on LinkedIn, connect with me, and you know, let me know what you’re seeing. And you know, we’re here to learn, so we want to hear from the community how we can make this space go to the next level.

Brian: Bruno, thanks for coming on. And where is it that they can meet you? You said LinkedIn is the best. Do you know your handle name just for people that are only listening and that may not read the transcript? What’s your handle on there?

Bruno: Brunoaziza. So, it’s LinkedIn forward slash in I think forward slash brunoaziza. So Bruno, like Bruno Mars, and Aziza, A-Z-I-Z-A. It reads forwards and backwards the same way, so it’s a pretty easy last name to remember. And you can Google me. I think there’s only—like my wife says, “Thank God there’s only one Bruno Aziza in the world.” So, you could just, you know, find me—

Brian: One’s enough?

Bruno: One’s e—

Brian: She thinks one’s enough?

Bruno: Yeah, exactly. [crosstalk 00:50:07]—

Brian: [laugh].

Bruno: —too many [laugh].

Brian: Awesome. Well, thank you so much for coming on Experiencing Data. It’s been great to chat with you.

Bruno: Thanks for having me.