Angie: Hi, and welcome to the Data Diaries with Dexibit, I’m Angie, and today I’m sitting down with Veronika Gower, who is our Product Director and Veronika has got a really fascinating history, started off life as a child psychologist. Have I got this right?
Veronika: Yes. A behavior therapist.
Angie: My goodness. And then launched into the world of technology and software. And actually before Dexibit worked for a company called Vista with their business unit Movio who do analytics for movie theatres, and now is in the world of visitor attractions, which isn’t all that dissimilar really. Thank you for joining me and welcome.

So the work of product teams has come a long way in the past few years from sort of silo days where business analysts would write requirements away and hand them to a developer who then ships code eventually into test. Why is it so important that we don’t work like that in that fashion anymore, when we are in the business where technology is our product?
Veronika: I think it comes down to the fact that you have different people in different roles. So you’ve got product, you’ve got design, you’ve got engineering and all of these people are keys to you making a product and you need all three in the same room talking about the same problem, approaching it from different perspectives in order to come up with a really good solution that’s viable, feasible, and desirable. So me as a product person, I cannot sit there on my own and come up with a solution, come up with the idea, test the idea with a customer, and then just hand it off to engineering and then ask them to build it because I don’t really know the underlying structure of the code, how complex something is, but also I don’t have an engineering perspective that would guide me and challenge my thinking. And that engineering perspective from a different view… because I come from product and I’m conditioned to think in a certain way, reading the product books that I read. And that’s the whole beauty of having people from different departments, with different roles coming together and using their different perspectives to talk about a problem and idea together.
Angie: So, this is sort of the idea of product trio, is it?
Veronika: Correct. I’ve actually never worked in the way where you only had a product or business analyst defining requirements, and then just passing it off to engineering. I came through the new way of working, which is you have this holy trio, triangle. You have a designer, you have product and you have an engineering tech lead with you at all times. And that’s exactly what we do here at Dexibit. Just to give you an example, we had a customer request to add filters to our visualization so that customers will be able to save these filters of different things they want to do, so they wouldn’t have to add different attributes, they can just save it as a filter and then they just click on that filter and they add it again and they don’t have to keep selecting all the 10 different things they want. Very simple, and then I started chatting to engineering about this. I’m like, “Hey guys, we’re thinking of doing this” and straight away, they were like, “By the way that filters are very complex for our ticketing system because of X, Y, Z. And the underlying architecture that we have from a legacy system in relation to ticketing is complex and blah, blah, blah, blah, blah.” So this work that I thought would be, you know, so very simple for this one data source was very, very complex.
Angie: So you’re kind of solutioning on the fly as you’re understanding the discovery, at the same time.
Veronika: Yeah exactly. So the feasibility of your thinking of what you want to do, impacts what you will do and what you can do. Because you don’t want to be in a situation where design or products have spent months thinking about a problem, if it’s a really big problem, chatting to customers about it, and then only at the very end coming to engineering to understand that, “Oh, this is not even possible. This technology doesn’t even exist for us.” So that’s why you have engineering from the very beginning of problem design.
Angie: What were those things that you talked about? Feasible, desirable, viable?
Veronika: Yeah. So viable in terms of the business perspective, is this something that we want to be building? Is it aligned with our strategy? Where do we want to go as a company? Is it desirable by our customers? Will it add value for our customers? Is it solving some of their key problems that they have? And then always feasible. Is it technically possible for us to do this, given the technologies that we have, or the technologies that are available to us? So you’re constantly addressing these three things, desirability, feasibility, and viability.
Angie: Making decisions around an iterative movement through those things as well, rather than just one big lump sum sort of move as a product at the end?
Veronika: Yeah. It’s sort of trade offs and evaluations, depending on things. So you could have something that’s technically feasible, but very difficult, but it adds such great desirability and value to our customers that, you know, we still want to spend the time doing it. It’s still worth it to go down that route.
Angie: Like that automation for us.
Veronika: Exactly. Very big project, technically challenging. In terms of feasibility, but the value that it will add to our customers, but also the future of our product and where it could go is enormous. And so it’s definitely worth us investing in that.
Angie: So the three of you, product, design and engineering are kind of all making decisions individually together as a team at the same time, by understanding each other’s words and sort of moving through the problem space and solutioning.
Veronika: That’s right. Yeah. And I think to me, that’s the definition of collaboration. And so I would absolutely hate and caution, anyone else working in siloed on their own and not talking and getting those different perspectives.
Angie: Unfortunately, I do have memories of working in a waterfall basis that was what I used to do as a business analyst back 15 years ago. I worked for Hewlett Packard and that’s how IT was done back then. It was sort of before this emergence of, you know, product thinking and, and really sort of product practice. And we did do all of those things. We would spend three months writing requirements with a business without talking to anybody from a technical pathway only to get to the end and find out how hard and big and long these things were. And we would end up sort of with these huge phase approaches that would span multiple years and it would be forever before we shipped anything out. It was crazy.
Veronika: Oh no, that sounds like my personal hell to be honest.
Angie: It’s the way things are done back then, I suppose. So what does that sort of cross functional team look like here?Given the different skills that we need in Dexibit, particularly with data engineering and data science being involved in that picture as well, when we’re delivering?
Veronika: Because we are foremost data company not everybody will have data analysts, data science or data engineers. And depending on the team that we have, so generally you have, you know, backend engineer, frontend engineer, design product. But for us, depending on the team, for example, one of our teams is insights, which is tasked with looking after an area of the product or anything related to the product that delivers visualizations, deep insights, forecasting for our customers. Not so much the experience inside the product, such as you know, how you send an email, how you do reporting, that we have a separate team that looks after that…
Angie: Obsessing over the calendar….
Veronika: … Obsessing over the calendar functionality, the filter functionality. So we actually have data scientists who also feed into that depending on the project that we’re doing. So if we are looking at how to improve our forecast or what we want to do with our forecast, we absolutely have a data scientist who come in on that team and helps us work through the problems and solutions that are possible.
Angie: I think it’s one of the exciting things about here is that at Dexibit being a data product, there are these sort of unique things that come with that land that you do not run into in your general sort of software as a service kind of ecosystem, in other companies. There are very specific things that we encounter that there is not the way things are done already coming out of Silicon Valley or out of the SaaS or tech industry generally, where you can pick up and say, this is how that’s done. You kind of have to work it out as you go along in sort of incorporating data science into a cross functional team or data analysis into a cross functional team is kind of part and parcel of that piece, isn’t it?
Veronika: That’s right. It’s new territory. And you know, we run into issues in terms of how is the best way to structure that, to work with data science and which projects, you know, do we involve them? So it’s definitely an evolving space for us. It’s a learning for us, and there’s just no material out there. And I’ve talked to other data scientists in other companies as well. And they come up with the same problem to be like, there’s no blueprint. It’s a new area of having, you know, data science in product.
Angie: Inventing the way of working as we are.
Veronika: Yeah. Which is an exciting opportunity.
Angie: So that kind of brings us quite nicely into understanding how sort of the research horizons of data science, which when you’re thinking about not for academic pursuit, because we are a commercial company, but when you’re sort of thinking about sort of general research for innovation and progressing that bar forward, how that blends with the roadmap horizons that we think about in product management. How do you kind of make those two worlds sing together?
Veronika: It’s something that we are working on and trying to figure out a better way of working together. But what we want to try and what we’re implementing is, like a three phase approach. There are, if you think of data scientists, they have to do operational things. They have to upkeep our forecasting and the project. And then other project they’re working right now is update dating our machine learning pipelines, a big project.
Angie: This is the Data Bricks thing.
Veronika: Yeah. Data Bricks is so huge, but you know, all these things need to be done, operational things that data science are responsible for and need to do. Then you have data science contributing directly to product outcomes like short term or medium term where they’re working on customer problems. That are, short term horizons, I would say not green field thinking, not that deep research where you don’t know what’s possible, what’s not possible.
As a product company, if you want to focus on those green fields, you probably only wanna dedicate like 10% of your time in that space, because you do have to deliver results and value to the company and your customers. So for us, yeah, we have a roadmap of the things they should be working on in terms of product. I think being very close to product is really important. Right now, there’s nothing that they’re working on for us in terms of very short horizon, but they are working on a medium term horizon and that’s to have a unified industry insight for us. So for us, we have all these lovely customers around the world from different venues within their traction sector. And so we are able to get that data and if we can learn from that data of what how visitation impact like works for that specific, sector within our attraction industry. So if we can figure out how all these art galleries function from, you know, within New York or within certain area of America, and then they can benchmark themselves for a specific gallery. How amazing would that be? So then they can compare and say, “okay, well, everybody else is here. Their visitation is 20% around this time, but we’re actually below that mark, what does that mean for us? Why is everybody else 20% above us? What’s happening for them and what’s not happening for us.” And that actually was inspired from our customer feedback. So a lot of our customers want to benchmark and understand what is happening in the industry, around their space and globally too. That’s a very big problem for them, and they’re not able to solve it themselves because they don’t have access to their data, but we do. And so it’s a very exciting project for us.
Angie: So that unified model sort of both helps us increase the accuracy for individual venues and predict things that we wouldn’t otherwise be able to predict if they were new or novel for that venue. and delivers benchmarking value across the industry, like we’re seeing for Recovery Index.
Veronika: Yeah, exactly for Recovery Index, but you can then take it onto so many other levels, not just visitation, you can do anything.
Angie: And one of the interesting things I think about that, those data science horizons as well is that you’ve got also this sort of data, operations of data science, which from a product perspective in SaaS, you kind of don’t really have that anywhere else. Right? Like in SaaS, you build product, you ship it and then you support it, but you don’t sort of ‘operate’ it. And with machine learning, you, can’t kind of just build a machine learning model, set it free into the wild and never look at it again. Every week you need to continuously improve forecast accuracy and integrity and validity, particularly in a time like post COVID, where things are changing so much. And there might be like new features that pop up or things that change or need to adjust the scope of that data and constantly experiment with that. So that’s kind of a new horizon of more like… current and present, in addition to your medium and long, and sort of research horizons as well.
Veronika: That’s right. And that’s only relevant for a company that does use data and has data. So many other software products. I have to think about this. But it is an area that constantly has to be looked at and thought of for example, recently, we saw another forecast falling, not recently, but you know, a few months back. And then the data science team were like, what could we do to make it better? And they looked at different factors and, you know, they tried COVID as being one of the variables and that was actually a great variable to use. And now we’ve implemented that into our machine learning. COVID a factor that helps our models predict better. Again, if you’re not constantly looking and innovating, that specific area, then very quickly it can go down. It’s like a little baby that’s constantly growing and looking after.
Angie: And so what about the topology of product teams? So what goes into the decisions around how you sort of structure your product teams here?
Veronika: I think there’s many ways you could go in that area, theoretically. What we’ve done is we’ve just looked at our product areas. You know, given the size of where we are at right now, what’s happening with the product, and we’ll just cut it up into three teams in terms of product teams. So, as I mentioned before, I think so we have the Experience team that looks after the overall experience of our customers entering the product, doing certain functions, like sending emails, how they’re using the studio, like their overall experience, how can we make it easy for them? How can we make the product more intuitive for them? How can we save them time with our product? And then we have another team that’s Insights team, and that’s focused on answering their key questions that they have of the data. How can we make data inspired. How can we help them visualize their data in a way that makes them have insights and brings value to them? And then comes on the experience to be like both very easy and intuitive and everything else, and yeah answering those other questions. So, you know, to be for a marketing team, what metrics do you need to know? What metrics should you be tracking, or what should you be measuring in that space to be successful? So that’s the insights team. And then we have our team of Automation, and that looks after our ingestion pipelines and everything that happens within like a data product, you know, how data comes in, how it’s integrated, how it’s transformed. So that’s a huge, huge piece for us, a crucial piece.
Angie: So it’s sort of building a new data automation platform underneath all of the app that everybody sort of interacts with as users.
Veronika: Correct. That’s a project that that team is working on right now. You’re building an entire data processing system.
Angie: So you wrote an article recently on our blog about our ways of working in product at Dexibit and you made a mention in there of all of these sorts of things around not working in silos and having your product trio and your cross functional teams and blending the research horizons for data science and finding out the right topology and all these sorts of things. And you connected all of that, that ways of working in products to our team satisfaction. And you had some really interesting findings there. What was that all about? Where does that idea come from of, of that connection?
Veronika: So when I first joined Dexibit I noticed that there was some inefficiencies and a lot of chaos in this space. Obviously Dexibit didn’t have a product owner before I joined. So a lot of the teams were unsure of the overall roadmap or of why they were doing something. The work wasn’t broken down enough for projects. So then the teams could not give a realistic estimate to the business of how long something would take. So then if they would say, “oh, it’s a small project,” because it wasn’t broken down enough when you start digging, it turned out into very large projects, which then the business, you know, didn’t think it would be as large and then potentially wouldn’t have made that decision to work on that specific feature had the business really known how big it was versus what the value that it would deliver for us. And so then there’s frustrations between the business and the engineers and people feeling a bit stressed, like, “Oh goodness, I can’t deliver on this now.” And feeling under the pump, because they’ve said that they could do it. And so I think that’s kind of the key of coming in, putting all these processes in place, best practice, to just ensure that there is that clarity and that process. And it’s well managed and expectations are well managed and we de-risk projects so that we do know what we’re doing, why we’re doing it, how we going to do it? Again, bringing engineers. You know, and solution architect in earlier on to help us design that solution before going ahead and just building it.
Angie: And there’s been a huge uptick in our team satisfaction as a result.
Veronika: Yeah, so we do these surveys within the company. And so it was amazing to see people like, you know, saying, you know, how clear are you on the outcomes or just team sentiment? Like their happiness and yeah, it was just amazing to see.
Angie: You’ve implemented this sort of dual track, agile product development process, and that’s all connected to this idea of pulling in people earlier into planning and doing that discovery and delivery, often simultaneously. What’s the sort of TL;DR… Too long, didn’t read story on how that all works and mechanisms of that?
Veronika: So in practical terms, that means we are actually building features and we’re planning for features that we’re going to build next at the same time.
Angie: So you’re holding both in your hands.
Veronika: You’re holding both in your hands. And there’s just different stages at which you involve which engineers. So we have the trio that does all the initial planning. And then you have the rest of your team engineers who are building the product, the feature that they’ve already broken down, we’ve sized this all up. We have the solution design for it. That’s fine. That’s happening. And then when we are ready, when the trio is ready, we bring in the engineering team that will be working on the next feature and we ask them to take a look at it, to think, to elaborate it, to start breaking it down. So then they’re building something and breaking something down so that by the time they’ve finished one feature, we have the next one really broken down, greater understanding of it. And that way they see what’s coming up, they’re aware of the work. And then we as a business, understand the complexity of that work. So then we can provide better clarity to the rest of the stakeholders of what that entails what’s possible. Which really helps our roadmap and communication with customers.
Angie: One of the things I’ve noticed in the last year or two since you’ve been implementing all these changes and particularly under your leadership and Daniel’s has been this introduction of continuous discovery and a huge amount, more investment in the energy that we spend in discovery before we embark upon delivery. And I saw a really cute quote on that on Twitter or something over the weekend around the fact that as a company, you do that discovery, and you either do it consciously at the start before you start delivering, or you do it subconsciously during delivery, which costs you a huge amount more, or you do it after you ship a product and no, but you have to do it at some point, right? I think that that’s been one of the biggest changes that I’ve noticed is really the amount earlier that we are doing that discovery and really testing out our, our ideas before we start developing. And that has meant that everything we’ve shipped has been beautifully designed, beautifully validated and tested out and has great features that immediately has a lot of uptake for adoption and usage that we see immediately, as opposed to prior where we sort of, almost tested out quite a lot of ideas in live product which probably had a lot more investment in them. And then we ended up with kind of a scramble of things that we had to unpack afterwards, because there was a lot of unproven ideas in there.
Veronika: Yeah, that happens really often for a lot of companies that I have had that experience myself as well, if things are not planned out. And I think one of the core things that causes that is rushing or just not having somebody to manage expectations or these products or the sizing of them. You have to have that space. And as you’ve mentioned, Angie that practice to be like, “no, no, no, before we build a single line of code we are going to do the research upfront about it. We’re going to think about this problem. We’re going to understand this problem. And then if at the end of it, we decide we’re not gonna do it, then we’re not gonna do it.” But yeah, no single line of code should be written before we’ve had that discussion.
Angie: Yeah cause we’ve always like capacity is a great example of this. Capacity is something that we tackled pre COVID because we have customers that deal with capacity problems that are long standing, you know, that just have more visitors than they can fit in their venues. Then we encountered capacity again, through COVID, particularly at the height of the pandemic where everybody was capacity controlled by government decree. And then we’ve sort of got the life life after COVID capacity controls for people who are retaining that, or maybe have special interests for particular exhibitions or events or whatever it might be. So we’ve kind of had three bites at the apple of pulling off capacity. And if I look at the discovery experiences of all three, they are really different in terms of the work we’ve done and the product that is resulting, or the solution concept that results from that is far superior now to, you know, that first thing that we put out in the market, which to be honest, I don’t think anybody used versus now something that’s, you know, quite ingrained with the operations of many different attractions. But it is really cool to see, but an awful example, if you like, of, of things that we’ve had to throw out because of, we didn’t invest enough in, in our discovery
Veronika: And look, I don’t think you can always build products and always get it right?

