Today I’m chatting with Dr. Sebastian Klapdor, Chief Data Officer for Vista. Sebastian has developed and grown a successful Data Product Management team at Vista, and it all began with selling his vision to the rest of the executive leadership. In this episode, Sebastian explains what that process was like and what he learned. Sebastian shares valuable insights on how he implemented a data product orientation at Vista, what makes a good data product manager, and why technology usage isn’t the only metric that matters when measuring success. He also shares what he would do differently if he had to do it all over again.

Highlights/ Skip to:

• How Sebastian defines a data product (01:48)
• Brian asks Sebastian about the change management process in leadership when implementing a data product approach (07:40)
• The three dimensions that Sebastian and his team measure to determine adoption success (10:22)
• Sebastian shares the financial results of Vista adopting a data product approach (12:56)
• The size and scale of the data team at Vista, and how their different roles ensure success (14:30)
• Sebastian explains how Vista created and grew a team of 35 data product managers (16:47)
• The skills Sebastian feels data product managers need to be successful at Vista (22:02)
• Sebastian describes what he would do differently if he had to implement a data product approach at a company again (29:46)

Quotes from Today’s Episode

• “You need to establish a culture, and that’s often the hardest part that takes the longest -  to treat data as an asset, and not to treat it as a byproduct, but to treat it as a product and treat it as a valuable thing.” – Sebastian Klapdor (07:56)
• “One source of data product managers is taking data professionals. So, you take data engineers, data scientists, or former analysts, and develop them into the role by coaching them [through] the product management skills from the software industry.” – Sebastian Klapdor (17:39)
• “We went out there and we were hiring people in the market who were experienced [Product Managers]. But we also see internal people, actually grooming and growing into all of these roles, both from these 80 folks who have been around before, but also from other areas of Vista.” – Sebastian Klapdor (20:28)
• “[Being a good Product Manager] comes back to the good old classics of collaborating, of being empathetic to where other people are at, their priorities, and understanding where [our] priorities fit into their bigger piece, and jointly aligning on what is valuable for Vista.” – Sebastian Klapdor (22:27)
• “I think there’s nothing more detrimental than saying, ‘Yeah, sure, we can deliver things, and with data, it can do everything.’ And then you disappoint people and you don’t stick to your promises. … If you don’t stick to your promise, it will hurt you.” – Sebastian Klapdor (23:04)
• “You don’t do the typical waterfall approach of solving business problems with data. You don’t do the approach that a data scientist tries to get some data, builds a model, and hands it over to data engineer who should productionize that. And then the data engineer gets back and says certain features can’t be productionized because it’s very complex to get the data on a daily basis, or in real time. By doing [this work] in a data product team, you can work actually in Agile and you’re super fast building what we call a minimum lovable product.” – Sebastian Klapdor (26:15)
• “That was the biggest learning … whom do we staff as data product managers? And what do we expect of a good data product manager? How does a career path look like? That took us a really long time to figure out.” – Sebastian Klapdor (30:18)
• “We have a big, big, big commitment that we want to start stuffing UX designers onto our [data] product teams.” - Sebastian Klapdor (21:12)

Links Referenced:

• Vista: https://vista.com 
• Vista Blog: https://vista.io/blog
• LinkedIn: https://www.linkedin.com/in/sebastianklapdor/
• Vista Blog: https://vista.io/blog

Transcript

Brian: Welcome back to Experiencing Data. This is Brian T. O’Neill. And today I have Dr. Sebastian Klapdor from Vista on the line. You’re the CDO, which means in this case, Chief Data Officer, not Chief Digital Officer, not Chief Design [laugh] Officer. Is that correct? Did I get it right?

Sebastian: Absolutely. Absolutely, Brian, I’m the Chief Data Officer at Vista and super excited about that.

Brian: Excellent. And just for listeners, this was formerly known as VistaPrint. I heard I’m not supposed to say that. Do not say that.

Sebastian: [laugh].

Brian: [laugh]. A little bird told me, “Don’t say that.”

Sebastian: It’s actually still okay to say it because VistaPrint still lives as a brand. It’s just part of the bigger Vista family. And obviously, I’ll talk more about that later, but print is only one thing we got to do in what small businesses need to market themselves. There are also other things like digital and design, and therefore the print is still absolutely existing.

