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, 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.