From 6 Engineers to 2: Why Product and Engineering Are Merging

Software engineering is evolving. Things are going faster and faster due to AI tooling, but processes? Not so much. They're still the same daily stand up, Sprint reviews, retrospectives. Do they still make sense? What are the expectations of engineers within that team? And same for product design, research and AI people. That's exactly what we talk about.

Joining me today is Kate Ivanova, Product Manager in Big Tech with many years of experience building products and that's a real passion of hers and she has a newly found passion in experimenting, trying out as many tools as possible.

So enjoy. I was thinking about kind of the development phase mainly from a software engineering angle and a lot of processes are you take a piece of work, you work on it, you have daily stand ups, then you have BI weekly depending on your cadence, demos and what was delivered in increments.

And if you like with AI tooling, this is accelerating, but the existing processes are still the same. Oh yeah, I'm an existing team, used to have daily stand ups. People might get blocked multiple times in a day, but there's no like synchronous touch points. I feel like the processes are very much lagging behind with regards to how things are accelerating.

Yeah. And not only processes like team processes, but in general, like, I don't know, something that I like thinking a lot about right now is like the distribution. Because like, yes, it is very easy now to build something like in a way, because then like you are building like a prototype of product. But then like when you want to make it work better or work faster, you also need to like do it in a, in a right way, not not type coded. But on the other hand, yes, processes are the same.

Like inside the team, the distribution is the same. And like, it's like some part of the environment is very fast and like it's moving forward, but other pieces are still lagging. And you need to still understand how like these two or like 3 can interact with each other. And you also need to think like, OK, but like, can I actually change something in my processes? Because they don't work anymore? And I think it is important to have this, like, mindset of can

I change it? Like, because, yeah, for example, like with all the agile rituals, they're still set in stone, but yeah, they might not work anymore. Yeah, this like one week Sprint, two weeks Sprint, then like then maybe you don't need it like in two weeks if you can build something in one day. Exactly. Yeah. Have you noticed that people look towards the product person for some of the process things? That's been my experience. Yeah, yeah, yeah, always, always. I think it is because in my

experience, product person is the kind of facilitator of the whole processes of the team dynamic. I like. Of course there is like the agile personal like engineering manager. But in terms of like how you as a product person, you have this connection between like the business and the like team and to make the team work, you need to also like work on the processes and make change them. Yes.

So yes and yeah, it's been always part of at least my experience that you need to also adjust processes and if something is not working, also readjust. Likely all of the teams that I've worked with were very happy to readjust. So it was never like we only do it like 2 weeks Sprint. Yeah, we have this like retro every Friday. It was more like, do we need it? OK. Do we feel that like it doesn't work anymore? Yeah. And then like we change it. I like that.

Yeah, I like that a lot. With regards to experimenting, I know you've been in, in bigger organisations even working on AI products. What works well with regards to then processes or experiments that you've done improving process for delivery? Well, I think first is that there should be a mindset. The team is ready to to like to change something because especially in bigger organizations is like very like we used to work this way, like the whole company works this way.

So why don't we need to change and like AI? Yes, it's like big flashy words right now, but yeah, it was

working before. Why do why do we need to change it now? So I think this is like the first milestone that you need to like change or like find people who are willing to change and with them try to build something together with AII think it is like a lot of because it is much faster like the the processes you need also the like for example cadence to be more frequent. You also need to like for example, in my previous company we have this like 2 weeks Sprint and we set the goal for two

weeks. But with AI it is changing so much. And also because like there is, it is very new. You don't know a lot of things. There is no playbook. Like now with AI we are doing things this way you don't know, no one knows. Even like people in love they, they don't know. So you just need to be ready to adapt and to change. Like you can set something like in the beginning of the week.

We are doing it this way on Monday, but then on Tuesday you realise that like with this language model, for example, it doesn't work. You need to change the language model. Or maybe there is just like no solution or you need another solution. And for big company, it means that like you need to go through the whole process of like making it like legally possible. So it's like, yeah, I think the overall idea is that you need to