Brian: Excellent, excellent. Well, so just so people have an—I think a lot of listeners probably are familiar with that brand, so we kind of know what we’re talking about here. So, I wanted to talk about this idea of data products with you, having a more product-oriented approach to how we build analytics. And machine learning-driven solutions are supposed to help the business move forward, whether it’s customers or internal stakeholders, whoever it is that we’re serving, right? What is your definition of what a data product is, just so we can first kind of have a common language to talk during the show?

Sebastian: Yeah. Hey, this is a great question also because there’s no industry definition, industry standard for that. So, we took a rather broad approach of defining data as a product. It can be actually a really complex product that has a complex UI, interactive, like a media mix model that can you can simulate something and say, “Hey, if I changed my media spend to go more on TV and less on paid search, what would that change to my ROI for my marketing spend?” That’s a data product.

So, that has basically UI, it has a [unintelligible 00:02:20] model inside, it has data pipes that always pull and refresh it, basically pulling new data from many different systems. So, that’s a data product. Another data product, and let me take the extreme other form of that is, for example, in API. Which, one of the data products for that example is a product recommendations model that we are using to personalize our customer experience. So, whenever customers are on our website in real-time, the front-end calls that API and that API returns back a product ID to show as the next best product for that customer with what is the most relevant product for that certain customer.

Both of them are data products. Are also other shapes and forms in between, for example, tables that sit in our cloud data warehouse and are actively maintained and managed as a product. That takes it back to what’s the key principles of a data product, right, because it can have so many shapes and forms. And one of the most important principle is that it is an artifact that is actively managed by a cross-functional team and has a data product manager, and it solves a certain business question based on data and/or analytics, including AI/ML. Not always necessary necessarily, but can. Most important thing, it is managed actively as a product.

Brian: Help me understand what the not-data product version is, just to help even clarify what that means when you say it’s actively managed for teams that maybe are doing what I would call more project orientation, which is, “Here’s an assignment. Build this thing I asked for no questions, just give me exactly the spec.” And then send it over in the next project. What’s that product-y way? Dig into that a little bit more about the act of management piece.

Sebastian: Typically with projects, what happens after the project is finished, these end products, these artifacts, they die, or they kind of experience a long and painful death because somebody [unintelligible 00:04:08] later, right, say, “Oh, my gosh, what this amazing report that somebody build? We want to run it again because now we, again, in our holiday planning period.” And then they find out oh, gosh, unfortunately, the analyst who was on that project, staffed on a project left the company seven months ago, so nobody understands how that thing calculates something and what’s the business logic in that thing? So, I think that already is, I think, helps a bit to understand it. So, everything that is not actively managed anymore where it stops, things also—I would describe it another good example for that will be where it is actually still active managed, but not with the product management mindset is just imagine your typical BI team that gets data from someone—often technology teams—dumped into a place and they need to make some sense of it, but they don’t really own the data, they don’t really own the output; they are more like the middleman handling the requests from analysts or from somebody else in the business and trying to make sense of the data and trying to chase back to the producers where this data comes from, what it means.

And again, this is also not a productized approach to data because it doesn’t have any vision, it doesn’t have a roadmap, it doesn’t have a kind of forward-looking planning on, “Hey, what business problem am I trying to solve with that? What is the features I need and what are the kind of skills and the superpowers that product needs to solve these business questions to create value?”

Brian: Was this something you evolved into slowly or you actively made a shift? Because this isn’t the quote, “Normal, default” operating way for teams that I’ve talked to. It’s a different way. I’m just curious, did you just ease into it? Did you actively go into it? Was it always the way you just did it and you didn’t know there was another way? Like, tell me a little bit about how you arrived at this having DP and having data product managers, having this approach to managing things as reusable assets.

Sebastian: So, when I joined at Vista in November 2019 and then we formed as of January 2022, two months later, the D&A team, the Data and Analytics Team, we completely flipped the switch to that new operating model with regards to data. So, at Vista, so there was no other way of operating data with me before at Vista, so it was a basically complete switch. Why did I do that? Because when I was working at McKinsey and advising global clients on data and analytic strategies and on driving value from data, that was the key pain point number one I was experiencing that clients could not get the value from data, they could not scale data.

