In this episode Irina and I are interviewing Vitaly – a delivery and design lead who works close to product enough to absorb many of the product management methodologies and approaches. We found it interesting to see delivery organizations adopt the product mindset – and we grilled Vitaly on it.
As always, if you have any questions or want to subscribe to our podcast – ask a question here
Episode transcript (courtesy of Otter.ai)
Vlad 0:00
Hello, everyone, this is Vlad and you’re about to listen to the third episode of the real world product management podcast. Unfortunately, as you’re about to hear, it was not recorded in the most ideal of the circumstances. So the quality somewhat suffers. We apologize for that and promise to the better next time.
Vlad 0:24
This is real world product management.
Vlad 0:33
Hello, everyone. This is third edition of real world product management podcast. We have Irina Irina. Hi.
Iryna M 0:40
Hi everyone.
Vlad 0:42
And our guest today is Vitali. Vitali, please introduce yourself.
Vitali 0:48
Hey guys, Hello, my name is Vitali. I am Associate Director of user experience design as you can. So briefly talking about myself over the last 15 years of experience As I gather a significant experience working with products and services, and I’m focused on the full user experience circle, starting from the early concepts to the final delivery. Today, we’re going to talk about a data driven approach and how we will implement it in our day to day work. Thank you, Vitaly, since you’ve already announced the topic, which is great. You said data driven approach to delivery right. So what is the problem? What is the problem? Why do we need yet another approach to delivery we’ve been delivering stuff we as you know, all the it in the world been delivering stuff pretty successfully for a number of years. what’s what’s up with the new data driven approach to it? That’s actually not very you and and the problem itself is not also very new. So basically, the problem that we faced with usually on any new project or product we have been requested to work with, or develop with is we are facing a lot with the pinyon Based thing So, many, many times we are facing the situation with somebody been told to deliver something to you not understand why you need to do this. Moreover, that sometimes you’re not agree and this is very often situation when people who are working a lot in the in the clients company so they are working for a long time, it’s hard for them to think out of the box. And they consider themselves as a subject matter expert with a huge amount of experience. And they think that they know the their users business users need is painful. And so basically everything about about the business. And here’s the service company, like where I work and please guide we have this number of ideas, this number of features, and please build it, build it for us. This is what we’re facing with like for every new project and what we wants to change here is that we started to ask him questions why So why we need to build this? And this? If we get the answer was the next question will be, Okay guys, we’ve built it. So how we will measure success? How it will identify that this feature, this specific feature that we built for you will work bulletproof for your customers life. That’s probably the answer. Okay. So if I understand you correctly, you’re trying to replace the opinion based solution was something that’s backed up by data?
Yeah, yeah.
Vlad 3:33
I have a question. As a person who came from a company, I myself came from company where product was built based on opinions and not data. I’m really curious to see how you guys solving the problem that I was faced back
Vitali 3:46
in the day.
Vlad 3:48
What do you do when there’s not enough data? And I imagine it’s not a new problem either. So what are you doing there’s not enough data to outweigh the opinion
Vitali 3:59
so First we try to get the data before build something. And in order to build something meaningful, something that will bring value, we need to understand what is the what is the problem. And basically, we need to come up with some problem statement or point of view. And to get to this problem statement, we need to put data in front and center to kind of data qualitative and quantitative data. So qualitative data, we are gathering by using the analytics. So we have digital analysts in our team for our health and loss. We give them this kind of data that will give you the understanding of how the current solution works in terms of analytics in terms of behavioral patterns. So basically, we get the answer what people do in your solution today, and quantitative data will give you the answer why? Why are they behaving like this? Sometimes? It’s very hard to answer this question. Using the quantitative data only after that we will give the 360 view on the problems that we have today. And we can compare it against the KPIs that we have in this particular business model of our client. And this is the foundation for any our hypothesis that we will work in the future. So then we build the hypothesis will probably eliminate the problems and improve the situation. So when we build the solution based on the hypothesis, we definitely will measure so we measure the success and we measure against KPIs KPIs is the core here and measuring the success will give you the understanding, if this feature is designed, worse or not, this is not like a shiny items or great look and feel. So this is not enough. Right What is enough is that you will get numbers numbers that this solution will work. Okay, that’s great. Thank you. Again, I’m just following up on certain things you said, you mentioned that you’re looking at behavioral patterns. And you’re looking at what people do. And to me, again, correct me if I’m wrong. To me that sounds like either applying user personas are your blind jobs to be done. Do you have any specific discerning ideas, but which one do you apply in which case or not really, we are shifting from personas, you know, to just to be down because we are working with a with huge companies, right? So they would have a lot of personas. And what we see in our wars of progress is our specific. This personas have so many overlapping, overlapping, let’s say jobs to be done, then the persona does not have a lot of sense to be considered. So what we can see there is more and shift or more is to just be done. format, which is very convenient for us to understand the users tasks and these users behavior. So it’s like working with the fungibility rights one of our clients, which is very huge company. One of the main tasks for their, for their customers is to find the right product in like very, very huge catalog like we’re having millions of products and fungibility is crucial there. And we cannot seek to any personas because they they need different products for different personas. But the they have become an issue on the ability. It’s like if I will give you an example so if we are waiting in the queue to buy a coffee, it doesn’t mean who am I it designer or a CEO of a rich company. We have the same jobs to be done – to buy a coffee. So that’s what we think is more efficient to work with than the persona.
Vlad 8:06
Yeah, I agree. And my experience was pretty much the same. We’ve used personas before. And that’s something that we realized that personas are not the way to go on this, but I just have to mention that if, if I’m co standing in line for coffee, I’m planning my day wrong.
Okay, no, that was that was. That was really good, insightful. Thank you. I wanted to bring up another. Another thing that you said.
Again, one of the things you mentioned before, you mentioned that analyzing why people behave like they behave, why people behave like this is a very complex and one of the biggest problems understanding why they do what they do. Can you from your point of view from your spirits, can you talk a bit more about how you guys tackle this problem? We Yes, we all agree is hard. Trust me, I’ve been there. I’ve been in your shoes as well. And I understand is hard. How do you guys tackle the problem? How do you What’s your approach? How do you even look at this? Like, where do we start?
Vitali 9:12
So basically, we talked to users. So you should consider user voice as one of the main source for your data. You can talk to users directly, you can talk to users read some variable themes from from the surveys from different surveys, if your client company has or you can, you can run this survey, or even what we what we also do, by the way, this is very interesting. Since the company that we we are working right now is it old white company, they are represented in many countries. It’s very, it’s very hard for us to go in every country and to get the voice of their users and to see the difference. What was the cultural differences probably or conscious Pacific Thanks. So what we did, by the way, is not only interviewing respondents and customers by ourselves, but we created and let’s call it the framework. So that including discussion guides and nology, to the people to clients, people who plan to plant employees, for representatives in these countries. And we gave them this framework in order to get the user voice. So they basically interviewed users using our discussion guides using all materials and send the raw materials to us. And then we were processing this materials and get the data from them. This is basically what we what we are working with this problem. Awesome. Thank you. Oh, by the way, this is from the list of questions that we have based on the webinar you did prior and which is what this discussion is based on. there any trends of using AI or ml for focus? Because we’re interviewing or in broad terms, are there any uses of AI and ml to process that broad data that you were receiving from your interviews? Yeah, we have this, you should see us. So they are in the very beginning. So actually, today, I had a call with our technical guys, how we can use it in our work. We offer some with some ideas, and we definitely will elaborate more on that, because there are a lot of perpetuities to work with it to use AI and machine learning work. But you know, I’m not technical guy to answer the question. Unfortunately, if you want me to connect with this guy.
Vlad 11:45
It’s more about it’s more about whether you have enough data or not. And then obviously, we’re not experts in everything. Obviously, we need to subject matter experts. It’s just the question of, are you guys getting enough data to even think about AI/ML. To give you an example, in one of my previous engagements, the team, the product management team, which the design was part of, was also tasked with doing the customers interviews. And some of our users asked if we can if we’re going to be using AI NML to analyze the data we’re getting. And we said, No, we can’t really use AI and ML to analyze the data, the data from the interviews we’re doing with you, as our users. However, since we’re are gathering data of your interactions with your customers, which is way more plentiful, where there’s a lot more data, and it’s voice data, so we can do voice to text and then process the decks for whatever sentiment analysis, natural language processing, all the all the cool buzzwords that we keep hearing over and over. We can do that to tell you more about your own customers. So whereas we can’t use it on you, guys We can use it for you that allow user but for our users, and that was an interesting pivot for them. And again, we’re not we’re not we don’t have to be experts in everything, but we need to know kind of what what’s in there, what’s not. Right. Thank you.
Vitali 13:14
Thank you.
Vlad 13:14
No, thank you. It’s It’s interesting. I was just wondering, just to wrap this one up, what amount of information were you guys processing? And how did you how did you even manage that? I mean, I just said it’s not a couple of questions. It should be pretty big number to give you a significant insight into what’s going on. Like, what how much data Did you guys have is it was that like, I’m just question has hundreds of surveys, thousands millions, what was just give us a ballpark?
Vitali 13:42
Yeah, it is thousands, if not millions, thousands, but we definitely use some internal tools to work with with the surveys. So we identify the most critical touch points. So basically, our most critical touch points are really identified. In the consultation, and what we try to do right now is to get let’s say from the from the surveys and surveys and surveys, by the way is also a touch to the specific dashboards and what we are trying to do is to get try to correlate this answers and still correlate this variability to the touch points that we have and basically focus on this first on the most critical first and then continue with it with others. I don’t know if I asked you a question but but this is what we are trying to do right now.
Vlad 14:37
Oh, yes, yes, you did.
Iryna M 14:39
So without your actually mention a couple of things you’re doing on one side he said that you are sharing these surveys and these will get in the real danger and and as inside you said that you’re doing the daily proposition Canvas, and it helps a lot. how those two things live together and what goes first. And it’s actually possible to feeling that way to position cameras when you’re remote and when we’re not talking to the end users, because most of the cases what most people are trying to do is actually to have a workshop, like face to face workshop to healing the cameras. So how did you overcome this challenge of being remote in your case?
Vitali 15:21
So, you know, unfortunately, we didn’t use the preposition carnivals in our work. So, for us, this activity was not very helpful. So it will give you some kind of understanding. But you know, we have a lot of other activities that we are using in our work. So they are very specific. We choose them based on the task that we are we’re going to solve but value proposition Canvas is too general and doesn’t didn’t help us a lot, unfortunately. So that’s why we we basically remove it From the list of activities that we usually do hold the client.
Vlad 16:05
Cool, that is interesting.
Iryna M 16:06
Okay, thank you
Vlad 16:07
though it was interesting, because, you know, in the classic product management, you do use those things. And so it was interesting to see a different experience. Thank you for sharing. I want to just go back a little in what you said because that we we had one of the questions from your webinar that also proposes and slightly different and I like different opinions. That’s why we have you guys on the podcast. The question says, I would actually argue the amount of research and time spent on research directly correlates to the level of uncertainty. In other words, way I read this, the more data you have and more time you spend on research, the more uncertain you are in layman’s terms. This means the more data you have, the less you know. Do you have any experience especially from latest products that you worked on, and latest engagements that would speak to that? To that the amount of sort of research and time spent on research really helped or did did it actually introduce some level of uncertainty.
Vitali 17:09
So, you know, we did different kinds of researches, and I more or less agree with this. So we spent almost the whole year on research. And I found myself thinking of it. Now, if we spent like, twice less time or even lay out a month on the research, it will be enough and we will get more or less the same amount of information to to build our hypothesis. I fully agree with this. We do not try to spend more than money on the discovery phase, even less, so we try to spend a lot more than two weeks. Of course, it depends on the problem. Of course, it depends on the problem that you are working with. But if we are talking about the I don’t know, like a feature in your application, not every feature, it’s not more just spent, like a month is of discovery, basically what we what I see from my experience you can do enough, not more.
Vlad 18:12
So let me throw a curveball here. You will you’re talking about is the law of diminishing returns, you figured something in three weeks. And in the next three weeks, you don’t really figure out anything new. So it doesn’t make sense to spend more time. That’s the Law of Diminishing Returns, so you’d not be getting anything. What this question asks really is, hey, we know a, b, and c today was started doing research now we’re not sure. Is it a A, B and C? Is it x, y, and z? Is it alpha, beta and gamma? You know, the more research we do, the more uncertain we are, the less we know. And that’s what yeah, it’s what the question asks. And it seems like you guys are tackling this by kind of doing this stuff and Okay, we know this Let’s stop here. And let’s build it. And that leads me into into the next question.
Vitali 19:07
Yeah, but you know, then it’s endless process, you know, you can do research forever. So you need to stop somewhere. And probably Yeah, you definitely will uncover some things that needs more investigation. Probably yes. But in this case, what we usually do is that Okay, guys, here we have a clarity here, we can proceed with some hypothesis. But here is more and more we need more investigation, and it will be like another talk. So we just need to split it into many different tasks. Otherwise, you will do research for for a year. I don’t know I must say.
Vlad 19:43
I actually agree with you. Thank you. But just just to follow up on this one, I agree with you. You need to break down the tasks to just get what do you stop breaking down? What level of product capabilities is that? The price or product level of the capabilities level at – I don’t know – a feature, epic, story, where do you guys place I research and which level of product detalization.
Vitali 20:12
Different level, it could be, it could be even the full task. It could be even an epic, or it could be an overall view on the applications. Basically what we did recently, we conducted thorough research for the entire application would require. And this this research was not the learning phase, but more like a measuring place. So this guy’s they delivered number of features, all of them were opinion based, because multiple stakeholders are involved, and everybody has an opinion about that. And what we did is that we evaluated this issues first. And then we believe that overall experience with application and with With this lines are the flavors. So what we find out is that first, this is work this features that can sense. So this is this was a long report. And another thing that probably guys, he needs more investigation on how we you will position your application. Because now what we understood during the research that for the customers, they did not understand why this application for there are so many features. So the official collateral is huge there. And they just not understand what this application for is the replacement for another platform for the website, or this application is augmenting this website. They just do not know.
Vlad 21:44
So the value proposition was not clear to them.
Vitali 21:47
Yeah, yeah. And this is a good example of probably to say that guys, look, here we go. This is our playback about these features, but what you need to investigate more deeply into the proposition, into the value proposition of your application about.
Vlad 22:05
Okay, thank you, then that makes perfect sense. Let’s move on. Because we keep going back to what would you said? Let’s keep moving forward. We’ve mostly talked about qualitative data, the qualitative data in terms of doing the product research and measuring products, success or product impact. What about quantitative? What can we talk a bit more? And he probably would make sense to spend a few minutes on talking about the specifics of this particular case that we’re talking about. What kind of product is that? Is that is that a web application? Is that a mobile application? So that we would understand what the quantitative data are we able to collect and what was collected in real life?
Vitali 22:51
It depends, you know, that every time we’re faced with the Winblad problem when we start working on the corner, Data data, we see the problem that the level of maturity in terms of regions and data in terms of toolset and all the things is not enough on client side. And first what we do is a kind of the firstly assessment assessment in this area and then we come up usually with with a number of improvements and only after that we start collecting data Otherwise, you will get the wrong data and based on the wrong data, you should be very careful here because based on the wrong data you will you can build the wrong hypothesis and this is not acceptable. So, firstly we do this. So, the next level next level is we work in on measurement plan. So, what is my what is a measurement plan? Is that how We measure success of growth product and that some specific feature related to so basically we are we are working with a KPIs that are level of levels of KPIs. Some of them are behavioral UX KPIs that are connected to the buttons to the call to action. So things like that. And other things are the lead in our business KPIs, we call them is the things that are related to the conversions. And then the next level. So the highest level is the main KPI. It’s different from from business models and business model, it could be revenue, it could be user base growth, it could be an NSS Why not? So what we do is that we try to connect all these KPIs and based on this, we create the measurement And every feature that we are working on and we are building, we connect to the measurement problem and the connect to the KPIs and look how effective and how efficient it is. I don’t know probably a little bit clumsy explanation without whiteboarding or having slides, but I hope you will get the idea.
Vlad 25:28
We get it. We get it, thank you and just to clarify, your hierarchy of KPIs is the on top of the most important ones are your financial or your your overall growth KPIs. Then you’ll have business KPIs, like conversion rates, probably daily average users, those kinds of things. And then you have behavioral level KPIs on the bottom, which are tied into individual control elements like Marco Island, then you know, Soho When people click this button or said button, and so on,
Vitali 26:02
okay, yeah, well, yeah, that makes sense.
Vlad 26:04
Yep. Thank you that that that is interesting. Thank you. Thank you for elaborating on this. So are you using KPIs for any kind of decision making, for prioritization, or using for anything else? or using KPIs for everything? This is a data driven approach to delivery what what what is the role of KPIs in all the other methodologies or all the other ways to prioritize and figure out what is it that we’re building?
Vitali 26:36
Yeah, so long story short, yes, KPIs are our priorities. So KPIs are connected to the business model and the clients are our business right. So they want their backlog they want their roadmap to be related to the business they are doing. What we are doing is that we are trying to bring value to the business with every feature that we are working on. And based on this, we are creating our roadmaps.
Vlad 27:12
So your your roadmaps are solely based on KPIs.
Vitali 27:15
Yeah. So they should be related to the KPIs.
Vlad 27:19
Okay. Okay.
Iryna M 27:21
So my question to you is about how would you align your KPIs. The vision and the strategy are that most probably was sat before you start your search, and then fees and gains and needs that you found that were identified during services during the research. So how, how can you align those three strings and how do they work together in order to build one roadmap? So we have KPIs, we have vision and strategy for a management team, and we have your search results right. So what goes first? What takes the priority?
Vitali 28:00
Okay, so I think it’s really, the answer is very easy. So the product vision, and KPIs should be not contradiction with each other, they serve the same, sort of the same goal, right. So if you have the product vision, then you definitely should have a business model. And the business models should definitely have KPIs to measure if this business successful or not. This is the first thing. And if you really are talking about the user needs, about the pain point the user have, what drives business is these user satisfaction. So if users are loyal to you, if they rotation tradition is very high, that drive the daily active users and more productive users TPS, for example, your user satisfaction is good is high, then it should judge your main KPIs like raving you or user base gross. So all Things are very, very connected and they are serving the same thing.
Iryna M 29:06
Okay, and who joins KPIs wholesale whole brings down the vision, each of the KPIs is if you and your team in thinking on on the client side. So how those are being created.
Vitali 29:19
We do this collaboratively with a client. We can probably come up with some ideas, then we discuss it together. And the final decision is collaborative decision.
Iryna M 29:31
I see, thank you. Thank you.
Vlad 29:32
So this is great. Yes, I had similar question in the list of questions that we got from your webinars. So thank you for answering those as well. I have another one that is sort of applied to most of the body of knowledge you’ve shared with us. So let’s step back a little from details and look at this a little bit holistically. One of the questions Here we have asked, was it challenging to explain to the customer The reason for time consuming research before actual build phase? And if I can expand on that, the real question here is how you justify research to the customers. Given that this this is effectively a consulting assignment. Most of these are, how do you explain to them that you need to do research and spend time money and resources on something that will effectively never be built? versus, Hey, I know what we need to do just go and build it. Like, what is the rationale? What is the approach? What is the take? And is there any data driven, material data driven? I don’t know decisions or data driven approach that can help you justify doing the research and finding more data versus Hey, you already have some kind of a data go and build stuff.
Vitali 30:57
This is this is an excellent question. By the way. What I can say that there is no like silver bullet of how to solve this problem depends on the culture of the company. So some of them are not ready to change, they have a fear of fail and fail is considered something that is very negative. A fear… how to say it…
Vlad 31:23
I see I see what you mean, it’s the fear of failure, not not as much as the actual failure, but the optics of it. How do you go there and tell them, oh, hey, we did the research. We had three hypotheses and all three failed, even though that is expected result, you didn’t expect to succeed all the time. Your upper management say like, why did they experiment? It’s they’re always failing.
Vitali 31:29
Go and do this, instead of experimenting.
Vlad 31:50
Right? Yeah. upper management will always have an opinion on what to do if you were failing constantly. I had a similar experience and it’s good that we do Talk about this, because a lot of stories that I hear on on all the product management talks are, hey, we came in, we were great, we solved this problem management loved us and built this amazing product. And what we don’t hear about is all these stories of failure and how management said, Guys, you keep failing all these experiments, why we keep doing this. And believe it or not, these are way more way more relevant. And they happen way more often it just just to relate. I had the same experience in one of my previous engagements where we would introduce the whole idea of product mindset, the whole idea of, Hey, guys, you need to run experiments, not all of them will be successful. And you need to make sure that you understand and management understands that some of these variants will fail and that’s a good thing, because it tells you what not to build what not to spend your money on. And that fear in the eyes of these people was absolutely stunning. So we would run an experiment and they would always report success to the upper management and said, Hey guys, you only built one prototype, you can’t really say you’re successful because you haven’t tried other things. And the response was no, we can’t try other things – we will fail, and then they will tell us that we’re not doing the right job.
Vitali 33:19
Yes, Yeah, I agree. So, a lot of stories that we are facing with. So then people are definitely feel like not very confident in this failures. And this is not supported by by their bosses. And yet another thing that I can say that some of them have already understood that they need to talk to users, they need to be data to be considered and they are okay with the failures. What they want to do is to understand how they can do this. And this is where we can help. Then you go Need to convince this guy, he probably needs to convince the details. But you don’t need to convince important the importance of research of discovery phase of getting the data. Of course, it’s easier to work with these guys. But there are different level of maturity. So some of them do like the baby steps in these directions. Some of them are more major, but it’s great to work with this guys. And if we go go back to the first kind of the client who had who have this to fail, you definitely can improve the situation. So you need to talk to them. You need to ask the right questions. This shouldn’t be a one on one crazy guy in your team who continue asking this question like boxcar mantas deserve, right? It should be a team it’s a team voice. So not only designer, not only BA, not only developer should ask these questions, but the team should ask those questions and then you might probably will be heard.
Vlad 35:07
Yeah. Yeah. That’s why we have this product manager role. And product management competency. and a product mindset. I keep repeating this and I, maybe it’s a self fulfilling prophecy. I keep saying that, the product manager is a thankless job if you fail is your fault. If you succeed, that is a team effort. So you rarely get the thanks. But yes, that’s the person not the only one. Like you said, not the crazy guy, but the product management is the person who will lead the effort, at least in my eyes, my opinion, as the person who leads the effort and talks to your executive tier about hey, this is what needs to be done. This is what its gonna look like this is you know, all the failures you guys gonna face, but it needs to be done. Speaking of which, I like to use another question that we have From from the list of questions we got from your webinar, that it’s really interesting because it kind of segues into the previous discussion. So you have enough data to convince people that this is this stuff needs to build that, that you kind of have enough data for data driven decision. And you kind of stepped over the part where you can identify whether the decisions have been opinion based or not. So opinion based decision is when just one person tells you, Hey, this is, you know, this is what you what I think needs to be done. And when you have a large enough body of data, you say, Hey, 80% of our customers want this feature. So I understand you’re an expert, but our customers want to do this thing. And there’s a valid you can argue that there’s a balance that proverbial Ford’s quote, If I asked my customers what they want, they’d won the faster horse they wouldn’t want a car. So so there’s a balance. It’s a balancing act between what customers want and what they really need. Maybe customers and I’ve been in that situation as well. I’ve been in situation with customers kept asking for a faster horse. That’s a really interesting question. What are the pitfalls? Or what are the disadvantages or what are the dangers, however you want to address this. Are there any precautions that you need to make when you’re doing a data driven project projects or when you’re building data driven products or using data driven insights, for prioritization? What could go wrong? If you’re using data driven approach?
Vitali 37:35
I will say that you should be very, very, very accurate in reading the data first, it’s very tricky and you can make a lot of mistakes here. What leads you to bad consequences. This is the first thing and another thing that you said very good thing that family opinion should be considered as well. So what we have, let’s call it not the date, let’s call it a dating forum closest to the cell. So, the term that sort of power that a lot of us use, right. So, the what what data gives you is just the data is just a probably when I talk to customer you get the opinion of this guy’s when you talk, when you look at the data, you look how this appears, where opinions are scalable here in your your solution product, but what you are what you what hypothesis that you are doing is basically your opinion is is what how you read in the data, and this is where we have where you should be very accurate and when you should be. You should be where where the pitfall is. So this is this is why what I think is the most dangerous place.
Vlad 38:57
So to summarize that you need to go Collect the right data and you need to be able to interpret the collected data correctly.
Vitali 39:05
Yeah, correctly.
Vlad 39:08
That we’ve seen that.
All right,
Vitali 39:12
it’s very easy. It’s very easy to manipulate with the data, you know.
Vlad 39:17
Oh, yes. And I think I’ve seen these this question come up, pretty recently, some of the product management discussions online. The question was, you know, what do you hate about being a product manager? And a lot of the reiterating answers was the ability to manipulate the data. So, you know, when when I’m showing something to my CEO, and he wants to see good picture, it’s really easy to do this because I can, I can give the data any which way I want. Yeah.
All right, guys, we’re almost out of time. I want to start wrapping this up. Vitaly, thank you for great answers. I really enjoyed the conversation. Here’s let me turn the tables over a little bit. Do you have any questions for Irina or myself? Wait, if you know if you weren’t there, you know, it’s not the other way around. Do you have anything you may want to ask? And given that Irina has vast experience in product management? And I have some as well?
Vitali 40:20
No, no, I don’t have any questions, guys. But I want to say thank you for having me here. So this is this was a very pro pleasure for me. And thanks a lot. I’m looking forward to see you again.
Vlad 40:33
Oh, absolutely. Thank you so much. Vitaly Irina, thank you so much for great questions. So thank you guys for being on our podcast and hopefully we’ll see you guys more will definitely want to hear more about data driven approach is specifically coming from the experience designer, not from the product managers.
Iryna M 40:53
Thank you guys, for having me here as well and Vitaly Special thanks to you for sharing your insights. I think the you you know, with your practical backgrounds and experience is, it might sound a little bit controversial, controversial, but that’s always great. And actually, you know, I think you’ve covered quite a number of topics without good cause some awesome discussions going forward. And thank you for doing that a lot.
Vitali 41:21
Oh, yeah, I’m counting. I’m counting for discussions. Thank you, Vitaly.
That’s great. Thanks again. Thank you guys.
Vlad 41:30
You’ve been listening to the real world product management and I’ll be your host, Vlad Grubman. Until next time!