Become a Creator today!Start creating today - Share your story with the world!
Start for free
00:00:00
00:00:01
Paolo Platter: From 10 Years of Data Consulting to Creating Witboost - A Platform that Scales Enterprise Data Products
59 Plays1 month ago
Paolo Platter, CTO and co-founder of Agile Lab and Witboost, joined Yuliia to share how his 10 years of building custom data solutions for clients led to creating Witboost - a platform that helps big companies manage their data products at scale. One of their customers used Witboost to build over 250 data products in just 18 months, showing how well the platform works at scale. Paolo explained why setting rules for data teams becomes harder as companies grow, and shared how he shifted from saying "yes" to every client request as a consultant to building a product that works for many companies.
Paolo Platter - https://www.linkedin.com/in/paoloplatter/
Recommended
Transcript
Introduction of Guests
00:00:02
Speaker
Hi all, it's Yulia from Street Data to Talk. And today I'm lucky to have Paul or Platter as my guest from Witzbud and Angelos. What else are you doing? Yeah. So Paul, thank you so much for joining. Please introduce yourself. Tell us how brilliant and talented you are.
AgileLab and Wheatboost Overview
00:00:30
Speaker
Hi, Yuda. I'm Paulo Plachter, CTO and co-founder of AgileLab. AgileLab has been a consulting company for the last 10 years, specialized in data management. And three years ago, we spin off a product company that is called Wheatboost. It is a data product management company.
00:00:57
Speaker
yeah
00:01:00
Speaker
And what did that tell us? What it does, because it's pretty unique. Yeah, it's a data product management platform ah to manage data products independently by the technology, by the specification, by the practice. So it's completely a gnostic regarding a lot of things, um but still helping you to set up your practice to manage data products at scale in large organizations.
00:01:33
Speaker
So, just folks, to be frank with you, I had i was lucky to see a short demo of Vidbus at Big Data London and Poland being really i modest here. This is basically the platform, very unique platform that enables users to do and manage data mesh. I would put it this way. Because i know i honestly, I ah saw nothing like this previously. And I guess it's also very difficult for you guys to explain that to end users what and how how can kind of it helps to manage data products because it's
00:02:22
Speaker
I should say it just sounds too simple to what it does. I mean, this is my personal opinion. How do you guys explain the value to end users?
Explaining Wheatboost's Value
00:02:33
Speaker
Yeah, this is interesting. You're right, because it's quite the difficult. ah The data product itself is already a quite abstract concept. sir that not An abused concept was put it this way, okay? Very abused.
00:02:49
Speaker
very abused and very understood but it's also very abstract and conceptual because you know it's a logical ensemble of different components, infrastructure, software.
00:03:04
Speaker
It's a very abstract topic and we built a platform that is abstracting away more and more ah concept. them So yeah, it's quite hard to explain ah to our prospect what it what is it and what it does. Typically, I start from the challenges. So I always start from the challenges that it solves.
00:03:29
Speaker
And they are ah quite common challenges in large organizations, like the governance that typically never works in large innovations, shadow lighting, practice adoption, like adopting the data mesh practice of the data product practice.
00:03:51
Speaker
So all these are challenges related the to people and processes, not related to technology. And this is where with Boost can can bring a ah the most of ah of its value. I always say technology itself is generating 20% of the impact in the data space ah and the remaining 80% is impacted by people and processes and how people are implementing, thinking and designing their data products, ah putting them in operations. so So we want to try to ah focus on those 80% that typically is not addressed in large organizations.
00:04:48
Speaker
I have so many questions, probably I cannot ask half of them publicly. ah ah but i First of all, this this podcast is not sponsored. It's my genuine interest um because, I mean, after I saw what you guys do and and also being event, I can imp appreciate ah the education part, how you work with the clients. I mean, it's a lot, right? To explain and even to find a fit, you know, with the clients. So what do you think is the most challenging for you guys? um Like, what are you, as a product, challenged the most? Because the use cases which you explain, I can say that every other big organization have them and they publicly cannot beat them.
00:05:45
Speaker
most in most cases, right? They have problems with governing data. They have problems with understanding which data products ah they are there, what works and what does not. um Every other organization is talking how hard it is to implement data mesh. So, I mean, the problems are clear. What are you finding the most difficult, how to get into the organizations and how to work with them?
Market Trust and Challenges
00:06:13
Speaker
I think we have two main, two main challenges. The first one is that is a pretty new product in the market. So obviously it requires time ah to get the trust the from the prospect and customer, ah even if we are, uh, uh, baked by, uh, uh,
00:06:37
Speaker
super large corporations, we are super solid in terms of economics and so on. so But from a product standpoint, the product is young. So ah it requires time to get also awareness in the market.
00:06:54
Speaker
And the second challenge I think is um the belief that people can build something similar to with Booster in ah in home, in house. So with a custom make CICD plus Terraform and a bunch of script ah here and there. um Not understanding ah that um Users right now in large organization are demanding for professional grade softwares to work with all the day. So they are really um used to have ah professional and top level tools to work with. And they will not start to use internal frameworks or command line tools. unless ah there is a very strong developer ah culture in the organization. But I'm talking about banks, insurance, these kinds of companies. So the
00:08:02
Speaker
that final result of something built in house is going to be slower ah in terms of time to market is going to cost a lot in terms of maintenance if you develop such amount of software internally then you you need to allocate the resources to to maintain it and also it will require a lot of effort in ah evolving and keep the pace of ah of the market so did This, at the moment, is the the major challenge that I face. and So, when when people ask, ah who are your competitors? And my competitor is a young development.
00:08:45
Speaker
and hows develop ah and then I think it's for every other solution. like Even for us, ah I ah see it all over the place. and that you you know What I saw from my from my experience, when I'm talking ah to data directors, I kind of put them mentally into buckets, those that understand this, that maintenance and and allocating their resources towards building monitorings in our case.
00:09:18
Speaker
um is not their strategic business. And those who understand to move faster, they need to upskill their current data teams to make them yeah sophisticated enough to be able to apply ML, AI, all of those sexy things towards the data they already have know as a flavor to be able to play with it, um but not build the monitorings. This is kind of the packet where I put as those data directors and then I mean like we can we can have a combat with them but eventually it comes from their strategic thinking and that is little you can do about it.
00:10:00
Speaker
I think it's just a matter of market maturity because also your mother is very young because in the 90s people were building a database in house. Now, I don't know, nobody is building that by themselves ah because there is a market super commoditized so there's no point to build an in house database.
00:10:25
Speaker
And I think the the more the market of observability that a product management will evolve and the more this kind of temptation will disappear because you cannot keep the pace of the market with an internal team.
00:10:44
Speaker
um and and It also very much depends on the maturity, not just the market, but also the organization.
Build vs Buy Decisions in Data Management
00:10:56
Speaker
Like, let's say, before any observability solution appeared, there it was Netflix, there was Spotify, you know, those giants over, and they don't need any observability solution because for them, data is their core asset. And they had also monitoring plate, like they have this robust framework, I believe.
00:11:20
Speaker
that, you know, from my standpoint, from the standpoint of data observability solutions, monitors, those kind of things. So i'm I tend to talk in a way that, folks, you're a level of maturity to where you cannot allocate your resources, not to your strategic business.
00:11:44
Speaker
If you guys are reached as Netflix or, you know, but if I wish I have been talking here, you you you have been, you should have, you know, you should go and build something internally. That is for sure. And I see that on that spectrum of maturity.
00:12:00
Speaker
And I think I believe it's the same for you, for Vidbus. But I mean, I was completely blown away because this is also a challenge. And you mentioned that you are kind of growing sustainably, but for you, it's even larger organization than for an average ah data enterprise, modern data tax solution. I mean, the organization who you sell to,
00:12:31
Speaker
need to be large, like really, really large. And you get an attraction there, which is so much impressive. And you kind of shared with me that you even cannot track how the solution is used. How do you guys, because it's um the backstory, because it's implemented on a client side, and a good team doesn't have any solution like but and post hoc or amplitude to track the events. So this is a backstory. So Paulo, tell me, how do you guys, from the product standpoint, assess what's been used? Like, how do you guys collect that feedback? Because it's also hard to collect it. Yeah.
00:13:19
Speaker
Yeah, exactly, because V2C is it's not a SaaS, so it is installed and and integrated within the weeemed infrastructure of the customer. ah It's very difficult to extract automatic information.
00:13:36
Speaker
even if we have the tracking of how people are using the functionalities and whatever. But anyway, it's requiring effort to extract those information and put them together and analyze them.
00:13:54
Speaker
So we rely a lot on old-fashioned data product management techniques. We do a lot of ah user and stakeholder interviews to collect ah feedbacks about ah feature usage, usability, and also to discover opportunities for us to increment the value.
00:14:21
Speaker
So understanding where the users are struggling and where they would like to use something else, but ah this is not available with Boost or whatever. So we run three, four ah customer and user interview per week at the moment. there So it's a continuous job that must be done in order to collect ah let such information. That's ah a word, Olmec.
00:14:51
Speaker
Yeah, definitely. But at the moment, ah there's no solution ah for this unless customer allow us to stream events ah outside. There is something that at the moment is not happening because security and IT constraints, um but need to we need to find a ah solution to this.
00:15:20
Speaker
We are also creating a customer advisory board now ah to have some moment ah with all the customers together to collect such feedbacks in a more ah ah informative way, ah not trying to spot a calendar slot, but having the time to sit down and understand, okay, what are your needs? What are your challenges that maybe we can solve?
00:15:50
Speaker
together. So that that's the way we are approaching. Also because we we we don't have thousands of customers, ah so it we are targeting ah enterprises. So anyway, it's a manageable number of customer ah where we can keep a very personal relationship well and understand ah in in depth what is happening, why is not working, why is google working and so on. so Listen, I know that you cannot name the companies, but we got the understanding that those are pretty big banks.
00:16:34
Speaker
I mean, as a product person and I get in a sense from you that you, you know, you're fascinated building the product, otherwise you wouldn't um kind of hope on the joyful ride.
00:16:47
Speaker
of getting customers feedbacks and all of that. vihi soallo all of that My question to you, can you please share the most fascinating use case and feedback from the customer? Like, okay, we were able to achieve this and this and this and this time period and that was, you know, kind of this kind of things. Please share that. I really would love to know that.
00:17:13
Speaker
Yeah, sure.
Customer Success Story
00:17:14
Speaker
I think my most advanced customer and probably the most famous also one achieved incredible results because and yeah we have been able to go in production with a full-fledged data mesh platform where you can really ah onboard users and build the real data products in just four months, something like that.
00:17:45
Speaker
So from when we installed with Boost on the customer and to when we went in production including a penetration test and all those stuff and bureaucracy that you need to do in a large enterprise. so And from that moment forward in one year ah and a half right now from when we went in production they built more than 250 real data products.
00:18:13
Speaker
oh um something built from scratch, not just putting some metadata on existing data set. So this has been an unbelievable adoption that honestly I didn't believe it was possible at the beginning. I'm so glad for you.
00:18:34
Speaker
No, it's a big achievement as, you know, not as an entrepreneur, but as a builder. I call myself a builder and I can kind of um understand what you feel like when it's working. You know, when you even deploy every time you have your fingers crossed, like, you know, it should work, but every time you cross your fingers, your fingers have to work. I know it's going to work, but everything's going to happen. I know, I know exactly the feeling.
00:19:02
Speaker
This is happened on every release upgrade we do now, also because there is such a huge adoption when you upgrade the platform and so on, you risk to generate an impact on a And on products that are already in production for clients, right?
00:19:26
Speaker
It's already since one year enough no and So every time ah we upgrade the release, we're impacting more than 300 users across the organization. ah So it must be done very, very carefully.
00:19:45
Speaker
Okay, okay, so now you get me to the question, can you please tell me the biggest fallback that you can share that happened? Yeah, because you know, it just sounds all too sweet and too good. But I know the reality, it could be harsh. um so Something you could share when you kind of a little bit drop the ball, let's put it this way.
00:20:10
Speaker
No, it happened that ah we created a breaking change in an API ah that we were not aware of because ah we were thinking it was not used. Instead, it was. And we said, okay, no, let's create a new change. And then when we release it, we say, oh, no.
00:20:41
Speaker
Not the working anymore. so But yeah, we we have a very good team. So we we yeah and we have been able to recover with a patch release. OK. OK. Not too bad. It just doesn't sound like a it was quite. When you don't have a full visibility on what is used and what is not, ah you can also have this kind of situation.
00:21:08
Speaker
I'd say, no, this is what I'm telling to every prospect on a customer. When you don't have his ability, you just don't know what is happening. Yeah, that's fun. Listen, so just to clarify, basically, as I mentioned before, and what you told me what is incredible for your customer, you kind of enable data mesh and and you were able to map what the user already had in their data warehouse,
00:21:36
Speaker
map existing data products and to enable them creating through with boot and new data products. And right now it's in a year, it's over 250 data products in production that are being used across the organization. So it is it correct to say that you basically give to your customers a data platform?
00:22:03
Speaker
yeah in noning it that does have but For me the data platform firm ah is that represented by an ensemble of tools like ah ah Snowflake, Databricks or whatever tool ah you want to use ah that in some ways touching the data.
00:22:24
Speaker
so with boost is orchestrating ah all these tools to create ah another layer is a control plane for a data product the ah so I would not define a data platform but a data product management platform that probably is the right ah the right term to identify to identify with. But if you if you think about the data platform as the entire ecosystem of your tools all together and so on, in that case, yes.
00:23:07
Speaker
Okay, so what is, okay, let's make it up. What is a data platform for you? yes It's data warehouse and how it's and connected interconnected with other solutions on top, let's say, Looker, some ETL protestants, data ingestion, all of the collection of those solutions without a UI on top of it, right? So data platform for you already those existing tools in modern data stuff.
00:23:40
Speaker
Yeah, existing tools and all those tools that are touching the data in some way, storing them, processing, ingesting, serving, harvesting. So every tool in... in the perimeter that is useful to manage the data itself. Instead, we boost manage the data product lifecycle that is not only the data itself. So we start from the Git repository, but even before from the data product prototype, when ah you create the business case for the data product, you try to assess the business value of the data product.
00:24:26
Speaker
and then you enter in the development, ah so Git repository and data contract definition, then you go into into the deployment, and at this stage you still don't have any kind of data in the data platform. okay and Once you deploy the data product, you start to interact ah with the data platform itself.
00:24:50
Speaker
but then you have a versioning a change management of data products. so All these um elements are ah happening outside of the data platform itself because they are not affecting the data, not ah relying on the data in order to happen.
00:25:07
Speaker
so It's it a quite broad scope, not strictly related to the data, but managing the the the lifecycle of the data product end-to-end ah like it is a it's some mix of portfolio management, DevOps tool, so everything is needed to manage consistently the data product lifecycle.
00:25:34
Speaker
Very interesting because in my understanding and data platform was something that allows to manage this lifecycle of the data and data products. In other words, would which she name the data platform for me was just a stack. Yeah.
00:25:53
Speaker
It's a data stack in there. If you have Snowflake, you have your ETLs running. um look Let's even consider if someone have Airflow in place or something else. Yeah, but that is, and even if it's working fine, and even if it has all the monitoring in place, and and it's still a well-orchestrated and well-fine-tuned collection of modern data stack for me. While when you have UI and when you have some way for non-technical users to interact with it,
00:26:35
Speaker
to manage the lifecycle of data products, I thought this is a data platform. like so i mean And and yeah I agree with you. It's very broad and very different definition from organization to data professional. like Everyone is going to have their piece of mind of it. But tell me what is the difference for you then from data platform team and just data it team. What is the difference in that sense?
00:27:06
Speaker
the data platform team and the data team. so yeah yeah The data platform team or the platform team in general um is the team taking care of crafting the end-to-end experience of a data team.
00:27:24
Speaker
and also ah is in charge of creating standards, architectural standards, governance standards, security standardss infrastructureal standards, standards. It's basically defining defining ah the rules of the game.
00:27:43
Speaker
The data team instead is the team developing the use case, the specific use case, ah I don't know, charner prediction or whatever it is, um and becoming owner of the final result of this implementation.
00:28:07
Speaker
And the the interaction between ah the data team and the platform team is because the data team, when developed the use case, need to be compliant with all the ah standards defined them by the platform team.
00:28:22
Speaker
And ah the the real shift ah is happening when ah those standards are are not just on paper anymore. ah Very often platform team is just defining guidelines, but guidelines in a large enterprise don't work simply like that. I've never seen a guideline working in large enterprise.
00:28:46
Speaker
There are also studies ah referring to the fact that guidelines are working when ah your teams are up to 20-30 people. So if you need to um if you need to provide a guideline to a group of 30 people, you can manage to have them respecting the guidelines.
00:29:09
Speaker
If the group is more than 30 people's, the guideline is not effective anymore. You need to set up guardrails because ah people will forget about guidelines. They will try or tempted to bypass those guidelines first because there are other pressure, other forces on the system. so ah What we do ah is try to establish guard race to have a better decoupling between the platform team and the data team. So coming back to your question, the the platform team ah should define the rule of the game, the overall game, and should codify these rules. And the data team ah need to implement the use case being in alignment ah with with those rules.
00:30:01
Speaker
The platform team is also responsible to create ah enough automation and um so service capabilities for the data team to reduce the cognitive load of each single single data team.
00:30:17
Speaker
And there is a ah huge trade-off that must be considered in this relationship between the platform team and the data team. Very often, the platform team try to create frameworks to constrain and and limit the flexibility and the autonomy of data teams. If they exceed in this behavior, the data team at certain point will push back.
00:30:45
Speaker
ah the platform itself because yeah ill die yes because ah maybe allowing to do the 80% of things in a very easy way, but the 20% is becoming impossible good ah because they the the platform because is constraining too much the user.
00:31:05
Speaker
So you need to find a better trade-off between ah governance and autonomy. People want to have autonomy, but on the other side, ah you want to have governance. So that's the Lihi trade-off that you need to establish between a platform team and data team. Very tricky. And like I was at the, um,
00:31:36
Speaker
one of the big delivery yeah brands were presenting, they their data team was presenting the data platform from they built. And so they built two versions of it. And the first version was very flexible and that allowed data like data users to create nearly all the possible data products, like but it requires the knowledge of code, Python, SQL, how to deal with air flow. As you can guess, there are guardrails that could be bypassed, but you need to have specific knowledge.
00:32:24
Speaker
So, but it wasn't working and what it had too much freedom. And then they, uh, you know, and they also had so many requests, like hundreds a day. It just wasn't working. And they rebuilt the data platform with a very strict card rails. And then it shipped. I started to to grow. So just to compare, like I do remember in one year,
00:32:53
Speaker
After shipping the first platform, they had about 100 data products. So in half a year after shipping the version two version too data platform, they had 700 plus products, data products, something like that. ah So yeah, there is a balance. I know what you're talking about. A hard trade-off you need to make sure.
00:33:19
Speaker
that the balance is in place with all the possibilities and card reels and it's hard to find it. Exactly, and Wheatboost is he's trying to find the right trade-off out of the box ah for ah for the customer so so that they don't have to discover by themselves with a try and error approach what is working at scale and what is not um because it is going to waste a lot of time and resources
00:33:52
Speaker
trying to do something. Let's see if it will be adopted or not, and then go back and restart from scratch. ah It's an incredible waste of time. No, no, no, it's just too much effort. This is cool. I honestly don't know, like this is so ambiguous, such an ambiguous concept and even adopting that in organization. How long is the onboarding time takes for you? It's like a few months.
00:34:22
Speaker
Just customer onboarding, you mean? Yeah, of course, customer onboarding, yeah. Yeah, typically, we do one-month onboarding with a training up front because the platform is ah heavily customizable. So you need to understand ah which are the hooks are that you can that you can customize and so on.
00:34:45
Speaker
And then ah very often we do some training on the job, so we try to create an MVP ah with be the customer, and we follow them ah during the the MVP, providing advice, providing support and tricks, whatever, and then there you go.
00:35:08
Speaker
Listen, I have a question.
AI Integration in Wheatboost
00:35:10
Speaker
ah Do your customers ask you about AI or something, how you can help them, you know, implement AI in their workflows? Like, do you think about implementing AI in Vidbus? Like, what how what is your joinery with AI in terms of large language models?
00:35:35
Speaker
And so on one side, we are integrating ah AI in the product um to facilitate some specific action. For example, the metadata creation or the definition of policies. ah And there are many aspects to where we are introducing ah AI to improve the user experience and reduce the cognitive load of of users.
00:36:03
Speaker
On the other side, the so on the customer side, um I think we can do a lot and on ah AI ah to help them to bring a ah AI use case in production.
00:36:19
Speaker
ah because this is exactly the same problem of ah um data products. ah So basically the decentralization of data products has come because and the IT was a bottleneck and business so want to develop their data use case by themselves with autonomy.
00:36:43
Speaker
ah But because we cannot fold on governance, so we need to find this trade-off to provide autonomy to the business, but on the other side, we need to have governance about what is built. On the AI, it's going to happen the same thing, because businesses want to develop their use case and plug AI in their business process, but From ah an IT governance standpoint, we cannot afford to have ah ah many different AI platforms in the organization, so many different frameworks to develop those use cases. And at the same time, you need to be compliant with the AI act, for example. So yeah you need to have a standard way of working also when you develop an AI use case.
00:37:37
Speaker
So, yeah, we are doing a pilot on this, so how we can automate the the the transition from the prototype into the industrialized ah and they industrialize it the um project ah applying the same ah ah concept. So applying standard, applying computational policies to verify if the project has been developed in the proper way. So everything ah we we apply in the data product space can be applied also in the AI project. They they are not a data product, they are a project, but
00:38:26
Speaker
basically policies that you guys help to enforce. Yeah, in fact, in Wheatboost we abstracted away also the data product concept. So we have our um an ontology where you can describe what um what system you want to create in your organization.
00:38:47
Speaker
And you can describe them fully, so you can describe if you want to create the data products, AI projects, BI projects, or data ingestion projects, lakehouse projects, no limitation.
00:39:03
Speaker
The um on ah common behavior that we apply is on one side do we provide self-service capabilities to facilitate the the creation of these ah systems, projects.
00:39:19
Speaker
And at the same time, ah we apply the computational governance, the computational policies in each specific sector ah in ah in a different way. So you can have different policies for an AI project and then other policies for ah the data products. And you will have them coexist in your organization. Not everything is a data product ah in ah in a large organization.
00:39:44
Speaker
So wheat was yeah we about data product management, but that does process the can be shaped the as you want. You can create whatever concept you want in your organization. um So this level of abstraction is allowing us to apply the same principles in different contexts.
00:40:08
Speaker
I've got a question for you. you know what ah um I do pay a lot of attention to people's semantics. And what I mentioned about you is you're kind of trying to avoid data mesh. You're more leading into data products. ah On that note, is it like,
00:40:32
Speaker
but I'm trying to understand the cause of it. Is it because, uh, data mesh is not viable for organizations of the scale you work with today? It's just too hard of a concept to implement it. So you're focusing more on data products or you just, um, not into it like.
00:41:02
Speaker
Yeah, I'm trying to understand because you're leaning into data products and everything is about that, which is which is great. I do understand it, but I want to know your perspective. I think that Data Mesh is a set of principles.
00:41:19
Speaker
The data product is the most tangible thing you can create, create you can extract. the ah All the rest are ah principles that to me are very good principles. So I'm in the data mesh story since 2019, so really deep, really deep on that.
00:41:44
Speaker
But ah if you obstruct a way, I think that the same principles can be applied also in other contexts, where maybe you don't have a data as a product, but you have other things. so everywhere you want to decentralize the ownership of something, it could be a machine machine learning model, it could be a dashboard, wherever you want to decentralize the ownership of something, you can apply the same framework that Zomak.
00:42:20
Speaker
ah created ah Because it's a set of principles that are just reinforcing each other and and working very, very, very well. ah I talk about data product mainly because at this stage of market awareness yeah is what people ah start to understand as a general ah as a general topic.
Supporting Data Mesh Adoption
00:42:45
Speaker
At the beginning of WordPress, we were not talking about data products because people were not understanding what they were. Now we can talk about data products because also Garmr jumped into this topic. ah The awareness in the market now is ah is very good. so We can talk about data product as what we are managing ah in Wheatboost without and
00:43:17
Speaker
without
00:43:20
Speaker
without coupling too much with data mesh. Okay, you can build also data product ah in ah in a way that is not compliant ah with data mesh. And for weight boost is It's totally fine. Also because ah reaching the data mesh
00:43:42
Speaker
The data mesh readiness and maturity. So when you embrace fully all the principle is a journey. Okay. I cannot wait. yeah So with Boost is enabling that journey where you can start from a very low maturity and move forward step by step towards the the the data mesh readiness. I don't want to b to sell with Boost only when a company is perfectly mesh ready.
00:44:15
Speaker
It does not make sense. so I want to be the enabler for the journey. and so This is where I position witness. We create data products. At the beginning, they can be very broken data products, but you start to reason in a certain way and move forward towards the evolution of data products when you will embrace all the principles.
00:44:45
Speaker
But if you don't have a steering point, like with Boost, and you start with broken data products, you will stay with broken data products forever, because every data product you build is just becoming a legacy that you need to rework later. If you don't have a steering point with governance, so that's the way we can move on.
00:45:08
Speaker
no This is interesting. Yeah. Yeah. I can understand that it's like keeping things in order from early beginning. Like you need to start doing that, especially across big organizations.
00:45:21
Speaker
um Yeah, it's kind of cool. Listen, Paula, this is, this is so exciting. And also the way you talk about the value and, and, and not the roadmap, but the vision of your product, you are talking not like a CTO, to be honest. You are.
00:45:47
Speaker
You come across more as a very product-oriented person. It's my general feedback on how that's set up in your organization, how you guys, like how the idea of it was appeared overall, like how did you launch the product itself?
00:46:05
Speaker
ah Basically, the the idea came up the ah from some experience so we we had in the data mesh journey with other organizations. In a jail lot, right?
00:46:23
Speaker
Yeah, in Agile Lab, in the consulting. So doing consulting and implementing a data mesh platform, um we understood which were the pain points and ah why it's not affordable to build Hinao's platform like that. So that's where we spotted that there was the need to to create an accelerator ah to do this journey. Okay.
00:46:52
Speaker
I don't know how you, I ah just want to give you feedback. This is beautiful. The accelerator of ah data mesh rendering. This is beautiful. I don't know if you use it in Harvard.
00:47:08
Speaker
And um then we did a market validation. So we built a prototype and we validated with more than 50 companies, ah leveraging a network of complete people and so on.
00:47:26
Speaker
and Once we validated the the the idea and also we got a couple of deals with the prototype, ah we started the we started the the real implementation. In that moment,
00:47:41
Speaker
I shifted that into product management. So and I'm still the CTO of the company, but on the consulting side, I'm doing basically nothing right now. ah On weak boost ah side, there's no need for a CTO because it's still a quite small organization. We are 25 people, so not so big.
00:48:10
Speaker
So I transitioned it in the product management. I started product management ah to be to be in the position to mix my competencies coming from the resulting and being able to manage the product lifecycle in proper way.
00:48:32
Speaker
Got a question to you on that side. So coming but coming from the consulting is actually contradicts the product management values a lot. Because as a product manager, you want to build a scalable solution that fits, you know, most of the use cases. When I'm consulting, you tend to say yes to every opportunity, as I understand. You kind of, you know, how do you, how that inner balance find you? Like coming back from 10 years of consultancy, jumping into the building and product without having product management experience. How do you kind of co-composite?
00:49:13
Speaker
That's a difficult transition, but i I fully understand what you say, but I have some customer that was knowing me before ah as a consultant and now as product, I say, why you are so inflexible now? And before you were always on.
00:49:30
Speaker
Oh, wait. That's interesting. It's not possible to manage a product ah with the consulting mindset. This is also why we split the company. So with Booth, it's a separate company with a dedicated team of people ah with a product mindset. You can you cannot bring a consultants in developing a product as well. It's not only the product management
00:50:01
Speaker
problem It's opposite things. It's just opposite. They have different attitude, different mindset. In the products so you need to aim ah for the perfection, you need to think about.
00:50:17
Speaker
but uming ah so much i said So it's completely different mindset. So that we we created a completely separate team ah with segregate the resources, ah effort, money, budget and so on.
00:50:34
Speaker
I hear you. That's interesting. The other part that I wanted to touch base is data products. As we get back from the conversation that you are in a business of enabling data products first, you're not necessarily in a business of enabling data mesh. Maybe in a few years, you're going to be enabling data mesh. But for now, as market matures,
00:51:04
Speaker
you guys help to enable data products, which is super smart. Ah, but do you feel the data products as a term being abused? And I'm going to tell you a story. ah So a big data one, then I was at the yeah one of the talks and then the guy from a very respected big friend was talking about data products.
00:51:32
Speaker
And he was showing the book of Marty Cargan. Do you know Marty Cargan? Yeah, of course, you should know by now. So this is the granddad of products as a product management, a classic product management from coming from Silicon Valley, right? So that guy from this organization, he represents a data wing, like he's been had a blade or whatever, like very, very high up in disguise. And he will turn one of the slides with the Marty Kagan book and saying that everyone in organization and data team needs to adopt product thinking. And I was so frustrated and blown away because
00:52:20
Speaker
And I even wrote the article about it, like it's impossible to demand from data team, you know, data engineers, data analysts, just think also not about technical aspects and everything, but also to think how it's going to be used to check how it's used, what is the feedbacks, like, you know,
00:52:41
Speaker
It's way too much, and but it's not even that it's too much a pressure on data the team, but also it sets back the innovation part of things for data teams in a way where they feel so much resources not to make it perfect for their business users when they kind of do laugh while organization invest so much money into cloud, into all of those modern data stack solution to make them deliver an experiment with data faster.
00:53:20
Speaker
So I see that pressure of data product in a way of reading books and getting the customer interviews and prototyping, you know, those crazy things from product management is too much pressure on data engineers. And I think it's a big mistake because data product management exists as a classic product management because organization bets high on a product. Like it's way more than organization bets on data in the end of the day. Yeah. So how do you feel about all of this fuss about data products and and pressure or product management thinking on data engineers? Like how how do you think about it?
00:54:11
Speaker
Yeah, you're definitely right. um I typically reason this way. So data as a product is the way of thinking in a product-oriented way related to the data.
00:54:27
Speaker
Instead, when we talk about data product, sir ah we we we refer to the physical artifact, and and I always say, okay, there is ah the data product in the context of data mesh that need to have ah certain characteristics, because if you embrace data mesh, you embrace the principles, so the data products need to be compliant with those principles.
00:54:57
Speaker
Otherwise, you can have data products in other contexts, then define the rules ah as you want and it's fine. Data as a product, instead as the product thinking related to the data,
00:55:11
Speaker
yeah Your analysis ah is right, but to me, you should not put that pressure on the data engineer. If you want to apply product management to the data, you need to have someone from the business ah taking ownership and apply that product thinking.
00:55:30
Speaker
And I can tell you that I see this product thinking really pumping right now. So at the beginning, of people were focused on how to implement, ah what technology do I need? that this he said all and also we are focusing on ah the business value and the ROI of data products. So so in um that part, before starting the the the implementation of ah of the data product, I call it data product market fit to i recall the
00:56:08
Speaker
the the terminology of product management. So that that's fair that phase where you build a prototype, you try to validate with the market to understand if there is interest from the market about, okay, but is there someone that will use this data product or not? ah What is the business value? What is the estimation cost? You need to create a business case related to the product. Then you can start to implement the data product and ah iterating the life cycle. But what you're seeing is a separate person who does all of that work.
00:56:43
Speaker
It's a separate ah person, not the data engineer itself, because the data engineer has no business knowledge, typically, and for the organization yeah doesn't know the organization who can be interested in this data for which use cases and so on. so um I think product management applied to the data is a good thing.
00:57:07
Speaker
but it must be implemented properly. Also, in the normal product management, who is developing the product is completely decoupled by the product manager. ah It means that and the product manager needs to influence ah the implementation of of the product ah but need to um understand ah how it fits with the with the market and all this stuff. and So I see this ah separation of concern also in in the data product. Then obviously separated means that there is a
00:57:48
Speaker
collaboration relation, strict one, because who who is implementing need to understand and the product direction, but the product du direction is defined by a separate person, not by the developer of the um the product itself. This is interesting because coming from the product management background,
00:58:17
Speaker
like managing products. um I think it's beautiful to be in an organization when developers think product. It's just beautiful. They question you, like, ah we jump together, how it's going to go. Like, we don't have product management, a dedicated product manager at Mass Hat.
00:58:43
Speaker
I kind of try to share the responsibility with my CTO, but I'm not satisfied. I'm not happy. No, I mean, like, I do that a lot today. But because also I have, you know, kind of an experience and also I'm directly talking to the clients and leads. So it's actually a good thing.
00:59:07
Speaker
that That's the already phase that then you need to transfer ah to to the developed team. Yeah. And I feel that that very much depends on the maturity of that development team.
00:59:25
Speaker
I do believe it's possible today to transfer product management ah to ah software developers. And the reason for that, that software development has already a big history. So many frameworks, so many solutions, like it's well like like the industry itself.
00:59:49
Speaker
and professionals in this industry are very skilled you know so they can have this additional responsibility. Well, when I talk about data engineering, and It still feels to me as a new emerging industry. was not stre boli says you know was not ah tender It was not it was not a lot of standards, et cetera. So everyone is doing their freestyle. So it getting mental, but like what you're trying to figure out their way. And they also in a very challenged position because they are serving organizations horizontally.
01:00:30
Speaker
It's hard to extract what is real, which one of the, of investment from data team, right? Cause they are serving to everyone and there is no direct, uh, return on investment. I mean, some organization do that and some not. So they're trying to figure out their way. They're trying to understand how to collaborate. They're trying to make things work, uh, and, and, and be all this stuff, you know,
01:00:58
Speaker
works mostly and showing on top of that. And also you need product thinking about the day that you deliver is today.
01:01:13
Speaker
But yeah, I'd love to live in a word world where they can take it as well. but and to be great That engineers need to specialize in some business domain if you if you want to apply the product thinking because otherwise it's like to develop a product sir with developers that are just asking, tell me what I need to do and I do. Okay. If the developers were not engaged in the product thinking, and obviously this is how you good are in
01:01:51
Speaker
board i yeah yeah like yeah and evolving also ah during the process. But if that the data engineer in a data product thinking setup, just sit down and say, give me the requirements, the mapping between source and destination and I implement, it's not going to work because
01:02:17
Speaker
I guess we're getting in the territory of accountability and and leadership and and you know yeah an ideal world. I just want to i want people to make everything beautiful and and and good from from the very beginning. and I mean, I bet you do. There's no way.
01:02:41
Speaker
Okay, Paola, I feel like you get tired talking one hour. How do you feel? Sorry, one hour? but That's good. Yeah, it's been one hour. It was a nice joke. I'm really a fan of what you guys do in and I'm I'm actually anticipating how you guys are going to grow and then enjoy watching your story from the sides. so yeah Thank you so much for stopping by. and um yeah Thank you for having me and let's see the next chapter of and um this story. Let's see. yeah Thank you.