be ready for changes. There are a lot of uncertainty and you need to adapt and you need to be ready. That like thing that you were thinking yesterday, they will be completely different tomorrow. But with that, I think it is still important that something that I do all the time, I still have some milestones like OK, we are doing this like one week Sprint and on Friday we still have a result. Maybe it will be not something that we imagine it to be. It will not be like working prototype.

Maybe it will be just a prompt and then we will have some result. Because like prompt you can do yeah. But even like if it it is not ready, you still have a result, you still have a learning, you still like understand something and you share it. So like people also have this knowledge and then can iterate later on. I think that's really smart, bringing clarity. When I was PMI, thought it was one of my biggest responsibilities.

And when you're saying things are just ambiguous and unclear all the time, then it it's really, it hits kind of your core purpose. So then having a goal every week to deliver something, I think bit by bit you'll clear up where your purpose is going with this product.

I really like that. Yeah. Have you also then noticed that in building this, since there are many things that are unclear, usually product could say, OK, this is the direction, kind of zoom out for two weeks, engineering team would work and then they would come back. There was kind of this divide between product and engineering. Have you seen them grow closer because of this as well?

Yes, they are definitely go closer. And I think it is not only between engineering and product, but between all the functions. And like I think in this era, it is not a good idea to make things like in this silo that like one team is working on something for two weeks and then they like, sure. Because yeah, it's so unclear. It's so ambiguous that maybe something like other people can have perspective that can help you to move forward.

So I think it is something that I see a lot of change that like there is no clear line between product design engineer and user research data. It's very like kind of in between. So now I think I work, I was always thinking that like I'm a good collaborator with my engineering team and like my designer. But right now I feel that just like collaboration actually change because it is not that IMSPM give like clear requirements and then engineers deliver me the result.

It's like I give their requirements and I, I'm very clear. But like what and why? But then we work a lot together in collaboration because something is not possible to to to do something is very like, I don't know, it takes, let's say one week and like for me, it's just not an option. And then we try to understand like, OK, maybe we need to change something. Maybe we can tweak things. Maybe we can do things not on the back end, but was like with prompt.

And then we need to change something in prompt or maybe we need to change something in design. And so, yeah, it's very, I think our collaboration right now is more frequent. And it's not that like we only share results in the daily or like in this like review. It's like more you are always in the topic and everyone understands better like what is going on. And this is of course, like very important for PM to have this clarity to always share why we are doing things.

Because, yeah, it's not like delivery. You are doing something because you need to do something like, because you need to solve a problem, you need to deliver some business result. And maybe there is like something, some other solution, something to make it even like simpler, faster that you can do together as a team. Yeah. I feel like feedback has always been big, but it might be even more of a big thing now.

Like the concept of for me as a software engineer, taking a piece of work, then being on an island and then coming back up and being like, is this OK from a technical sense? That was like something that I struggled with very much early in career. And the advice was always just ask for feedback or even pair program, right? Instant feedback is the best feedback.

The result will be better. And then if I think of the concept of pair programming now with multiple disciplines, because things are accelerating, I'm wondering if it's better if we just as a few individuals, because I do think you can do this in a small setting also as product responsible, if you can pair program with multiple eyes on kind of a solution and get this feedback cycle faster and faster.

Yeah, yeah. Because then you can steer, and you can direct and you can experiment. Yeah, that's true. Yeah. So the faster we get feedback, the the better. Like that's why we have MVP. We don't build the ideal solutions. We build like something that already we can show we can like get feedback.

Yeah. And I think right now it is very easy to build something like your prototype in one hour or like 2 hours and then show, it's like corridor testing or like, and I'll show to your colleagues to go to the street and like ask people to, hey, like, can you just use it on my phone and do something? But also, like what I like to do is to ask AI for the feedback, even though like you need to understand that, yeah, like GPT 5 is a bit better with that, like to be more critical. Like honest.

But still like you can show something for the AI and I use it a lot. I, I have like different GPTS, like different personas and I ask and I collaborate with them because like the goal here is to see some blind spots. So it is not honest feedback only like your customer can give you like feedback or you can like see how they use your product and you may you can make some decisions on that. But having this like AI Co pilots, GPTS can just give you