Angie: Yeah. That’s so true.

Veronika: Yeah, absolutely. There’s no such thing as perfection. But what we aim to do, and especially a passion of mine is just to reduce the risk for the business. So then if I know we’re following the best processes that I’ve seen work, and many of my other teammates have seen work, you know, if we do our due diligence and we do the best that we can, then we just de-risk that issue and, you know, deliver real value for our customers. And if we don’t get it right, sometimes that’s okay. We can see where did it go wrong? Well, why is this not a value? That’s very powerful.
Angie: And what does that customer discovery look like? Particularly, I know again, if we come back to Dexibit being a data product, and Daniel talked a little bit about the sort of recent industry presentation that he did, where it’s really hard to test out for a data product, whether somebody is actually having that light bulb moment of going, “Hey, I understand that I took away insight. I’ve gained value. That’s gonna help me make a decision in a different way. That’s been informed by this.” How easy is it for them to get to that from a data product? How difficult is it for us to test that that’s happening with a user as opposed to your standard old SaaS product? That feels like it’s, it’s a real complex world in there.
Veronika: Yeah, absolutely. Especially when you take the fact that so even if they understood the insight and gained value from it, there’s no way that we can measure they acted on that insight because they’re acting and those operational strategic decision making happen outside of our product, you know, because of our data. Did they change how many people they scheduled on for the month of June? Yeah. We have no way of tracking that. So that makes it difficult. But we do have monthly business reviews with our customers. So through those conversations, our customer success is able to probe and ask and have those conversations to help us out in that space. And also in terms of just testing new ideas and prototypes, we ran into this problem. I didn’t realize how much, how difficult it is to test new concepts when it comes to data stories with customers. And so what we learned is that we have to have the right customer for that data story. So for example, we have data visualizations for revenue. If we have new insights about revenue, we wanna share with those customers and get their feedback. There is no point showing that to a person who’s not interested in revenue, doesn’t work with revenue. But we must get the person from the finance team to take a look at that insight and see if it is valuable for them. Did it give them something new to walk away with? Can they make a decision based on this information? So absolutely getting the right person to look at that data and also giving them time and space to look at it. It is something that doesn’t happen within a second. They do need time. And so we came out with the concept of the experiment module. We will input these new visualizations and insights and data stories. Let the right customer know, “Hey, this is available for you. Please take a look.” And then later we follow up with questions so that they could take a look at it on their own. Without us there because ultimately…
Angie: Pressure to understand something in the moment. Isn’t it? When everybody’s watching your reaction?
Veronika: Yeah, exactly. And plus I, I’m not going to be there holding their hand when they’re using the product. None of us are going to be there. So we want to design a product that can stand on its own so that we have the right experience, the right health documentation, the right visualizations. That customers can get the value themselves without us.
Angie: So it’s kind of a, a live data prototype. If you like to test out this feasible, viable, desirable type side of things, to make sure that we can, using their real data, show them something that’s an insight of value, as opposed to kind of the traditional way of testing discovery, where you show somebody a mock up. It’s very different, isn’t it?
Veronika: That’s right. Yes. So the key, I didn’t mention here that it has to be their live data too. The nuances of that customer’s business rules need to be taken into consideration to see what was happening with their live data when we input this in whether with other products that have worked on, or like, you know, you think about an email editor An email editor is the same for any customer makes no difference. What data you have, what data you don’t have. It’s a simple function, the same, everywhere. But when you’re talking about revenue, they have different business rules. They, you know, some want to see very granular business line like item line, you know, chips versus somebody who wants to see just cafe data. Two very different concepts.
Angie: Yeah. It’s one of those, again, those sort of unique circumstances of data products that there’s not the playbook for how to do this. So this is one of the things that you all have discovered is important.
Veronika: Right. And I’m just so fortunate we have Daniel who just guides that process and helps us.
Angie: And so take me through what’s next for the product culture here at Dexibit.
Veronika: I think we want to continue down the route of best practice and then bringing everybody onto that journey, especially as we have new staff members joining and growing not everybody comes from the same experience, knowledge, skill set in terms of how to build data products. So I think it’s important that, yeah, we align everybody and explain to everybody of why we’re doing something, how we’re doing it, how we’re building products at Dexibit, you know, what kind of practices we want to implement, why we have the dual track of delivery and discovery, why we have the product trio, why we talk to our customers, why we take a customer approach and we don’t just product designing something that they thought up without talking to a customer or an engineer just going away and doing something without talking to product or a customer.
Angie: So you’ve sort of got this people integration challenge when newbies join of first of all, inducting them into these practices of product and then sort of adding on the data products layer of our thesis, of how those practices apply in a, in a world of data products where these challenges like live data prototypes. And then you’ve gotta layer over the fact that we’re doing that in an enterprise market. So we do that in different ways when we’re working with our customers,
Veronika: Correct, yeah. It is quite different. Again, you know, if you’re working for a product that’s not enterprise or what, you know, $5 a month. Yeah. Very different. Processes that you would have and the scale at which you would sell, everything’s just different, the business model’s different, how you develop, how you can test, very different.
Angie: Well, I’m so excited about where things are at at the moment. The product, but also the product culture here has come so far in the last, you know, year alone. And you know, when I think about where it’s gonna be and another year from here, it’s very exciting to look into the future and see all these ideas of what a post modernization ,post modern, if I can use those words in an app podcast looks like for us.
Veronika: Absolutely. Absolutely. I just, yeah, I think we just have a great team. Everybody here is so engaged. So it makes my work really easy. And yeah, just everybody understands and is willing to listen, willing to change, you know, I just love that.
Angie: Very cool. Thank you for joining me for a cap of hot lemon on this cold winters morning.
Veronika: Thank you, Angie.