And why is that? Because A, often the data was not connected. That they had brilliant people, but often what they were doing was not connected to what the business needs and what the business problem is actually to be solved. And that’s actually where product management from the software world comes in. Because it’s all about, right, finding out what are the customers problems, what are the customers pain points, right?

What are the customer—where’s the friction when the customer wants to interact with us, when a customer wants to do something with us as a business or with our products that we offer the customer, to take that friction systematically out, and then improve it from there on, make it better, make it better, make it better. And that’s what I did also a lot at McKinsey was typically software products. And I thought, “Hey, there must be a way how we can bring that to the data world to make all of that one-off work that I need a number or I need an answer, actually, and half of that answer sits into an email; the other half sits into a Tableau dashboard that is not updating anymore properly. And how do I make sense of that?” Build that repeatable, sustainable model to drive value out of data and scale data. So, that’s kind of the data product approach.

Brian: Were there are hurdles to getting that going either from selling your leadership or your counterparts or to the existing culture and team that was there? Talk to me about the process of making that change.

Sebastian: It’s a process on multiple facets, right? One is the mindset with regards to data. You need to establish a culture, and that’s often the hardest part that takes longest, to treat, actually, data as an asset, right, and not to treat it as a byproduct, but to treat it as a product and treat it as a valuable thing. I think in our part of Vista, we were pretty fast able to do that. Because typically, data practitioners know and understand the value of data.

But often for stakeholders, it’s a longer journey because they are actively working on the forefront, on the first line, kind of with customers building software, building tech, thinking about marketing campaigns. They don’t think about data, right? They think about business problems and they think about customer problems. And helping them to understand how valuable data and data products can be for them to solve their business on an ongoing basis is kind of a journey, right? It’s a typical data literacy into the data—we call it also data product adoption because we build a lot of these products, right, but building them alone is not enough; you need [laugh] to get somebody to use them.

If people don’t use them, there is no value from all of these data products. But again, in order to do that, people need to invest time, stakeholders need to learn, they need to be open, exploring new things, right? And they need to do trainings and understand the new infrastructure. We introduce new tools where you can actually do self-service data that were different from the previous tools. And all of that also created friction for our internal stakeholders. But the more and more we helped them to understand the value, the more and more we see adoption go up and we measure the adoption actually on a monthly basis and report it out by org and say how many of your team members in your org are actually using, actively, data products, are logging into them and using them.

We are super happy that we see that adoption curve go up, but it takes time. So, it is one of the hardest pieces. Other pieces are technology, you need to have a good scalable stack in place. And one of the hardest things actually finding data product managers and staffing them on the products.

Brian: I’m curious about the fact that you’re even measuring adoption is interesting. Do you kind of assume that well, there’ll kind of by default, tend to be a problem with adoption, so we need to measure it, right? It sounds like you’ve already decided that if you’re measuring that as a metric. So, is that mostly through mining usage analytics of the tools or are there other metrics that you look for from your “customers” or stakehold—I’m using customers in quotes here, just in case they’re internal business partners and things like that—but talk to me about the measurements that you use to know whether or not your work’s getting used or making a difference.

Sebastian: Yeah, we measured along actually three dimensions. Let me start with the usage. So, usage is clearly one where we want to understand, if we built self-service tools—and that’s for the category of self-service data products—we want to understand how many people in the relevant target audience or target populations for these data products are actually using them. Because there’s an hypothesis behind that, right, if people don’t use them, there’s little value to that, or there’s too much friction, or they’re hard to use. And that’s a typical mindset of what, typically, SaaS companies are doing. They have customer success teams, right?

And because they also what they see is, there’s a very strong correlation between usage of a SaaS solution of a tool and the license subscription renewal [crosstalk 00:11:05]—

Brian: [laugh].

Sebastian: Our terms, continuing to fund all of the work you’re doing, right? So, if people don’t use it, at some point in time, people ask, “Okay, why are we spending the money on that stuff?” So, that’s one angle. Then what we understand is—and by the way we do that also for API; for API’s, it’s also easy to measure. You can measure the API calls, for example—based products.

Then there is a user survey, which is even a bit more strategic, even a bit more qualitatively as to all parts of our organization. There’s a biannual survey where we understand we call it the “Voice of the Data User Survey,” where we can really send a survey to multiple hundreds of people and [unintelligible 00:11:41] said, “Hey, how is it using? Do you feel you have access to data, right?” And then they go more, “And how easy is it to get access to data?” And then we go product by product, different domains, we’re organized in different domains. In total, there are 100 different products. And then people can say which products are they using and then we collect even more detailed information qualitatively about these products.