some yeah, blind spots. Like I usually what I do, I share my PRD or like something like some documentation or like some my pitch and I ask like, hey, can you read it and like give me your honest opinion on the blind spot. And like you can, you can read it and get some insights that are really good. Some will be like, really? Yeah, that doesn't make sense. Like because because you ask it to criticize, so it will criticize you maybe like it's it

is not that big of a deal. But still, like I remember that before it will take me like in one week to find someone, like someone from user research from someone from sales and ask them, find the time in their calendar, give them my product, 10 minutes with them just to like walk them through the user flow and then see something or give feedback or get feedback.

But now it is like faster. But again, like it's not that you don't need to do this like feedback session with sales or with user researcher or with a customer. It's just like you can now do one more iteration and get it faster. And then when you get to sales for your customer, your prototype, your ID will be a bit

more to the point. So I think it's really cool and I think product like this is incredible for product managers that you can actually have these iteration cycles more frequent and then then to your result can be like can actually solve the user problem. Yeah, yeah, I was listening to this podcast. It was the diary of the CEO and they discussed AI and how people use it. And their main point was don't leave out your critical

thinking. I like that you said that you prepared stuff and sure, you can use AI, but you're in control, right? With regards to what does this PRD look like, What are going to be the requirements? What is this pitch? What is the essence? And you can ask for feedback, but you're still using your critical thinking. You're still using your brain basically. You can also do the opposite and say this is what I'm thinking, give me a PRD, give me a product

pitch. Yes, you know I I did it last week with the PRD. So there is this really cool product chat PRDI think you've heard about it. I really love it. It's it's really cool and I put a pitch like business pitch several paragraphs in the field. That's for me. It's not like it's finance, I'm not into finance, but like I know some things and yeah, I just wanted to see what's output, like what PRD can I get? And it did really good job. It did all well.

But the problem is that it was very like because basically AI knows everything about how product work right now, but what I want to build is something new. So it can it gives me the PRD for something that is basically a copy of already existing product. It didn't innovate, it didn't like, it didn't give me the vision of how the world can look like in future if I change something in the way how like finance process works.

So what it means is that even though like you can build PRD in 5 minutes, you still need to have your critical thinking. You still need to understand what you want to build, how you want to build and why. Because like other way, it will be just like something that no one need because like there are already 10 other products that can do pretty much the same.

So it's cool, it can make it faster, it can give beautiful like competitive research, but still like you need to own the idea, you need to own the solution. Yeah, yeah. This inside of this is not what I'm looking for. Like, this is not the vision that I have. And it just cannot get there. Yeah, I think that's really funny. Yeah. Like, and it makes sense, right, Because it's so much strain on history. And. Yeah, exactly. We are making synthetic data. Yeah, But synthetic data can

only get you so far. Exactly. There is always going to be room for innovation. Exactly. Luckily, that's where we make a difference. Still. Still. Still, Yeah, yeah, I think a lot about product development and also how I use AI. For me, the podcast is my product basically. Yeah. And I've been trying to optimize with regards to titles and click through rate and everything. And now I have a full transcript that just gets generated.

I feed it to AI and usually I have a template to give me title ideas, to give me thumbnail title ideas and everything. What I've tried to experiment with as of late, and I'm quite happy with that is I can really feel sometimes where I've hit the depth of a certain model where we align and we say this is going to be the perfect title or we have a few options and one of these should be the most perfect one.

Then I switch models. Actually, I go completely because I'm clawed first or Gemini this template, I go to another model. I go to ChatGPT 5 or Gemini specifically. And then I go, this is what I've been working on. Give me feedback and like, what do you think? And then there might be an insight which I didn't think of and I improve and then I bring that back to another thing. I can go so deep with regards to this rabbit hole and back and forth.

I've been really enjoying that, trying to get to the essence of things and being like, this is really what I think is going to make a difference with regards to It's so simple. It's like title, click through rate, but it's like the bread and butter of people watching your video. And I really enjoy that. I think I can take that with me and also do that from a product sense where I think this is really going to be my pitch. This is the purpose.

