Why do we need or care about design in the work of data science? Jesús Templado, Managing Director at Bedrock, is here to tell us about how Bedrock executes their mantra, “data by design.”
Bedrock has found ways to bring to their clients a design-driven, human-centered approach by utilizing a “hybrid model” to synthesize technical possibilities with human needs. In this episode, we explore Bedrock’s vision for how to achieve this synthesis as part of the firm’s DNA, and how Bedrock adopted their vision to make data more approachable with the client being central to their design efforts. Jesús also discusses a time when he championed making “data by design” a successful strategy with a large chain of hotels, and he offers insight on how making clients feel validated and heard plays a part.
In our chat, we also covered:
- Understanding “data by design” and how Bedrock implements this design-driven approach. (00:43)
- Bedrock’s vision for how they support their clients and why design has always been part of their DNA. (08:53)
- Jesús shares a time when he successfully implemented a design process for a large chain of hotels, and some of the challenges that came with that approach. (14:47)
- The importance of making clients feel heard by dedicating time to research and UX and how the team navigates conversations about risk with customers. (24:12)
- More on the client experience and how Bedrock covers a large spectrum of areas to ensure that they deliver a product that makes sense for the customer. (33:01)
- Jesús’ opinion on why companies should consider change management when building products and systems - and a look at the Data Stand-Up podcast (35:42)
Quotes from Today’s Episode
“Many people in corporations don’t have the technical background to understand the possibilities when it comes to analyzing or using data. So, bringing a design-based framework, such as design thinking, is really important for all of the work that we do for our clients.” - Jesús Templado (2:33)
“We’ve mentioned “data by design” before as our mantra; we very much prefer building long-lasting relationships based on [understanding] our clients' business and their strategic goals. We then design and ideate an implementation roadmap with them and then based on that, we tackle different periods for building different models. But we build the models because we understand what’s going to bring us an outcome for the business—not because the business brings us in to deliver only a model for the sake of predicting what the weather is going to be in two weeks.”- Jesús Templado (14:07)
“I think as consultants and people in service, it’s always nice to make friends. And, I like when I can call a client a friend, but I feel like I’m really here to help them deliver a better future state [...] And the road may be bumpy, especially if design is a new thing. And it is often new; in the context of data science and analytics projects.”- Brian T. O’Neill (@rhythmspice) (26:49)
“When we do data science [...] that’s a means to an end. We do believe it’s important that the client understands the reasoning behind everything that we do and build, but at the end of the day, it’s about understanding that business problem, understanding the challenge that the company is facing, knowing what the expected outcome is, and knowing how you will deliver or predict that outcome to be used for something meaningful and relevant for the business.”- Jesús Templado (33:06)
“The appetite for innovation is high, but a lot of the companies that want to do it are more concerned about risk. Risk and innovation are at opposite ends of the spectrum. And so, if you want to be innovative, by definition—you’re signing up for failure on the way to success. [...] It’s about embracing an iterative process, it’s about getting feedback along the way, it’s about knowing that we don’t know everything, and we’re signing up for that ambiguity along the way to something better.”- Brian T. O’Neill (@rhythmspice) (38:20)
- Bedrock: https://bedrockdbd.com
- Data Stand-Up podcast: https://bedrockdbd.com/podcast/
- LinkedIn: https://www.linkedin.com/in/Jesústg/
Brian: Welcome back to Experiencing Data. This is Brian T. O’Neill. Today I have my friend Jesús Templado from Spain on the line. Jesús, how are you?
Jesús: I’m fine, Brian, thanks for having me.
Brian: Yeah, yeah. I’m always excited when I meet other data science and analytics consulting firms and companies that are embracing design as a core tenant of the work they do. So, you’re a director at Bedrock; you talk a lot about data by design. You’re a consulting firm in Europe. What is this about? What does that mean to a data science leader and analytics leader: why do I need or care about design in the work of data science?
Jesús: Okay. I’ll try to set some context on why we started using data by design, [unintelligible 00:01:15] to the Bedrock tagline, okay. When we started back in 2019, summer of 2019, I still now—we feel—that companies aren’t embracing design as the main framework when trying to build business solutions using data. We realized that it was hugely important to take into perspective all of the human aspects when designing data solutions, involving all the stakeholders during the whole ideation and prototyping process. We started using design thinking as our framework for designing data solutions for the business, and that’s why we gave so much importance to saying we are, or we use data by design. So, that’s why.
I think it also comes from this tradition of feeling that data science as a practice—AI or advanced analytics—are far from being understandable, in the sense that all of this practice has been received really close to IT, and all of this world. That sometimes is scary for many business stakeholders. There are many people in corporations that don’t have the technical background to understand what are the possibilities when it comes to analyzing or using data. So, the importance of bringing design-based framework, as design thinking, it’s really important for all of the work that we do for our clients. You know, every client is different, every industry is different, and that’s why it’s so important.
Brian: Do you find that this is something that is sought out? Like, your clients are looking for this and they want to have a design-driven approach, or the design approach is an answer to what their need is? And maybe they don’t know what that is, but you frame it as this is—you know, “We’re here to make sure we deliver a human-centered solution that will actually get used,” and you have to, kind of, take them through that process for them to learn it. Are they knowledgeable about this in advance or is this something that you have to introduce to them?
Jesús: I honestly don’t think so. My opinion is that you cannot need or you don’t think you need what you don’t know. Meaning you find value in the process of using our methodology, or a framework like design thinking, or service design, when you explain what’s for, that you will be involved for the whole process, explaining the needs of the business, the individual needs of the stakeholders, and the strategic goals of the company. And when you realize that you can align the technical possibilities that data science brings with the human needs, is when you realize that you need to come to combine both, and that you need that hybrid model to further down what you could only use in technology and data science.
Brian: Do you find that, when you’re delivering your service and you’re using this design-driven approach, how does that gel with the existing data science and analytics and engineering talent that they have in-house versus—it sounds like your clients are often on the business side not on the data side, but obviously we’re all working together, so I’m curious, how does that work and what’s challenging about doing that? Is it a difficult if you’re trying to go through a particular process to help your client, but they have an internal team that maybe isn’t used to doing things that way? Or is it the data team that brings you in? Talk a little bit about fitting it into the process.
Jesús: To be honest, it really depends on who is our main counterpart or supporter on the other side. Sometimes we start to liaise with someone who is leading data analytics team—head of data science or something like that—and maybe it comes more from the business side. When we are initially involved with a data team, they already have a roadmap, or a strategic or a specific tactical need that they want us to support. Maybe they lack the data engineering knowledge or expertise in something that is highly technical, and that we have experienced implementing for other clients in different industries. When we speak with someone from the business side, I think they really value that we go through that design process and that we bring the experience of applying our data science knowledge throughout and across different industries.
Because we can bring in knowledge on learnings from other industries, and you know that some of the industries that we work with may be more advanced in using their data. You know that the client from the construction industry will be for sure less mature in utilizing data or analyzing data than someone who’s in marketing or media. So, there are still learnings that can be applied and that’s something that the business values when we come in, we’re in the picture. It really depends on how the relationship starts, but we’ve worked with both, and we’re comfortable with both approaches.
Brian: I guess my question though is, are those teams always comfortable with those approaches? I’ve seen issues before where one party, one party may want to do things a certain way, the other party wants to do it their way, and the challenge is in bridging the gap there between the cultures, frankly, the way one party thinks that data product development should happen. Is that every challenge or do you find by the time you get in that they’re already completely aligned about working with you and going through your process and the way you want to do that?
Jesús: Maybe we’re lucky so far that we haven’t encountered that, but maybe it’s because of how we navigate those relationships. I think we’re quite flexible on how we deliver those solutions. We do our agile ourselves in the sense that—I mean, we are weird hybrid [unintelligible 00:07:26] say, in the good sense because we combine the professional service approach with the software development or product management approach that is needed in all data analytics, data-science-related projects. So, we have a vision for how we want to provide services and how we want to support our clients at a business level and at a technical level, but at the same time, we also apply that agile and lean development process ourselves. We do have weekly sprint meetings, we do have daily stand-ups, and all of that, and we are flexible because of these, and we adapt to the client’s environment and their way of managing products because we also follow agile and lean process ourselves.
So, I mean, we were in engagements where the client required us to be part of their own daily sessions, in their own daily meetings, and we were flexible with that. Of course, we have our own way of doing things, of course, we have our own design framework that we’ve tested and works well, but we do want to provide our clients with the possibility of leading those developments if they want to. And yes, there are clashes sometimes, but if we are part of the process and we are part of the whole development and design process, we can still make things work.
Brian: Was there a period when Bedrock was not using design as part of the DNA of how you deliver your services, and then something changed and you said, “You know what? This thinking approach and this approach for innovation should be core to what we do.” Did something change or has it been this way since it was started?
Jesús: No, it actually works this way since we started it, but I have to say that in some of the deliveries or projects, programs that we’ve launched since then and we delivered since then, we did encounter that at some stages, the client said, “Okay, we don’t need to go through this design process right now. We know in and out what we need. We only need you to deliver x, y, and zed at this [unintelligible 00:09:39] engineering, at this infrastructure, or at this model development level.” What happened after is what you could guess, is even though there are some clear requirements from the business, I think that the design process where you involve all the stakeholders trying to think ahead how the product is going to be used, it still applies. When we did that and we have the opportunity to follow that design process because the business was imposing x, y, and zed, we felt that the delivery wasn’t as successful as it could have been.
I mean, all went good and the [projects 00:10:18] were finished, but still, adoption was struggling to get going; we had to fine-tune some of the designs in terms of the analytical models, and this was part of not maybe pushing enough for following our way of doing things. But yeah.
Brian: Yeah, I mean, that can happen. I think the difference here is, you know, when, “Requirements,” quote, are sent down to a team, it suggests that in a premeditated way, somebody already knows exactly what the users need and what they are going to use, and what you’re doing is you’re passing along an implied solution to somebody and not a problem to be solved. What I like teams to do is to become the problem owners and the problem finders and a lot of the design process is about uncovering unarticulated problems, the actual needs that are there that probably aren’t written down in a nice, clear format. And the management’s job is to allow the team to become a problem-owning team, not a recipient of orders, or requirements, and things to execute upon. If you don’t own the problem, the chances of you putting out a great solution are a lot smaller, in my experience.
Is this something you work on with your clients about this kind of concept of problem ownership and problem finding? Is this part of your process? I’m sure you probably get requests for solutions that are articulated as needs. Like, “We need a machine learning thing that will do x.” The solution is already implied in the request, which may or may not be the most cost-effective—or effective—experience for the customer. Talk to me a little bit about this unpacking the actual problem and how you guys do that?
Jesús: Yeah, I completely agree with what you’re saying. It’s actually part of our DNA, and I think we’re a bit biased towards preferring being involved in this strategic need for solving business problems rather than being called for fixing some data engineering pipeline. Of course, we do deliver and work doing both, but based on what’s our preference, I mean, me, as someone leading a team of very bright people, I very much prefer that we can come up with our own solution to a problem and that we can design that with different stakeholders and their business domain knowledge, rather than just coming in fixing something and feeling like just an IT support team. No disrespect to that, if you know what I mean, but we very much prefer keeping the strategic view and the strategic approach in mind when facing a business problem. That’s how we prefer to do things.
And I think that the people that I work with, as data scientists, data engineers, they also prefer that. Every colleague that has been joining Bedrock since we started this—and we always done it throughout their interviews—is making sure that they wanted to be part of this process, that they want to be client-focused, that they want to be part of the service design and solution design process because that’s what makes great data professionals. Of course, I mean you’ll be faced with tech [feeds 00:13:52] that you need to solve using x, y, and zed, and there is no flexibility on how you deliver things but based on how Bedrock was built and the processes around our way of working, we’ve mentioned data by design before as our mantra; we very much prefer building long-lasting relationships, relationships based on, we understand our clients business, we understand their strategic goals, we design and ideate an implementation roadmap with them, and then based on that, we tackle different periods for building different models. But we do build the models because we understand what’s going to bring us an outcome for the business, not because the business brings us in to deliver only a model for the sake of predicting what’s going to be the weather, like, in two weeks, saying something.
Brian: Mm-hm. Can you maybe share a very concrete example of some work you’ve done with a client? I’m particularly interested in a place where you felt like the design process made a significant difference in the outcome that your client got. I’m also curious to hear about where maybe things didn’t go so well. A lot of data teams at enterprise businesses, design is not—is still a fairly foreign thing, whether it’s working with designers, or non-designers that use design thinking in their work. Do you have an example you can share about how that process and way of approaching innovation actually delivered an outsize result?
Jesús: Yep. I started with at the start went well, and then things turned out to not go so well. And then I’d mentioned something that was a huge success to wrap up with something that [unintelligible 00:15:39]. The first one was data, a strategic program for large chain of hotels in Europe. Not many people know that because of the emergence of IoT and other technologies, you can capture data in many different formats, in many different ways.
So, apart from bringing in data from the digital assets that a company like a chain of hotels may have, you know, through the booking system, transactions, and all of that, you can also gather data related to how people move, or how they consume, I don’t know, drinks, or things like that. I mean, the main goal, of course, in this [unintelligible 00:16:18] for the business is always either finding an efficiency or making money, in this case, was increasing the average spend per occupied room. I mean, there is a metric in this industry that relates to that, I think the acronym is [RevPAR 00:16:34]. And we started with pilot hotel, and everything went well.
We implemented sensors here and there on the physical hotel, we started tracking what was the behavior of the user in the digital world. We combined both, we found insights on how the user was behaving and how that was affecting the real world, sort of say, and we wanted to scale that; we wanted to apply that for the whole chain, which I think was forty-something. Something that we did well, at the start of the project was bringing in people from the hotel itself because we—I mean, from the first pilot hotel. That was really great because we needed [unintelligible 00:17:16] on how we could collect information that any other company would have reacted. But when we wanted to bring that to the overall business, we realized—or we didn’t realize that we needed to bring in someone from the traditional IT systems unit.
And it is really important, I mean, the learning here was that, I mean, of course when we brought that person in, and we brought that person to the conversation, that person was really surprised of what we built, but he still felt reluctant to be a part of the process because everything that was built so far, he wasn’t a part of it and we didn’t take him, his opinion into consideration. Many things could have been better for that pilot hotel, but the overall learning was that throughout that process, you really need to identify who is who, who brings which value to the conversation, even though you may have been invited to create or to deliver part of a program to do something, I think it’s really important to identify who’s going to have a say, or who is going to impact your product. And I think there was a huge learning for us that we apply to any other product, that not involving business units that were related to our mission, that was a failure and learning at the same time.
Brian: You know, what I talk to my students in the seminar, in the training, about human-centered design—and the reason I use that instead of user-centered design is I think a lot of the design thinking mentality in this approach can be applied to people who are not users of the system. So, we have stakeholders, we have users, and we also have people who are affected, third parties who are not part of the project at all that may be affected, in this case, it could be a guest staying at the hotel. And having all those perspectives in mind when you do the project and using the skills of design to understand needs, concerns, even the politics, just understanding all of that can be essential to delivering a great solution because one of those parties can either block it, either directly through action, or indirectly because we didn’t understand a need or requirement that may have been present because we didn’t properly involve them. So, I don’t know if you guys frame it that way, but I think about design at that level that’s not just about the customer or user of the solution, but also the people, the teams that are brought in. I don’t know, [laugh] did you guys think of it that way as well, or?
Jesús: Yeah, of course it works like that. In that case, we were bringing in people that… as—they weren’t fake guests; they were actual guests, and we utilize their thoughts and opinions throughout the design process as well, not only the people that were working at the hotel, or the people that were working at corporate level, sort of saying. We brought everyone in for that vision. But sometimes, and as you were saying, the opinion and the experience of other accounts a lot, especially when it comes to knowing the technical depth that you may be inheriting. And someone else—in our case, someone as important as someone leading the IT unit, now it feels like the day that you need applies to all of the business units and there isn’t a central unit for all, but in the past, there was this central IT unit that was supporting all of the lines of business.
And of course, they had a vision of everything that went well and all of the implementation that didn’t. So yes, bringing everyone in, and of course, the user who is going to use the solution is important. In our case, we’re building some models that were supposed to be used by the business in trying to predict demand and trained predict capacity planning. I mean, they’re [unintelligible 00:21:10] complex tools, but you need to know what the user is going to be expecting so that when you build something, it really gets used. And then those insights are actioned back by the business.
Brian: And this specific project—and I love that it sounds like you had guests involved in this, too, in this design process—design is a team sport. This is also something I talk to my clients a lot about, and when we facilitate design jams, we need to have the right people in the room. And part of this is about getting everybody aligned around the desired customer experience, or the desired user experience if we’re talking about an internal user of a solution, like a manager of this hotel who’s trying to predict how many rooms should I clean today and at what time so that I can fulfill whatever the capacity planning is. But I’m curious, it sounds like in this situation, IT wasn’t perhaps brought in early enough, or something like that.
Was the issue here that IT also didn’t want to believe the solution that you all felt was right, or that the users—that you had somehow validated with users that, “Hey, this is the thing we want to make. It’s an application that envelops these models. It’s expressed through this interface or this experience,” were they saying, “No, I don’t believe this. We don’t need this,” or, “That’s great. I believe what you want to make, that’s all fine, but I have these technical issues which are going to stop it,” or something like that? Because there’s a difference here, there’s a, “I don’t believe it,” is very different than, “That’s going to be really hard to build.” Where was the issue here?
Jesús: I think it was a combination of a lot of factors. In this case, we were brought in by the business and the business didn’t think that involving this person was right at the time. And we moved forward with our way of doing things; we even created what we then create, but we adjusted an app that users, as guests, could download to talk about the different touchpoints within the hotel. We found that checkout was one of the—of course; I mean, when you have to pay—was one of the friction touchpoints. I think it was a combination of factors that led to not early identifying that person and that team view was important.
He wasn’t asked to [unintelligible 00:23:33], it wasn’t them believing that data science or analytics could do great things. It was just, I don’t like to say a coincidence because when you are in business you need to be paying attention to a lot of things, and of course, you need to pay attention to this, but I think it was how we started to work with this company, that they thought that a data-related program could go above everything, if you know what I mean; that it was so powerful, that could change everything. And yes, it can, but with the appropriate involvement in terms of stakeholders’ views and everything.
Brian: Are there—a lot—one of the core ideas of design is this act of ethnography and research, and it’s about regular and routine exposure time to the people who we’re building things for. So, whether it’s that hotel manager, or whether it’s the guest staying at the hotel who’s going to be the user, we have to get this exposure time to understand their headspace, how they frame problems, the mental models that they have about how they see the world, and that brand or service or whatever the heck it is, this is really integral and I’m curious, A, do you agree with that? And B, do you ever find that your clients or teams don’t want to go through that process because they feel like we already know what our users want?
Jesús: Ah. We do believe in that. We actually have one person in-house that is an expert on that; she is an expert in that. She studied psychology and she has that, or she possess that experience around all of everything that we’ve been discussing so far. As she is the one leading that conversation and trying to make clients or leads embrace that the design process.
It all comes down to making the people feel that they are being heard, if that makes sense, because when you’re in a business conversation, and especially when working with large companies, yes of course the reason is strategical and there is executives knowing what the business needs, but at the end of the day, they are people, and they have their individual points of views, and they have their opinions of what went well inside of their house, I mean, inside their company. And if they feel that they are being heard and that you are capturing all of those feelings, needs, and expectations, and that you are adjusting your service delivery model, your project, your ideation process to them, and that what you’re going to deliver has taken all of that into account, I think that they realize, and they help you promoting that within their business. When you have done that, is when you really get traction within a client, within our organization. That’s what we do. We feel that—I mean, it is not just making friends within our clients’ business; it’s making sure that we provide a close service by listening to them. That’s—yeah. And we really believe in that.
Brian: No, I get that, and I think as consultants and people in service, our first delivery of service, it’s always nice to make friends, you know, I like when I can call a client a friend, but I feel like I’m here to help you deliver a better future state. I’m sure you guys are probably—that’s your number one concern. And the road may be bumpy to doing that, especially if design is a new thing. And it is new; in the context of data science and analytics projects, it can be a new thing. I guess I’m curious, though, when you come in and you have this—it sounds like you have a user experience or a researcher who specializes in doing customer engagements and customer research to understand problems, and needs, and attitudes, and this kind of thing; do you find that the clients sometimes don’t like—for example, this hotel, do you find out, they’re like, “No, no, no, no. We don’t need to do any of that. We already know everything about our guests and we don’t need to go talk to them.” Or, “No, we just need a capacity planning model. You don’t need to talk to the manager of the hotel. We just need the model; can you build us a model that will predict demand coming up?”
And my answer to that, and you tell me if yours is different is, “No I can’t,” and actually, “Yes, some firm—I don’t do implementation work, but yeah, you could just go out and build a capacity model. Do you actually want to control capacity and be able to plan for that? Because if you actually want the model to deliver a business outcome, you need to understand how the person who currently owns the problem of capacity planning, and demand generation, and making the adjustments to the hotel’s service delivery, we have to understand how they do that work today. How do they do that work today? And then we fit our predictive intelligence into the natural way that they want to do things. We need to understand their world, and if you spend all day at your desk, building models or data pipelines are whatever and you never go out and talk to someone on the business side who is in charge of making sure that the hotel’s capacity is where it needs to be at any given time, the chances of you delivering, whether it’s machine learning or traditional analytics or whatever, it’s much lower because you don’t understand that world.” So, how do you respond to your client? If they say, “Well, we don’t need that. Just give us the model,” do you push back on that? Do you talk about these risks to them? Do you—what’s that like? Or maybe I’m the only one that has that issue. I don’t know, but I—[laugh].
Jesús: No, you’re completely right, and I agree, but it does happen as you’re mentioning. I guess we do a little bit of pushback mentioning the risks, mentioning that yes, we are technically capable of delivering what you’re asking for, but that we prefer not to do it that way. She—I mean, her name is Elia—she’s an expert in UX but she’s an expert in making sure that all of those solutions go through the proper design process, the one that we’ve been discussing so far. And we need to explain what’s the pros and cons of doing things well and not doing them well. And I guess so far yes, we… we did encounter people saying we don’t need that, but at the end of the day, it’s about making sure that you explain why it’s important, making sure that you explain why doing things from the beginning in a right way will help product to be successful and our model to be used, or dashboard to be used.
Because we’re always talking about data analytics models for predictive models or something related to that, but sometimes when we deliver something as simple as a report or a dashboard that’s throwing out some insights, if some of the main users haven’t been involved at the beginning, maybe in the data-gathering stages, they may not believe what’s coming out of those dashboards. That’s a very simple scenario, but it similar to what you’re saying. If they say, “No, we know what our users need,” we try to steer away from that and we try to provide them with balance [unintelligible 00:30:57] saying, “Okay, this is what you get from doing things in the right way, and these are the risks that you’re exposing yourself to if we do this in a three months timeframe, and then at the end of those three months, you really cannot find the value for the business because it’s not going to be used, and people aren’t going to believe what our assessment is saying.”
Brian: Yeah, I’m with you there, and I this gets back—we talk about it on the show a lot, the difference between producing outputs and producing outcomes because everybody asks for outputs, but when we have our design thinking hat on, we need to be seeking out the outcomes, the feelings, the—I mean, hopefully, there’s measurable KPIs on some of these, but nobody really wants analytics, nobody really wants AI. They want analytics so that x happens so that I get y return, I get z better life, whatever that means. We have to look downstream from that, so if you’re in a team or you’re a leader and you’re demanding output, output, output, “Where’s the model? Where’s the model? Where’s the app? Where’s the dashboard?” Those are all assets, they’re all outputs, they’re artifacts, they are not the actual thing that—they are not the outcome.
So, if we cannot frame that and get centered around that, we stand a chance of putting out stuff that will not get used or as you said, it will not be trusted because the people involved didn’t know where it came from. “How did you get to this? This doesn’t make sense with my job that I’ve done for 15 years. I’ve never seen numbers like this before; I don’t believe it.” And if they don’t believe it’s done; you’re done.
All you’ve done is spent three months, six months, twelve months, spending time doing stuff, but not creating any change. And so to me, this is where the design thinking process can really help us really focus on that end-user, that last mile part where all the technical work we do matters, it comes together.
Jesús: Yep. We also like to say something along the lines of something that you’ve mentioned. When we do data science, data engineering, [as simple as 00:33:10] statistics, that’s a means to an end. I mean, we do believe it’s important if it comes to that, that the client understands the reasoning behind everything that we do and build, but at the end of the day, it’s about understanding that business problem, understanding the challenge that the company is facing, knowing what’s the expected outcome, and knowing how you will deliver or predict that outcome will be used for something meaningful and relevant for the business. Whether that’s AI, whether that’s simple algebra—sometimes it comes to that—there is in the… that much of, you know—I know that what I’m saying may go against this, but I don’t think so.
We do have a team for covering a broad spectrum of tasks, if that makes sense: from lead engineering, from infrastructure, from—to data science, we do the whole spectrum of things, but you know that many business stakeholders are worried about that what happens in the back end, but more about what comes out of that project and what can be used by the business. And it’s also about making the scientific process that goes beneath that understandable without saying that, [unintelligible 00:34:33] is an algorithm that allows users clustering. I mean, not only data scientists and our counterparts on the technical side are going to be worried about that, you know, about us having that credibility, but at the business level, at the users’ experience level—and that’s what you’re saying—it all comes down to delivering something that makes sense and that can be used by the business because it’s relevant.
Brian: I completely agree with you. We have to right-size and right-fit solutions, and for a very technical user, they may need to know about all those details about how it works, what’s going on under the cover, how did you get to this? Other types of business user, they may not care if they’re at the point where I believe it. I watched us go through it; I don’t understand exactly how it works, but I’m sold because I was part of the process and I understood along the way enough to see that you guys understand my pain as a chief marketing officer, or whatever my role is. I know you guys understand what I’m trying to do and the trust is there.
You’re the expert, so I’m with you on that. Just to wrap this up, last couple questions here. Is there—just to kind of sum up your client experiences, is there one change that you would like to see clients make? Because one of the things at least my clients like to know is they don’t get exposure to what’s happening everywhere else. What’s everyone else like me doing in their organization?
So, is there a general message you’d like to convey about design? Or maybe not necessarily, but design and data, perhaps? Just a learning, a point of education that needs to happen, a cultural change they need to make, anything like that you’d like to share?
Jesús: Yeah. I mean, I do appreciate that many companies do understand the change management on cultural shift that is required when you’re trying to empower data-related programs, but not many realize that not only design thinking, but [unintelligible 00:36:32] frameworks are important when you’re trying to build these products or systems within a company. Sometimes it’s a decision that is made by some senior executives about an old predictive model that’s supposed to be predicting something, but I don’t think that many stakeholders have that much of an opinion on that. And I don’t think that the business tries to embrace that the people within their teams know what that is design process about. I encounter many people, I encounter many clients that, when we propose doing a workshop for trying to frame what’s the problem how to solve something, they quickly mention brainstorming because that’s everything that they’ve heard so far.
So, I think it isn’t only important to do some reskilling and upskilling on what relates to data tech, but also on the design side of things. Just making sure that—I guess that for me, this is a little bit of common sense—involving everyone because everyone’s opinion is important, but when it comes to developing and implementing a business solutions, I guess it’s even more important because it’s going to be staying there for long. I don’t think there is this sort of empowerment within the organizations right now. So, this is my opinion, maybe? I don’t know if you agree.
Brian: Yeah, no, it’s whatever you think kind of question, so I appreciate you sharing that. And I’ve seen—I think one of the things that, if I were to answer that question, is that the appetite for innovation is high, but a lot of the companies that want to do it, they’re more concerned about risk, and risk and innovation are at opposite ends of the spectrum. And so if you want to be innovative you, by definition—you’re signing up for failure on the way to success. And this is something Seth Godin talks about, one of my heroes, but I love that framing because that’s really what it is. It’s about embracing an iterative process, it’s about getting feedback along the way, it’s about knowing that we don’t know everything, and we’re signing up for that ambiguity along the way to something better.
This is not part of the DNA of a lot of the places that I encounter. And it’s politics, it’s, “We’ve been here forever. We already know everyth—you know, we already think we know all this stuff about the data part. Why don’t they understand—[laugh]—why don’t our users understand this stuff because we see the world through this one lens?” So, I don’t know, those are some of the challenges I think about in that area that I’d like clients to work on.
But this is I want to hear more about you, and just to kind of wrap this up, one of the ways to hear about you and your work is your podcast. Tell me about the Data Stand-Up podcast, and where can my listeners find out about your show?
Jesús: Yes. I mean, of course. So, Data Stand-Up is about mixing that scientific, technical knowledge with the strategic needs that companies are having right now. I felt that there are many great podcasts out there that related to how to do the models in and out, how to develop those models in and out, many scientific podcasts were doing great, and there wasn’t anything that was combining both the scientific aspects of it with—the CEO or a new role like the CDO may need for the business, and we wanted to bring both worlds together. We started in Spain, having a significant success bring in many CDOs from large businesses.
We also started with the English series of podcasts earlier this year. We also brought amazing guests. I mean, we had you, we had Bill Schmarzo, we had Kirk Borne, we had Clara Thompson; I mean, many, many great, bright, interesting people that can really provide an overview of how and why data and data science and AI is important for the business, but trying to relate that with learnings and real-life learnings that the experimented themselves. So yeah, this is what Data Stand-Up is all about. We are presenting all of the platforms, and you can find using Bedrock Data Stand-Up.
‘Stand-Up’ is a reference to the Agile practice or daily meetings for making sure that the technical team is aligned. So, Bedrock Data Stand-Up in Spanish and English, and we’re in Spotify, Apple podcasts, and a lot of the major podcasting platforms, but if you want to see all of the episodes that are available, you can also find them in bedrockdbd—as Data by Design—bedrockdbd.com/podcast.
Brian: Awesome, great. And if someone wants to get in touch with you, LinkedIn, Twitter? Like, what’s the best way?
Jesús: I guess that to get in touch with me, the best way is LinkedIn. I’m very responsive to that. I mean, a lot of people tell me that I’m crazy to be responding to the messages that I get there. I’m not a celebrity or anything like that, but I do get a few. I guess it’s also because of the podcast but respond to everyone. It takes me a little bit of time, but I’m quite responsive there. So yeah, feel free to reach out to me through LinkedIn.
Brian: Great, well, I will definitely link those up. And by the way, thank you for coming on my show and being willing to do this in English. I’m always impressed when people can come on and speak in a second language to do this kind of thing. So, I love languages, and I want to do that at one point in one of my other languages, but not yet, so. [laugh].
Jesús: You should. I guess that, I mean, for us to be successful at Bedrock, we’ve been truly global from the beginning; our reach is completely global. And I mean, thanks for having me. I do appreciate your mission here, making sure that design is brought to the importance that it needs because as I said, we do talk about the scientific and the data science methods a lot; we talk about the business side of things a lot, but not that those many times about the design thinking services hanging on other frameworks that are to be followed for delivering products successfully.
Brian: Great, great. Well, I think that’s a great place to leave it, and again, Jesús, mucho gusto. Thank you so much for coming on the show, and hopefully, we’ll be able to stay in touch.
Jesús: Gracias, Brian. Thank you.
Brian: All right. Muchas gracias.
Jesús: Have a good one.