And then there’s a third big dimension, which is about financial impact. And these are mostly for data products that have a direct impact on our finances. And that’s, for example, things like a pricing algorithm or that product recommendation API I talked about earlier where we can do simple A/B tests—or sometimes they are not that simple—for pricing. We for example, use time-split testing through, sort of a time-split variant of an A/B test, basically, to understand what’s the uplift if we use that model versus if we don’t use the model. And then we translate it to actual financial numbers and the measure [unintelligible 00:12:36] KPIs there.

It’s how much money we drove in the bank in terms of profit in a given year and how much incremental run rate impact have you unlocked. Because if you get a new feature, a new data product live, and we assume it will continue to run, right, we say this lift of one percentage point conversion rate will be there as long as we run that data product.

Brian: Are you able to share some of the financial impact that some of these solutions have had with us? Or even if its adoption number or just some sense, whether it’s relative and percentages, things like that. But could you share any of the—what are some of the results of using this thinking in this orientation?

Sebastian: The latest—so the financial numbers for last fiscal year, I can share, which runs until end of June. In that year, just in that year alone, we’ve unlocked around about $50 million incremental profit that is in the bank that was delivered in a bank from pricing, from personalization, but also from using natural language processing to understand our key interactions, customer key interactions and drive, on a customer level, interventions. If customers are unhappy, then we can directly for example, send them—proactively—customer call or an email to further inquire and help them. That’s right about $50 million and we unlocked $60 million incremental run rate that will reappear in the next year. That’s obviously, it dependent on baseline of the overall business, but.

And this was the second year of the Data and Analytics Team. In the first year, the money in the bank was a bit smaller because we’re still building stuff, but it was also a significant double-digit million number. So, by now, we are now two-and-a-half years into that D&A data analytics journey, that’s around about $100 million in the bank.

Brian: That’s revenue that you think you can attribute to the work of the data teams that—

Sebastian: It actually profit.

Brian: Through split testing or—okay, additional increase in profit, based on the solutions that you’re working on. Got it. How big is your team, like, ballpark? Just I’m curious what that translates to roughly in the number of headcount you have who reports into your CDO? Or do you not own the team?

Sebastian: Yes, I do own the team and it’s rather broad remit of a Chief Data Officer function, of a CDO function. It is around about 150 people who build data products that spans across domains. And we cover the entire value chain, so we build data products from marketing that helped, for example, to optimize our spends on performance media, our bids, and measure the [unintelligible 00:14:54], or media mix model which I talked about. And then there’s a pricing domain which is all about building products to optimize our prices, data-driven prices. And we also be just launched a machine learning-based pricing product called Price Guru that continuously optimizes our prices through reinforcement learning.

Then there is a manufacturing domain because we also do have pretty big manufacturing operations where we print, actually, products and manufacture products. 2000, 3000 people working in manufacturing, so when we do a data-driven forecast, for example, again, using machine learning. Then there is the customer care domain. We get 9 million customer interactions every year; 50 million customers we serve every year, and 9 million interactions with customers every year. And there are things like, again, staffing forecasts for the teams who handle these care centers, who are working with care centers, but also things like natural language processing to understand each individual customer interaction and infer what was the reason why they contacted us, and were they happy? What was the relevant products, why they were calling in? Or the relevant features on our website to take—for example, contact us because they had an issue checking out or things like that.

And we then directly route the insights to relevant teams in Vista who own the parts of the experience or the relevant products. And then the last domain is more an underlying domain that does lifetime value modeling, customer cohort analytics, prediction, they [offer 00:16:19] LTV values and things like that. That’s around about 150 people doing that. And part of the last domain was also reporting on transactions and then what financial trends reporting. Then what we also have is around about 40 to—around about 40 embedded analysts that sit within our country, category teams, marketing teams. They are part of these cross-functional teams. Also, and which is a little bit of a special thing, there’s paid and organic search and pricing, part of the CDO function.