These are the values. Take that, use it in a different model and be like this is what been working on giving me feedback or give me alternatives and then just keep going. Yeah, yeah, yeah. I also like switching models. I also like use different models for different jobs, let's say also Clot. For everything that I actually want to write, I use Clot. But with GPT, like GPT 5, yeah. Now I am using it also a lot for like my critical thinking, let's

say. Yeah. And also it is interesting that we use these models not only like for our personal project, but also in in work. And I have this project where part of the product was a prompt. And also like if you change the model your your like your output can be different. So when you experiment and try to get the solution, you also experiment not only with like back end with design. You also experiment with prompt and not only with like prompt as like text, but also like with the model.

But model can work better. And then like there's new model and you need to check maybe it works better for you. So it's like new dimension. It's cool, but it's like, very. Additional thing that you need to know as like a team, as a product. Yeah, it's like an additional metric. Yeah, exactly. It's a, it's a little bit out of your control. It is not as predictable as any of the previous metrics and then a new model comes out. So it can be make or break for

your products. Exactly, exactly. No, I completely agree. I'm wondering since you've been in product teams where the purpose was to build AI features, what have you seen with regards to product composition or team compositions with regards to disciplines,

people that are wide or people that are depth or T shaped versus pie shaped in engineers, But also beyond that with regards to research data and AI, what is a good team composition from your experience? Well, I think the main aspect of every person in the team and this like AI era is curiosity. So can you be curious enough to learn? Because yeah, as I mentioned before, like there are so many things that are unknown right now and like no one knows them.

So you need to just experiment, you need to try new ways. So this is like the main thing that you need to have on your team, like for people in your team. And then in terms of like how I see the future of teams, they will I from my experience and like that I really believe in they will be more flat in terms of like, I don't know, when I started, I had two teams of engineers and like in my, in one team, there are like 464 to six engineers.

And then there is a designer. And then there's like part of user researcher. I don't see that we need it anymore in that amount. So I don't say that we don't need these functions, but we don't need like 6 engineers anymore. Why? If you can create product with like 1 back end, 1 front end, and yeah, and they can generate of course, like they need to refactor it after. But yeah, it's like smaller team that can actually go faster. And yeah, I think that in

general this will be the future. So you have like small engineering team. I still think that you need to have this function of like designer PM and to use a researcher. Maybe they will be not like for PMI think it it needs to be dedicated, but for like designer and for user researcher maybe they are can be merged. Maybe they can also be distributed between like different teams. But I think the the future is in

this like faster iterations. So if you iterate faster, you just need to be smaller team, more autonomous, but with like all these functions included that like you can actually operate as like 1 unit and do do these iterations. So I don't think that we don't need engineers, we don't need designers, we don't need user searchers, no, but maybe they we don't need them in this amount that we have right now.

But of course, like, it is very different because honestly, I never had, for example, use a researcher that is only in my team. Yeah. So it's always like shared between different teams. Yeah, exactly. Yeah, My hope is that, and it's kind of hard to do that now, but hopefully in the future it's differently. If there is one problem and we're looking towards different solutions, there can be multiple teams trying to solve this one problem, right?

Because right now if there's one problem, usually you spin up one team and they try and tackle that problem. It's the same people. But if you already work in smaller teams, then you can have a few teams trying to tackle that problem and they can learn from each other, but they also can just work very isolated and see what the results are. And the results can be leading with the rest of.

This is this is very interesting because I've been thinking about it a lot and they see that there is a big risk that when you have different teams that are autonomous and then that can tackle like this problem space, they can do first, they can do the same things or they can go in such different directions that like it will be impossible to merge them together. I mean like the, the product that they produce.

So I think it is important in future to like still make it very clear in terms of strategy and in terms of like alignment on what is actually direction and what and how we are building. Because like even now in big companies like you've heard, I think this story is that like for example, in Google, there are several teams that are building for the same problem, but they create different solutions. And then like the best solution means. So it happens already.

And I think it will be happening more and more. And on the one hand, I understand that like, yes, maybe someone can make better solution, but maybe we can make it somehow different. Maybe we can like not put all the resources to do the same things. Maybe we can distribute our resources in a way that like you're working on this problem space, you're working on this problem space, but we have very clear like North Star, we have

very clear product strategy. We understand our business that we are in a way going in the same direction. We like solving the same high level problem. Yeah, I feel like it's it's the rules of the game. If there are no clear boundaries or if there's no clear purpose, then what I've seen is just anarchy. They just go everywhere and I like that. One of the expectations of engineers is to think more with regards to product. Know your business, know your

domain, be close to your customers, know what to build and then build it instead of just building things and getting really enthusiastic about the technical side. Like there are still people like that, but I do feel this trend towards more product oriented engineers, which is a good

thing. But then if you have that full responsibility, if you have both the responsibility of product and engineering, then indeed you're kind of the orchestrator of your own ship, and people can go any which way. Yeah, I think that it is still important to have this collaboration to have people with different opinions. Yeah, because like when you are a solopreneur, it is cool. You don't need to align with anyone. You can do everything by yourself.

But you can be so focused on one way of thinking that you can miss very important opinions, you can miss very important point of views. And like, yeah, you can have blind spots. And yes, it is cool, you can do everything by yourself. But even like when I now do some like side projects, so in AI, like some wipe coding tools, I still share it in my LinkedIn. I still like just share it with my friends. And like I ask for feedback because I build it by myself for me.

But yeah, I want other people to also use it. I want other people opinion. Yeah. So I think it's important still. Yeah, absolutely. The teams that I've worked in that has been have been the most effective was where people felt safe enough to ask feedback for each other. But also looking at disciplines is when there was a good relationship specifically

between product and engineering. And I think I highlight that because in some of the teams where there has been dysfunctional behaviour, that relationship just wasn't as close with the rest of trust or with the routes to ownership of different artifacts. From your perspective and your experience, what are the expectations of engineers and have they evolved or are they still kind of similar?

I don't know like if it is our current market expectations, some high expectations, but I really like the, the thing that you mentioned before really resonates with me that like engineers is not the only person who like just get the requirements and produce code. Like no, why? I can, I can do the same with AII can like put my requirements

and get the code. No, this is the person who can also understand the product space, problem space and who can also like relate to what we are building for customers. I at Mira, I think this is like really cool set up that we had where we had weekly sessions with our engineers where, where I shared our current user problems and we generated like we brainstorm together because they like engineers, they can have some solutions that I just never thought about.

And yeah, maybe like they're very technical, but still there's something that I can take out of this and like with my designer and we can build together something really cool and that I really like when engineers they push back for product. I mean, like, sometimes it's a bit too much, but yeah, whatever. I I like the when engineers push back in a way not that like, yeah, it will create enormous amount of course and like that it will be tagged that and like we will die.

But when they push back in terms of like, but we are not solving customer problem like, or this is not what we need to build because like this is not our business case, let's say. So when people understand different aspects of of business and different aspects of product and cannot like and can, yeah, say it out loud in terms of like push back in a way that like actually makes sense. It is really cool. And yeah, it's, it's for engineers, but also like for all

other functions. I think when you understand the business, when you understand the customer, yeah, it's just like make much more sense also for your motivation, of course. But yeah, I think for engineers now it is important to have this connection. Yeah, I feel like in teams where people understand the business, like I feel as a product person or in my previous role being responsible for product, I would

just miss things. The domain can be complex and they have really good engineers next to me that hold me accountable and say these are the things and we haven't really accommodated for them. I love that. It's like it's not me just thinking and being the orchestrator, it's everyone thinking alike and then it makes it so much easier to kind of build and do the right thing or have a smaller risk of building the wrong thing. It's all about risk management in the end.

It's all about trade-offs as well. You mentioned one thing which I think is interesting and that's the concept of tech debt within a product. I came from a software engineering background with regards to tech debt building things. If it's too much, good. If it's too complex, is it worth it? With regards to actually solving the right problem? I would also be the person that pushes back, so it naturally makes sense.

I wanted to try the product role, but I also felt like it was my responsibility to have some discussion with regards to is this going to be something we build and throw away? What is going to be tech debt for the long term? I've played around with regards to building features and having small part of tech debt in the same cycle let's say, or only doing product and then doing a cycle of kind of cleanup. I still don't know what works well.