Brian: Talk to me about some of the non-standard technical staff that you have. So, I’m sure you have analysts, I’m sure you have data scientists, probably data engineers, et cetera. Talk to me about, maybe, the more product-oriented roles: design, product management. Where are these people coming from? Are you grooming them internally? Are you hiring native skill set from outside? Because you have to have people to do this, right, to own the Price Guru product, or whatever it may be.

Sebastian: Yeah, totally. And that was one of the things that took us longest to figure out is where to get these data product managers from because that was not a role that existed three years ago, and still hardly a standard definition of what is a good data product manager out there. So, we really had to also experiment; we experiment a lot. Now, we have 35 data product managers in our team.

What we’ve seen this day come from three different sources. And it’s actually, all three of them work for us; it depends just on the type of product you want to build. One, say, source of data product manager is taking data professionals. So, you take data engineers, data scientists, or former analysts, and develop them into the role by coaching them the product management skills from the software industry, basically. That’s pretty good if you’re building a highly technical data product, something that is heavily relying on AI/ML, for example, that needs a lot of kind of technical understanding on how to make it scalable, how to make it high performing, it’s part of a transactional system, for example. So, that’s where these kinds of roles are really strong for these kinds of data products.

Then there are data product managers that come rather from experts in their respective domains. On media mix modeling, we have staffed somebody who had a marketing background. Or on certain pricing data product, on that Price Guru actually, we are staffing—although it’s a machine learning-based product—we are staffing somebody who has a deep pricing background, who knows, kind of, what’s the best practice out there in pricing in e-commerce. What are the best players adopting and, kind of, being super close to the actual business use case and to the industry latest and greatest, what’s happening in pricing.

There’s a third category of people where we are actually the domain expert. We have the technical peo—have the people from software obviously.

Brian: Got it. So, that’s two. And there’s a third one, right? What’s the third one?

Sebastian: Exactly. And one is staffing or taking experienced product managers who had built software products before. Obviously, there’s a big community out there that’s well-established by now in the industry, and they are really, really good if you have a product who needs a lot of stakeholder interaction, who needs a lot of visioning around their product and, kind of, best practices on how to build a kick-ass product vision based on a complex stakeholder landscape, and then needs constant love and care and handling stakeholders. That’s for example, one of our reporting data products where we not only want to report numbers, but we want to really make it insightful, so use also AI/ML to predict, “Hey, is that what you’re seeing here expected or out of range?” And kind of, we have a lot of different teams using these products, again, having here strong product manager great and stakeholder management and interactions and facilitating workshops, building product divisions, division types, that kind of stuff.

Brian: Are you primarily grooming that first cohort which was the machine learning and AI deep tech specialization? Is that something you groom for the non-technical skill sets internally, you train them and then do you go outside to pull the other two? Where are those other people coming from you have to go outside to hire?

Sebastian: That was a big thing for us anyways because when I started, the data team was only 80 people, something like that and now we’re over 300. So, in all three of these different streams, we went out there and we were hiring people on the market who were experienced. But we also see internal people, actually grooming and growing into all of these roles, both from these 80 folks who have been around before, but also from other areas of Vista. So, for example, we have a super great PM from the marketing, who was before marketing who is now leading API-based complex data product, who runs our search.

Brian: Do you have designers working, especially on these hairier solutions that require an outside software product manager because you’ve got multiple stakeholders, maybe you’re creating a net-new tool where there’s no existing concept or model by which to compare it against, it’s going to be a net-new way of doing things, where does user experience fit in with all these tools that you’re making?

Sebastian: Not yet, but there’s a big, big, big commitment that we want to start stuffing UX designers onto our product teams. Not on every one, but as you say on very hairy ones that’s complex, where kind of, you really need to understand what makes a very easy-to-use, slim, amazing product. I mean, that’s the vision for all of them, but for some, it’s harder to do that. We haven’t done that so far because the staff, we were overall short of UX designers, and we said, “Hey we”—and we hired massively into UX design over the last 18 months, but we kind of going to put them on our customer-facing products first because there we didn’t even have them in a sufficient number. We did have UX design but too very small numbers. So, we put them there first, and now as this first wave is basically onboarded staff, we want to do the same with our internal tools and data products.

Brian: What are some of the skills that Data PMs need to have that are not on the technical or the domain side? What are the challenges that they’re going to have, particularly if they’re serving internal customers? Or maybe they only API for the recommendations, but they don’t own the digital experience of the VistaPrint customer. Some other product manager owns that. How do I get my thing into production, right? How do I get it prioritized in the backlog?