In the end, I just decided this is also a team preference. This is something I can align with with stakeholders. I can always create clarity and communicate about it, but if this is the team preference, then let's do it.

It gives people energy, it makes people motivated, and I feel like that's an under represented statistic. It's like developer happiness. Oh yeah. If developers are happy, yeah, your product flies. Yeah, that's true. That's. True. How do you manage more of the operational kind of tech debt related things from? From our product. Angle. Yeah, I, yeah, I think I in general, I believe my team.

So like we have this always I try to build this trust and have this like very clear, like I believe you. So I really think that you can make this decision like better than than me, than the product person. But on the other hand, it is very important to understand the risks. Like, OK, we can like ship now 10 features, but it will come with the price of like one month of tech debt, let's say. Yeah.

And then like you decide, it's also can be something that like you, you can have some external deadlines. Let's say you have some like demo, you have some sales call and like, yeah, you just need to build something right now. But then you need to be very clear with like your stakeholders that like, OK, but then like 1-2 weeks, we will just like clean it up. And then with the team, it is

also important. I I don't like when we as a team have something like for let's say 2 weeks only like cleaning up the emails that we produced before. Because like, also from your motivation, like what was your two weeks? Yeah, I, I was doing nothing. I, I was like cleaning up, which is brooming. Yeah, exactly. So I understand that like for your motivation, like, yeah, it's, it's not a good one.

So I really like to distribute it in a way that, yeah, we have like we are building things like 30% say of our week, we are building something new. Then we do some tests we like, I don't know, fix bugs. And then we have this like tag that that we also need to to deal with. I think this is this is a good one. But yeah, sometimes my team say, yeah, let's just like build it

now. And then like all people of our team will be, will be dealing with the tag that like if it is your decision as a team and like, yeah, everyone is agree, then yeah, let's do it. Absolutely, yeah. I mentioned developer happiness a bit before, yeah. And I'm curious to hear what your perspective is on developer happiness or what what have you seen that makes developers just really happy? Oh, I think it's, it depends on

people. But for like for teams that I worked with, they are really happy when we make the difference, when we create something that actually like

that is impactful and impactful. Not in the way that like, I don't know, we increase activation for 30%. We might do it, but like, yeah, usually it takes time. But yeah, we make inputs in terms of we adopted like, I don't know, Co pilots or like we produce something with like this new technology or we run AB tests and we already see

results. So it's yeah, it's just if you can create this impact and that's why I like tag that is very often is not impactful enough because like, yeah, you you're not don't create anything. But yes, I think that's for from my previous experience when, when you feel that like you're moving forward, I think that's when you have a lot of just like feeling that you stuck. This is like the worst motivation.

Like then people really don't want to yeah, and just like go to work, they don't want to produce new things, they don't have any ideas and etcetera. So this is like the really something that you should avoid this like feelingness that you stuck and you don't want and you don't need you, you cannot like move forward. So this is also very important as APM to like sense this feeling.

Sometimes it's really strange, like some like, I don't know, you're waiting for, I don't know, approve from someone. So you as APM can just go to other PM and like really ask, Yeah, but very kind. Yeah. But on the other hand, like, yeah, just like this feeling of are we going to the right direction? Are we moving forward? Are we like getting closer?

It is really important. And I think for like engineers, this is something that build their happiness and like this feeling that I actually make the difference maybe like it is not a new product that like everyone is happy about right now, but this is something that I created. Yeah, it's the, it's still a a purpose kind of feeling the product is very much involved in.

That and I think This is why it is also important for, for APM to create this like clarity for strategy and like to, to build this connection between engineers, between your team and the like business and like the high level vision why we are doing this. And I remember one of my engineers, he asked me at some point, like, if I now go to my team and ask them, what is our vision? Can they answer? And back then I realized that

like, yeah, they cannot. And then I spent a lot of time to just like build it with them together. So it was like our team vision that was Co created together with engineers. And then at some point I

remember I was just like asking my team, yeah, So what are we building? And they were like, yeah, we're empowering like and it was really cool because yeah, they just found this like Bologna and also like they Co created together with me. So it was like also their creation. So they felt very deep

connection with that. This is a skill for me that can be really, really beneficial or it can be if you don't execute it properly, it can really just make a team disconnect because if you have spend time on a purpose and another person comes in and we're doing this purpose session again, you'll feel lost. I feel like where it works really well is where people indeed feel connected to it and they can act and execute upon

it, right? There's a risk with regards to kind of this experimentation culture that we have now where people don't feel this fulfilment because you didn't experiment and it fails. You can experiment and it fails and you, you want the success. Communication is everything. So if you see failure as also progress, then that can be motivating for people because we're getting closer and our experiments are becoming better and better and we are getting

there. But I feel like communication and clarity, these responsibilities as a product, they are now more valuable than ever. Yeah, with regards to kind of how a product team functions and executes. Yeah, especially with all the information that we have. Yeah, like all the Slack channels. Yeah. It's just, like so easy to fly away and like don't just out of the sense of where we are, what are we building? What are we doing? Yeah, yeah.

And I think it's in, in every role that I've done for me, there's a challenge of tunnel vision because there's more and more responsibilities going to engineers, but also product, I think user research, data and AI, those are all kind of skills where it's becoming very broad, which means that you only have a finite amount of time. You focus on this one thing. And the fact that you focus is good because then focus brings depth and it brings clarity with regards to that specific point.

But you have all these other things and you might be tunnel visioned. If I focus on specifically the operations of my team, I might disregard if people are actually happy or I might disregard for going in the right direction. If I focus are we going in the right direction, I might disregard indeed kind of the process things.

And it really helps me with regards to the total responsibilities that I have in asking for feedback because people bring their perspective and they also have a focus on one thing. We delivered products and product after product. And the feedback that I got was we didn't fix up this tech debt and I could make the decision on. Was that a purposeful decision or did I disregard that? Did I miss that? And for me, that's incredibly valuable with regards to product

and growth. How do you handle feedback? Do you have like a a specific process? Is that on the fly? Is it more as you go? Yeah, what kind of feedback are you talking about? Like I think it's both feedback for you in a specific product role you within a team, but also feedback with regards to what have we done in the last few weeks. Yeah, I think it is like, still it is very like I feel very vulnerable when I got feedback. Like it's like me as a person,

like I'm a human being. So this is something that I

really work upon. And yeah, I think it is important to have this like, very open relationship with your team and also like this kind of ask for feedback that is like, not, yeah. For example, I really appreciate when people praise me because, like, you know, usually you feedback when something goes really bad. Yeah. And then you end up with like, thinking, OK, why? Why I get only like this feedback that like why I need to improve.

So I think it is very important to actually like have give feedback about something that people do really good. Like I really like that. Like one of my engineers, she she had really tight deadline. So what she did, she did generated some code with like a compiled and yeah, it it's all the problem and no one ever done it to the team before.

So it was really cool. And like, we make the whole big deal out of this because, yeah, let's show other people that like this, this can actually be done. So this is actually really cool. Yeah. But of course, like when you got feedback that something is not working well, this is like this is your moment of reflection. But I think it is important to be in this like gross mindset that first when you get this feedback, it means that there is

a gross opportunity. It's not that like something is bad in you. No, it's like the opportunity for you to grow and the same for your product. Like it's really cool for you as a product when like you have this, I don't know, like usability session and you see that everyone nailed it. But honestly, like it never happened that way. So every every time for us, you have like people like you think that they will get it.

They don't understand like this button, they like don't understand where to go. They don't see the point of like this flow and etcetera. And of course, this is a frustration. This is like normal because like you put your soul in this to to build it and like it it, it didn't work out. But on the other hand, you try it and now you understand a bit better. So like your next attempt will be better.

So I want and like I tried to think about it in the same way product or your like personal one that this is something that like we build with our best assumption. We act with our best assumptions. It's very rare when like people do things because like they want to sure to know they also have like some good intention in in their mind. But like it didn't work out.