Sebastian: Yeah. And it comes back to the good old classics of collaborating, of being empathetic to where other people are at, and what’s their priorities, and understanding where can my priorities fit in there, into their bigger piece, and jointly aligning on what is valuable for Vista. And convincing them, honestly also, based on facts and data that it’s super helpful to invest into a more data-driven search or into a kick-ass product recommendation engine. But it’s also on building trust and delivering what you promise, which is probably one of the biggest pieces that helps building that trust. I think there’s nothing more detrimental than saying, “Yeah, sure, we can deliver things, and with data, it can do everything,” right? And then you disappoint people and you don’t stick to your promises.

As in everything, right? As in everyday life, right? If you don’t stick to your promise, it will hurt you. I think there are also, being realistic about what a team can deliver, what the team can’t deliver in a given time period. Also ready for seeing certain bottlenecks and impediments a team might have and still kind of finding a path that you push the team and say, “Hey, this is what we really want to drive,” which is at the intersection of being stretched but also realistic and then getting people into the boat, exciting people.

I think also communicating and talking about the value and the impact of the product. And not selling it, but making sure that people understand it so that it creates a pull for the product and to pull for the team. I think that is one of the biggest traits of the successful data product managers.

Brian: Advising a colleague or a friend in a similar situation—different company—they’re interested in doing this work, maybe they’re not in the leadership position, yet; they’re not the chief data officer to go and implement this type of approach. My theory is, it’s really hard to do this kind of work if you don’t have executive management because it takes some long-term perspective. Not all the work is going to have an immediate impact when you think about, not only do we have to make it, now we have to maintain this thing too, which takes time, money, all this kind of stuff. Is it possible to have this product orientation with data science and analytics work if you don’t have that senior leadership? How would you get the gears turning in a different organization if it can’t start top-down with a culture change? Or does it have to?

Sebastian: It certainly starts way faster if you have to top-down push and the top-down mandate to do that. That was also one reason why I took that role because I am reporting to the CEO, and part of the Vista executive team, so data has a seat at the executive table, which helps tremendously accelerating. But hey, it still works, even if data doesn’t have a seat at the table, right? And the nice thing about it, about the data product approach is that you don’t need to transform an entire company from one day to the next. We did that because we went in very bold, and it paid off, that’s great.

But you can also start doing that with one team and trying that new way of working out with one. Take a confined scope, area of scope, take a confined business problem, staff a team, right? And it’s not—you don’t need to—it’s a team, it’s a two pizza rule, right, so the team can be—or should be maximum nine people, right? In reality, our average data products are more like on average, like, five people. So, take a data product manager, take an analyst, take a data engineer, maybe take a data scientist if it uses machine-learning models and then try to start tackling a business problem where you can foresee that this problem will obviously sustain and persist for a certain period of time, right? If it’s a one-off thing, we also don’t build a data product, therefore we have embedded analysts.

But if you think this is something that will come up on a repeated basis and there’s value of doing that, running that as a product, start with one team and see kind of how it’s going. It takes a long—actually, the opposite is the case because you have these different superpowers on a team. You don’t do the typical waterfall approach of solving business problems with data. You don’t do the approach that a data scientist tries to get some data, then the data scientist builds a model, then the data scientist hands it over to data engineer who should productionize that, then the data engineer again, needs to go back and says all certain features can’t be productionized because it’s very complex to get the data on a daily basis, or in real time or whatever, right? By doing that in a team, in a data product team, you can work actually in Agile and you’re super fast building a first, which we call minimum lovable product.

Often, it’s also called the minimum viable product, but if you say it’s lovable—because I’ve seen in my previous times at McKinsey, so many clients that we’re stuck with a gazillion of viable products, and I think it’s pretty bad if you have to deal and handle with viable products all the time; they are just viable, so therefore, we try to make them at least lovable. The goal is to do that within two, three months, first as a POC, and then if that POC is successful, we move building on MLP. And that, again takes two, three months, you should aim for that right? And then that already significantly demonstrates value and you can already apply an MLP to production system. Maybe not to a hundred percent of the traffic or maybe not to a hundred percent of the problems or scope, but it already solves one of the biggest pain points of your internal customers.