OK, Now we know that like this way it it doesn't let's try something new and for that also like how try you also can have your like collaborators you can ask for feedback, you can ask for help and this is fine like asking for help. This is something that like I also one of my lessons is asking for help is actually very brave thing to do. It's not that like, I don't know. I'm so I've been in product for so long, so I don't I know everything and like, I don't need to ask for help anymore.

No, you still do, especially now. So yeah, it's it's the same for for your product, for your team dynamic, even like for for me as a parent. Yeah, you try something with like your best guess, with your best intention. It doesn't work. OK, we reflect on this, we move forward. Yeah, of course sometimes you reflect on something you understand. Yeah, maybe just like doesn't doesn't make sense to even continue. It's also important to to to mention.

But yeah, just try it out. It's like experimentation. The whole life is experimentation. So we we don't know. Yeah, yeah. And and continue. Have you had that experience, the last one that you mentioned where you you reflected and you said, OK, maybe this thing that I'm building, maybe it's not actually solving the problem that I want it to be?

Yeah, I had once, I mean, like, of course not once, but like I think one time that was extremely painful for me because it was very cool product and it was a lot of resources, like a lot of resources like the whole team and yeah. And at some point it's yeah, we just miss the the time. So it, it was like the set of, let's say events, different decisions and etcetera. And like the market that the thing that we were building in the beginning just like at some point didn't make sense. Yeah.

So it is very hard, especially when you're like very near the end you. Put everything into this. Yeah, exactly, exactly. And also like if you reflect on like, OK, like what what my likes three months were look like I was building this and now this is like this big product that like everyone is happy about and you don't have this story. Of course it is frustrated. But on the other hand, it is much better to stop at some point when you understand that like, this is not what we need

and refocus. It is extremely painful, extremely hard. But this is so cool to to do it and to have this like courage to to stop it and move on to to something else. Yeah, for me, that's, it's a bit of a paradox, right? Because you want to care about what you're building, you want to care about your users. But then if there's so much information, data or user feedback that says that what you're building is just not, it's losing its purpose, then you can push, and you can push

as hard as you can. And at some point, yeah, you might just have to accept that it's just done. I also feel I also saw this case when like you build something you already understand that like it doesn't work but you still can create the story inside the company. You can like find the numbers that will show some progress. Yeah, very specific, yeah. You still can find the quotes from customers, like from your alpha users that that will show the value. But like, honestly, does it

actually make sense? Like doesn't create an impact. Yeah, no, yeah. I feel like then it kind of hits your integrity. You're just window dressing at this point. But yeah, it might be. I like that you mentioned that people that are sometimes doing something that you don't understand, it doesn't come from a bad place. Yeah, I've rarely seen it come

from a bad place. So even there where someone might be window dressing, they might really just believe in only those specific numbers, filter out everything that they think is noise but actually reality, and then still come in from kind of their perspective. I say this a lot on the show. I'm very naive. So that also means that what people tell me, I believe, I don't believe. They go behind my back and they do other things.

It's just the way that I am and it makes some things easier and sometimes it surprises me when things are otherwise. That's life as. Well, yeah, but I realize that it is easier to have this belief than the other way around when you think that. Yeah, everyone has like other agenda. So yeah, I I am also like this, this kind of believer. Yeah, yeah, yeah. To round off, there's a lot of people listening, I think mainly software engineers, but also product people.

There's a lot of things accelerating products with regards to AI features or AI tooling with regards to productivity. If there if there's one piece of advice that you can lead people off with, either from a product sense or more from an engineering mindset, from your experience, what would that be? It's to be curious and not afraid to experiment because especially right now, like honestly there is like no rules on how things will go. Like everything is changing every week.

Like we don't know what will happen in one year, 2 years. We don't know what happened like in I don't know like next next month. So don't afraid to experiment and just try it out. Use it. If it works, cool. Just integrate it to a workflow, integrate it to a life. If it doesn't, it's also good learning. Then you know what? Like what doesn't work, how you should not do. And then move on and continue because, yeah, now is the time.

Yeah, we'll run off here then. Thank you so much for listening. We'll see you on the next one.