Brian: This wasn’t my creation, but I heard Minimum Valuable Product, which I always liked better because it implies there must be value. Viability just sounds a little loose, you know, like you said. But valuable implies that there’s actually an outcome that’s being achieved by—someone’s getting an outcome out of it. It’s not just about the thing, but it’s the value downstream from the thing that we made, that’s ultimately what people care about. Why are you trying to hire designers? Is this to help with improving the L, the lovable piece, to getting the experience to be, like, super great? Why is that an area of investment for you, going forward?

Sebastian: It brings us back to that initial topic of adoption. The easier products are use—and often these data products are, by definition, more complex than word processing tool, right, which you can learn on yourself. It’s super self-explanatory, right? That’s the ambition, but just exposing that data to users, right, and you look at a dashboard, it has different breakdowns of KPIs, for example, just imagine your conversion rate, it’s broken up by channels across different funnel stages of your website. That by definition is just to understand that business context on how you divide that very, seemingly, not complex matrix of one big conversion rate up into five different double-clicks along five different dimensions by device type, traffic type, and incoming channel types, and all of that stuff, that makes it very complex.

And then you exclude certain pieces of traffic here and there, so you need to not only understand the concept of how you decompose a certain metric, for example, you also need to understand how these individual metrics are defined, how much they move over time and what’s expected what’s not expected. So, there’s a lot of complexity behind that. Not always what we’ve seen in the last two or three years, that if analysts for example build dashboards, it’s by default, an easy-to-use and easy-to-understand dashboard because often that kind of empathizing with the users who don’t have that analytics background, who don’t know technically how that query, how that metric comes together, and what queries because the analysts know the queries behind that. By having a super easy-to-use user interface, “Hey, this is the Slack channel where you can actually reach the team if you have a question on that thing.” Even comes back to small simple standards like that, where I think designers can be super, super helpful.

Brian: Let’s say Vista shuts down and for whatever reason, it’s on to the next company. Are you going to play this playbook the same way again? Or what would you change if you were going to go run your product-oriented Data Science and Analytics organization at another company? What lessons learned? What would you do differently?

Sebastian: I’d say I’d keep 70, 80% constant. What I would probably change, and earlier invest is in the topic of data literacy, coaching, pushing the teams more—the data product teams—more to communicate early on with the stakeholders, be more stakeholders-centric, customer-centric. That was the biggest learning across the, kind of, whom do we staff as data product managers, right? And what do we expect of a good data product manager? How does a career path look like? That took us a really long time to figure out.

Now, we have a stable, good approach which was, in the end, not that complex because what we did is now, in the end, we landed on taking pretty standard software engineering career track for data product managers. So, we could have had that idea earlier, two years ago, yeah? But we were still thinking about, “We need to customize it massively to data, yes or no?” And yes, there are some customizations to that in there, but it’s more or less, even stronger following the industry best practice of product management. And I think we should have done that earlier on. And I think that would have led to even more customer friendly, more empathetic, more viable—more lovable in the end—product early on. And I’m glad to seeing picking that up over the last 12 months massively, but could we have accelerated that by six to 12 months? Certainly.

Brian: I agree. I tend to think a lot of it, if you just get the regular stuff in place, like the basic workouts, you don’t need special training, you don’t need special equipment, you just need to do the regular part. If you get that going, you’re 80% of the way there, probably. The rest of it’s more domain specialization, things like that. But I kind of agree with that.

Sebastian: That’s great.

Brian: Awesome. This has been a really great conversation. Sebastian, where can people follow you? Are you on LinkedIn, Twitter, where do you kind of hang out? And can people reach out if they want to?

Sebastian: Yeah, absolutely. So, feel free to connect me on LinkedIn, I’m quite active there. Also, we do have a blog, where we talk about the Vista data analytics journey on the website: vista.io/blog.

You can find that we have now run about 35 blog articles about data product management, about the different data products we were building, but also more technical aspects about it, Security for data products. So, feel free to check it out. Feel free to reach out and connect. I’ll be super happy to exchange with other data practitioners.

Brian: Cool. Yeah, vista.io you said is your URL, right? Yeah, I’ll put that in the show notes as well as your LinkedIn. So, thanks for coming on the show. It’s been great to chat.

Sebastian: Thank you so much, Brian. A pleasure to be here.