Hi everyone, My name is Patrick Aku, and if you're interested in
building products for growth, this episode is for you.
Joining me today is Vilam Ayford, product manager at V dot
IO. And that's an environment where
every decision counts. So what decisions do they make
and how do they do that? Listen in and find out.
Enjoy. Before the show, you also told
me that Veed is like a super product LED organization when it
comes to decision making as well as how they basically grow their
organization. But now that you're behind the
scenes and also in operations, how do you see that that it's
like very product LED? That's a great question.
I would say The thing is that the the founders were both
really product minded right from the start.
So one of them is designer, the other an engineer and they
really started building out this thing and got a lot of usage
right from the from the get go because they figured out the way
to basically tap into a lot of the SEO potential there.
So that meant that didn't have to do an awful lot of of
marketing, for example. And because it's so much a
product, yeah, it's just digital product, right?
You don't have an operations part to it.
So there's no huge operational team either.
So that from from the get go, we were quite product 1st and yeah,
it, it stayed that way basically.
And the product function is mostly shaping where we move as
a company. And now we've grown.
We of course hired a great marketing team.
Yeah, they're amazing. And also on an engineering side,
we've gotten way more mature, but we're still very for very
product driven. Interesting with these designer
and let's an engineering background as or, or founders as
a background. I think it's interesting
conversations that you're going to have because even in my
position now as PM, for example, if we have tech debt or even
let's start with design. If there's designing
consistencies, then it's hard for me to prioritize that over
functional, let's say requirements.
But then still, if there's too many designing consistencies, it
becomes a mess. So then you have to juggle, OK,
what do we do and what value do we deliver?
Do you have those conversations as well 'cause I I looked at it
from a user interface and things look very slick.
I must say, that's cool. That's great to hear.
Of course, if it's your own product, it's pretty easy to
swat, to spot the places where it isn't that great.
But it's cool to hear. Yeah.
What we often see is that you with adding new functionality,
right? You can only go so far and at
some point you need to reconsider.
Hey, is our text still good enough?
Is it still performant? Is it still stable?
Is our information architecture or UX still up there where we
wanted to be? And we've run into these
situations where actually maybe we were too much product LED and
we were very focused on building all this new functionality
because we've seen that new functionality can help us grow
top of funnel, but also retain more users and the UX and the
quality have has suffered as a result.
So we had to do a big push for quality earlier this year and
that really helped us improve our retention again.
But then did you say, OK, hold your horses on new functionality
and actually focus on quality as a focus point?
Yeah, OK. Yeah, actually we there's this
anecdote from Google where they weren't allowed to ship any new
features until all the response time were on their, I don't
know, some milliseconds. And we did something similar.
We said, OK, 70% of our engineering budget needs to go
to a performance improvements for the next three months well
before we can move into new functionality.
That's incredible. Yeah.
What was in the bottleneck because at some point, but what
what I'm trying to do is do tech Deb and let's say design
inconsistencies gradually. But then if it piles up too
much, I'm now in the decision that, OK, are we going to
dedicate, let's say a month to it or two months to it to
actually clean up and catch up basically.
And it sounds like that's what you did, but there must have
been a point where you made that decision.
Yeah, an ideal world probably would have done it more
gradually. Yeah, we would have paid our
tech debt more often or design debt more often.
But we didn't. We were just pushing really hard
on the feature side for good reasons.
Like we had ambitious goals and we thought the best way to get
there in a very competitive space is to increase our feature
set. But we figured there was some
diminishing return there. So it was actually not the best
used for time anymore to build an awful lot of new features and
we had to kind of haul our horses a little bit, as you
said, and work more on the quality of our product.
Yeah, I'm, I'm not sure which train of thought is better.
Let's say if you do it gradually and can keep that up or if you
do a big batch of let's say functional and then you clean up
afterwards. I, I don't know which one I
prefer yet, but if you do do let's say a very product focused
few months, then some decisions you have to push back.
Or at least you'll have some hefty conversations where people
from the engineering side will push back and say this is not
sustainable or this is short term.
Yeah. And from the design side, say,
OK, this is too quick and now there's inconsistencies.
Yeah. I think a bit of the friction is
good to kind of really push the envelope there.
Yeah. And as many things in product
building, to me, it's a bit of a wave function, right?
So at some point in time you're optimising a bit more for
monetization maybe and then you figure out, OK, well, we've
pushed that pretty far. Now let's focus on core product
again and try to make that better.
Or also, if you look at processes in your team, your
team might feel like, OK, we have a bit more need for
process. We need to streamline a few
things, but you can also go too far there.
So it's often happening that you've instrumented all of these
processes and at some point you're like, OK, do we still
need this weekly check in or this weekly retro?
And then you remove some of it and you know, maybe a couple
months later you you'll do the same again.
And it's also fine that it goes in waves and it's you're just
over correcting sometimes. And then learning as you go, do.
You have an example of that, of processes that were, let's say,
in place to solve a specific problem.
And then later on, you figured out, OK, we don't need them
anymore and you're gonna move them.
I think mostly not so much team processes because especially Ed
feed the teams have that I worked on have grown a lot and I
would say basically if your team gets bigger, you need a bit more
of process and we haven't downskilled those teams.
So it's been upward motion, but what I've seen often in for, for
PM to stay In Sync with your stakeholders or on certain
projects, you might have a weekly sync or you might have a
one-on-one every month. And what I try to do is every
couple weeks kind of reassess. Is this still adding value for
everyone? And if it's not, then we've
moved it back to either an async update, which saves us a lot of
time or just remove it all together.
Yeah, yeah. Nice.
I like that a lot actually. I, I try and do that, but then
still at some point I feel like I'm behind and I need to do that
more often. Yeah.
And it's a lot with team processors.
And now that I'm, let's say, in the PMC, I'm way more mindful of
team productivity than I was at the engineering side.
Because at the engineering side, I looked at my own productivity
and sure, sometimes at my colleagues.
But now that you're at the PM side, you see the throughput and
you see, let's say, A wish list from stakeholders and then
pretty team productivity is more top of mind than it used to be
basically. But as an engineer, what I heard
very often is that a lot of engineers also do not really
like meetings, right? I was there for you.
Yeah, I mean, I like meetings to be effective.
So whenever we structure a meeting, I like there to be an
agenda. We come together for something I
challenge if it cannot be done asynchronously or why we're
coming together. And sometimes I've also noticed
that I push back on meetings so far that you see this like Slack
channel with a thread of like 1000 replies and then OK, we
need a call. We need to dive in and
synchronize basically. So I try and balance that, but I
am more mindful from my own side and my own productivity.
And now I feel like from the PM side, I need to be mindful of
does all of engineering need to be here?
Because I want to involve them at the start when we slice up a
new topic or domain or we do problem solving or also from the
design side. But do I need to involve
everyone? Because that can hamper
productivity. It's a super tricky thing.
Everyone would love to have all the context and you'd love to
give it to them as well, but it takes ages.
So how can you do that in the most effective way?
And we've experiment a lot with process around this.
And we recently tried something new that's working quite well
where we have one project lead on every bigger project.
And that's one of the engineers. And what we try to do is to
shave the project as much as we can with the engineering manager
on the team, the designer and the PM.
And then we do a kick off, which is very structured.
We have this Fig jam template for it.
And it's a super nice workshop of 45 minutes.
And after that project lead will take it away and go deeper.
So then the time you spend with the entire team is quite short
and it's super effective because you have such a structured
workshop and then really going deep and figuring everything out
and like raising new questions, etcetera is done by one of the
engineers. And then before we start
development on the project, we will do an async update or a
short development kick off. And then we, yeah, it's quite an
effective way to give everyone the context without having to to
kind of spend hours on discovering the project.
Yeah. So that works quite well.
I like that a lot. Like a process wise, we also
have a kickoff and I like that because I can put everyone in
the same room, but I let the stakeholders do most of the
talk, let's say with regards to what the problem is in another
tone. And I allow everyone to ask
those questions. But then the follow up is
usually I pick that up and I like that From the engineering
side, I can pick-n-pull people, but I think I might involve
still too many people because as you said, everyone wants to have
the context and I think that's important.
I think from a development side, you also need that to create the
best functionality for the product.
But then I think I can streamline that more because it
does. If I involve everyone all the
time, then there's no hands on work being done basically.
And that's the hard part. I feel like balancing that.
Have you done that, let's say always kind of intuitive or has
it been more so experience based learnings for you?
Yeah, and definitely not just me, but I'm lucky to work with
really good teams and everyone is very wants to do great work
and is very opinionated. So basically maybe the the, the
first iteration of the process is a suggestion by me or me and
the engineering manager, but then we really try to evolve the
process together with the team. And we have a team with five
engineers now on on mobile, and they're all very opinionated.
So yeah, we're really shaping that process together.
And this works. Really.
Well, yeah. I mean, if I look at, let's say,
the product landscape, I see a lot more towards pragmatism and
going fast and making decisions fast and failing fast as well.
Whereas from the engineering side, if you have people that
are very opinionated, they also want to work towards that's an
excellence in their own craft, right?
And make sure that the quality's up to par, which can clash
sometimes because if you focus on too much quality early on,
you can't go as fast later on, but you need that quality to
also go fast in the future, which is like this paradox.
But how are some of the discussions that you've had then
with these, let's say, very opinionated engineers?
Well, the opinionated part was mostly on the process I was
referring to, but also on how we build for sure, for sure.
What's really cool about Feed is that from the beginning it was a
bootstrap company. So we're quite, yeah, revenue
focused and quite scrappy. OK, in a way, yeah.
Everyone would you say also or like the is that the?
Culture, that was more the culture more in the DNA, sure,
more so than in other companies maybe.
Gotcha. And that means we're still quite
religiously tracking our revenue also for specific parts of the
products. And we're setting clear goals in
there too. So it's not the only goal.
Like saying you need to grow revenue is not really strategy.
Yeah, but it's kind of the. Yeah, by keeping the score of
how well we're doing so everyone on the team knows that we we
need to win basically we need to grow the revenue this year but
also next year. So having that context I think
helps everyone understand that we don't have that.
There's a sense of urgency to what we do.
So by having that context, I think people can already make
the trade off for themselves pretty well.
But it also helps when having these discussions say, hey, we
can't afford to spend three or four months on this because then
we'll we'll not hit hit our goals probably.
Yeah. You touched on, let's say, those
goals and I really like that. It's more so known also within
the team because then you can steer more easily.
Conversations can be focused also with that end goal in mind.
But you said it's not a, let's say, strategy.
And I'm sure that as APM, that role gets more and more
entrepreneurial, which means that you take this product and
you treat it like it's your own business, basically.
And with the decisions that you make, which I really like.
But that also means conflict either within other teams or
within leadership teams with regards to vision and strategy,
where you want to go versus where someone else might want to
go. Yeah.
How have you kind of mediated those conflicts or
conversations? Yeah, that's super interesting.
So on the current product I'm working on the the mobile
product of feed, Yeah, we started out as quite separated
from the rest of the business because we first wanted to prove
there was a need on mobile and that we could acquire customers
and that we could get them to pay.
Yeah. So it was really stand alone but
and this year, so that was last year we spent a couple months on
that. This year we're spending on
scaling up the product. So basically ensuring it can be
a significant part to feeds business.
And then next year we're looking into, OK, how can this help, how
does this fit into the feed ecosystem and how can it help us
accelerate the business. And of course we already have
plans around that. This is going to be the the big
challenge for next year. And part of that is also the
discussion on goals and metrics because if we want to focus on
supporting our desktop based users better, that will go at
the expense of growing the revenues of our mobile base or
at least the expense of the the focus on that of course.
So that's coming up now and we're trying to build a new set
of goals as a guard reel basically, yeah.
But that's still very much ongoing.
I mean, at the end of the day, a decision has to be made, right?
Yeah. And I mean, how often do you
have those decisions where you, let's say, disagree, agree to
disagree and then still disagree and commit?
Yeah, because ideally everyone agrees where you have a focus
point and everyone is of the same mind.
But as teams get more diverse, the end result also gets better.
But there's also more friction in trying to understand each
other and then make a decision. Yeah, Yeah.
So we for this focus on the the mobile first user and growth in
the revenues of mobile was in the beginning was quite easy.
But as we scaled our business users on desktop, we're seeing
more and more need to also do some quick edits on your mobile
phone or to share content from your phone to your desktop.
So it's becoming more of an issue for more people.
So the pressure is, is growing a little bit.
And at some point at this point the the team still understand
that we have a different focus also because we share that story
very clearly. Hey, we feel your pain and it's
definitely where we want to go. But at this point in time, this
is the first thing we need to prove and the next thing is
going to be debt. So currently we're collecting
all the insights and we're making our plans, but we're not
going to touch development on that anytime soon.
And by telling that full story, we get quite a bit of buy in.
But I could see at some point that the problem gets so big for
for desktop users that we need to, yeah, revise the decision.
Yeah, and it's completely fine. Yeah, I think too.
I think the faster and let's say the more agile you are.
I mean, pivoting is good as long as you don't pivot, let's say
too much. But at the end of the day, it's
not a bad thing to have focus. And I think focus and clarity is
one of the things that I learned actually really helps A-Team.
If you're saying, OK, this is now clearly a focus, then all of
the others, let's say, issues or pieces of work that are not on,
that people can already decide, OK, it's not relevant.
Probably not because this is what we're working towards.
Yeah, I think that really helps. Yeah, for sure.
There are just a lot of fires that you need to let burn,
unfortunately. And that's it's also, I spoke to
another engineer who moved into the PM position, and one of the
things he struggled with in the beginning was, OK, there's so
much I'm not doing. There's so, so many things
broken or so many times that I unfortunately cannot help
someone. And that was something he really
had to, yeah, get his mind around.
Yeah, and let go. Yeah, let go of.
It, Yeah, yeah, yeah, yeah. I'm myself, I'm really big on
time management and I'm really curious how you, let's say, came
into this new domain, understood the business as well as the
users because I think for APM to excel at what they do, that's
like a must. Yeah, basically, yeah.
How did you do that in the ramp up?
In the ramp. So we really started with
talking to people because we had a lot of assumptions on how
people might want to use, how they might want to use edit
video on their phones. Yeah, but we wanted to be build
a bit more confidence there. So we recruited people via user
testing, which was quite nice to get a quite a specific profile
and also geographically diverse in multiple places.
So that's how we started out before shaping the product
vision did. You set that up internally or
did you have like an external party that?
No, internally. Gotcha.
Yeah, yeah, we have some UX researchers in the company,
which is great. I really love working with them.
Shout out. But yeah, back then the team was
a bit smaller. And yeah, we did a very
lightweight first version and it was just an experiment.
The whole mobile thing was an experiment.
So we hired a freelancer who worked with us two days a week
to build the MVP. And then once we had the MVP, we
could start talking to some of these users as well.
So they could. We just basically had a big
button in the app give us feedback.
And surprisingly people did all the time.
So we have this select channel and it's a concept to learn from
a, from a friend. It's called the feedback river.
So it's basically you get feedback in all the time and
it's just an open select channel.
Everyone is in it. So people would also point it
out to me, hey, I've seen this a bit more often lately.
How about tackling that? And there's the engineers on the
team. So that's basically helping them
build that context around the user and the problem.
So that was super valuable. But as we've grown, we have now.
Yeah, hundreds of thousands of creators.
Yeah, that wasn't super scalable anymore, or at least it was hard
to get a very precise picture of, hey, who's our user.
So now we're again going deeper into research about our ideal
customer profiles, but I still try to speak to users very
often, at least once a week. So we have this automated e-mail
loop where we basically ask users, hey, do you want to hop
on a call with our product manager?
Yeah, and they do. Awesome.
Yeah. Well, how do you manage feedback
then? Because usually with people that
give feedback, I think it's really good that people are
enthusiastic and solution thinking as I think is very easy
because they see a problem, they immediately give you a few
solutions and are like, OK, there's an expectation then with
giving that feedback. And I think it's the role of the
PM to also navigate that, make sure people are open to giving
feedback, but they're not all feedback is going to be
implemented. And you mean internal feedback
or in? Feedback, feedback from the
users, but also I think especially the dynamic of
internal feedback which is then based on user feedback is very
interesting as well. It's super interesting one.
Yeah, it's so we work with Rd. maps every six months and in
this road maps we always present.
OK, what did we learn from our users?
And basically we build a big databank of, hey, this is all
the feedback we're getting. And it's of course different.
If you notice an icon that's unclear or a bug or like small
things, we want to pick that up much quicker.
I don't think you need a whole road map around that.
But it's more the the underlying pain points or the dreams and
wishes of your users. We address those every six
months and then say, OK, these are the big pain points we want
to solve in the in the next six months.
So that makes it easier if you get the feedback to kind of
build that up over time. Yeah, synthesize it and then
give it back to people. Do you also take them with you
then along that journey where you set the expectation?
OK, this is our road map and this is what we expect to
deliver. And we could do that more for
for our users, Yeah, we could do that more.
We have a Kenny board, I think it's called Kenny.
It's a SaaS tool where people can leave feedback and they can
upvote the feedback and we can share our road map as well.
So whether it's being considered or in development.
So that's kind of open, but most people just give feedback by
writing a review or clicking the button in the app.
They don't bother going to that website.
So we could do more there. But in the end, I think users
are also quite, you know, they're reasonable.
Yeah. They don't expect you to to
build it right away, but they already really appreciate a
product team engaging with them and reply, replying to their
emails and inviting them to to a user interview.
So we really see that that helps, Yeah, it builds trust as
well. Yeah, it's I think that
community aspect is something I see more and more.
Yeah. And I haven't seen that from the
bigger organizations like Spotify is what I use for this
podcast. Yeah.
And for the longest time they had video on Spotify.
Yeah, but not in the Netherlands.
And then I went on a vacation to the US and I saw that button
that I could upload a video. Yeah.
So I did. Yeah.
And then I went back to the Netherlands and it wasn't
available. Was gone it.
Was gone. So I was like the customer
service was like, what happened? Like this functionality was
there. Now it's gone.
Yeah. And they said, we don't know
what happened you, you were not supposed to have access to this
because it's region locked. And then I said, OK, well then I
know what happened because I went abroad.
But it took a long time for them to, let's say, first of all,
engage with me and then also set the expectation of when I can
expect anything because this functionality was just there.
But I see with smaller companies that they engage with people on
a more regular basis. You more so feel part of this
product as well as the development.
And I think that really helps them with, let's say, longevity
and loyalty and people actually using your product.
Yeah, that's which I which is really cool.
Yeah, yeah. It's probably really hard to do
this at scale though. Maybe AI helps, I don't know.
Maybe, I don't know, but the fact that you have an open
feedback channel where people actually can drop their
comments, read from each other and then probably also engage
with each other. Because at the end of the day,
if they use your product, then they use it for a specific goal
and then learning from each other how they the others use
it. I think it's just as valuable in
creating then that community that involves or revolves around
your product, which is really cool as well.
Also, it's hard to get right. Yeah, I mean a lot of discords
for our products and yeah, some of them are really thriving and
some of them are just dead. Yeah, really.
Yeah, yeah. But do you have dedicated people
that then look into it or you? For example, how often do you
allocate your own time to it? It was part of my weekly
routine, yeah, starting the week with making a recap of all the
user feedback we got last week and replying to some of it.
And we now have someone working with us from from the
Philippines and they're doing a great job and helping basically
respond to a lot of feedback we're getting and also
synthesizing it and getting it to to the product team.
Gotcha. That's nice.
This a way of working that I think is in product, but also I
think the most prevalent example I've seen is more so in video
games where things go live and they know it has bugs.
And then you have a patch, let's say a day one patch and a day 2
patch and then things are a bit more smooth and then a week 1
patch. I think that also bleeds into a
lot of the digital products that we create nowadays.
And with physical products you can't really have that.
You can't have a whole supply chain of products and then say
we have a new version of day one basically, but with digital you
can. So we do and we deliver faster
through that. But what is your thought of,
let's say that shift in what used to be versus what is now
and how we deliver products? Yeah, it's a great question.
It's a great question. I think that you need to be very
clear on what is it that you want to prove.
So sometimes people ship something health baked.
Yeah. And actually it doesn't validate
their hypothesis because it's just not good enough.
So you ship something health baked and then OK, well, the
experiment isn't really conclusive, of course, because
people can't figure out how to use it.
So I think you can split it in OK.
Do we want to make sure that that there's a need for this
feature or do we want to make sure that people have know how
to use this feature? Or do we want to make sure that
people retain better if they use this feature or monetize better
if they use this feature? So what is it you want to learn?
And then you can build your experiments based off that, I
would say. So for some things, you need to
do it well right away. And you also don't want to scare
people away. And I think an example of that
is Apple Maps. It was really bad and currently
it's really good, but everyone had the experience with Apple
Maps that it was quite bad, so people just don't go there
anymore. Maybe they can do some crazy
marketing trick to turn that around, but the perception of a
lot of people is that Apple Maps is not such a great product and
you don't always get a second chance.
No. So that's a great example
actually. Yeah, because looking back at
it, I have used Apple Maps. I think now it's actually quite
good, but I still don't use it because back then it was shit
and now I'm used to Google. I almost used it to drive here
because I copied the link from your invite and it was in Apple
Maps and I was like Nah, OK, let's copy it to Google Maps.
Yeah. I mean, that's the thing that
Apple does really well is like their whole ecosystem evolves
around their own apps and their own products.
Yeah, basically. And that works super well.
Like I had a family member that didn't have an iPhone, So then,
yeah, I can't really share any iCloud pictures.
We're not on the same cloud. We can't share any of our
locations by default. So it's that's something Apple
does really well. Yeah, but that's also only you
can do that. Or when you're very established
and you have a huge, let's say, loyal user base.
Yeah. And somehow they have that.
I think it's amazing. Yeah, it's very cool.
Yeah. And you see it in the, the
design tool space that we operate in.
You see more of this as well, where Figma just, you just
launched Figma slides, for example.
And it's the same thing. It's very easy to copy and paste
assets that you have or use your, your brain guides, those
kind of things. You're you have the your Co
workers there already, you know how to use some of the figma
tools already. So they really found a way to
expand their product footprint to do more products, basically
solve more problems for the users in a very effective way.
And that's that's very cool to see and other tools Compa does a
great job at that. So it's really cool to to see
how non apple companies do a bit of this as well.
Build really an ecosystem and that's something we would like
to do at Feed as well overtime. We're very early in the journey
still. Is there?
Yeah, yeah. You touched on talking to users,
engaging with them to get a better understanding of their
needs as well as the business. And I'm curious how you do or
how you look at, let's say your competitors within the space.
Because nowadays, if people launch something, there might be
people that try and copy or people that try and outpace.
And I think that's fair because at the end of the day, the
product that or the problem they're trying to solve becomes
or the solutions to solving that problem become better out of
that. But then within those companies
or within those environments, I think you need to keep an eye
out on your competitors. So how do you view that?
Yeah, I think competition is is basically good.
It's good for us. It forces us to be better and
it's great for our users because they get a better product at a
better price often as well. We can also differentiate on
price. So I think competition is a good
thing. The way we look at competition
is not so much, OK, what are they doing?
Also, like, of course, we, we follow everything that's
happening, but it's not so much, OK, our do we want to follow
exactly what they do? But it's more we're trying to,
we notice that our users have these problems, we're trying to
solve them. Has anyone else already solved
this problem or a similar problem?
And what can we learn from their solutions?
So basically, it fast tracks your path to a solution.
Yeah, and you see this everywhere, like people copy
from others to take shortcuts, even famous painters, they just
copy painting the the stands, the the the lights, etcetera,
and then focus on their technique.
Yeah, of painting instead of having to think about the
composition and the light. Yeah, so you can, but.
And I think that's a great metaphor for products.
So if you see what works for let's say an onboarding journey,
so the the format of onboarding journey, then we can focus on
the content. So we don't have to think about
it too much because we see that the the biggest teams that are
really successful that have ran hundreds of experiments on this
have figured out a great way of doing it and it's got it fits
our product. So let's copy that part and
focus on the content. Yeah, I really like that.
Like a proven concept that you take with you, you implement in
your own way. Yeah, but you don't have to go
into, let's say the R and DI mean sometimes still, but more
so of than establishing if this is actually a solution to the
problem you have. Yeah.
I mean a lot of subreddits with entrepreneurships and then
people basically ring the alarm bells and say someone copied me.
Yeah, of course. I already found a competitor to
an idea I have and they're already live.
And the people in the comments I see congratulate them because
then they're like, OK, you already found, let's say a
product market fit because someone is already doing it
Exactly. And I just have to outpace them.
It's validation and you need to outpace them as well.
But in this, let's say startup mindset over product LED growth,
we're going fast is like first and foremost.
So this time the market is very much top of mind.
How do you make it so it's still resilient?
Like I saw Greece, for example, introduce the six day work week.
Nowadays also other organizations I think of cutting
back and going four day work week.
But I think especially within this fast-paced environment, you
need to make sure that your team and your people can do it more
sustainably rather than burning themselves out with churning.
Yeah, basically. Yeah, I think that, well, don't
want to offend anyone here, but I think burnout is not so much a
result of working hard, let's say for five days a week is
standard, but it's more of not feeling in control of your
destiny or not feeling like what you do really matters.
At least I'm not an expert. This is what I heard and this is
what I can tell for my own work that basically makes me jump out
of bed with energy or not to, to feel like you're a bit of a mass
of your own destiny and it matters what you're doing.
And I think as APM or product leader, you can have a lot of
control over that to basically celebrate successes, to really
explain why it's important that you're what you're doing to make
sure that you're not pivoting all the time.
That's completely unclear why you're doing what you're doing.
So I really believe in that. Basically, set a good rhythm,
but also give people the feeling that their work matters and that
their input on what you're building is is valuable as well
and is is heard. How do you be?
Are you also mindful, let's say, with people in the team?
Because sometimes I see, for example, within my team, I see
people that throughout the day look a bit more drained, but
then I see them improving PRS at like 4:00 AM and I'm like, OK,
something might be either off or maybe this is just their style.
So I check in on them based on those symptoms.
Because I think I agree with you, the feeling of being in
control, like a lot of it is still in the brain at the end of
the day. But I do think rest and recovery
is like a huge component to it as well, at least from what I've
noticed. If I went too hard doing
podcasting, conferences, yeah, working as well, and then
everything at the same time because I didn't want to say no,
yeah, then yeah, you need to rest and recover.
And if I had weekends and afterwards on Monday, I still
felt drained, That was for me a symptom to cut back and.
Say no more, yeah. Yeah, but how do you check in on
your team? Yeah, we're a remote company, so
it's a bit harder, I must say. I do bi weekly chats with all of
the engineers team members, so we at least get time to chat non
related work stuff. Yeah, every now and then.
But yeah, it's in a remote company.
It's not easy for everyone and we've seen people for who it
doesn't really work because you need to be very self-guided.
You're not getting that energy from your colleagues.
Some people are working from their homes.
So it's it's not for everyone, but what we do is that personal
connection. So meeting once every year,
we're trying to increase the frequency of that and then the
biweekly chats and then some some fun things every now and
then, which is online as well. So we play games together.
For example, we have all these random select channels where
people talk about running, about cooking, about their kids with
parents. So that kind of makes it feel a
bit more social as well, yeah. Yeah, I'm assuming that's part
of the reasons why remote nowadays works is because you
still find ways to interact with each other.
Like obviously you have the the off sites where you go still a
few times, maybe a year and see each other physically because
that's like in person is just a different dynamic at the end of
the day. But process wise in this way of
working in this remote company, what have you found that works
well as well? Because sometimes it's like, OK,
you have a meeting and not everyone can join and some stuff
you need to do asynchronously. But when everyone's remote, it's
different than when everyone's in person at the end of the day.
Yeah, yeah, yeah. So that's going back to it
doesn't work for everyone. Yeah.
And I think that's that's good to acknowledge that thing.
But for the people for whom it does work, we figured that
basically making sure they have a good place to work from is
very important. So there's budget to kind of
upgrade your Home Office or or go to a Co workspace.
So that's important and very clear communication is important
as well. So we have the monthly All Hands
that is quite professionally produced.
Monthly. Monthly.
Nice. Yeah.
So people know what's going on
across the company. Yeah.
We try to write very clearly and, well, we're a video
company, so we're also sending out lots of videos.
And actually, if you need to look at dry text, it doesn't
convey a lot of excitement or emotion.
Maybe if you're a great writer. Yeah.
It's hard. Yeah, it's hard.
It's hard. And on the video, you really
connect with someone. It's very.
Yeah. We think it's a very good way to
communicate because you have much higher bandwidth.
So we really put effort into that as well to if we have an
important announcement to make a great video around it, or if we
have a product launch, make a great video of it.
Even everything we ship, we make a demo of one minute and share
it in the channel. So then you also see the people
behind what we're building and yeah, that's that's working
quite well. For us, that's really dope
because everyone then uses V to do yeah.
Exactly. So you also dog food your own
product. Yeah, yeah, absolutely.
That's really so you have many videos that people just put out
with regards to communication more.
Yeah, that's nice. We would like to have even more,
yeah. Yeah, yeah, I can imagine.
Trying to push for that. Yeah, I mean, whenever, like
right now I'm at ING, it's a bigger your organization and we
have some awesome milestones that we've done right.
And I do a written update and I feel like, yeah, that's just a
miss. And sometimes people ask for
like a demo or a product and I'm like, I can make a video, but I
know I can make a video because I just go in the studio and I do
it. Yeah, exactly.
And not everyone can do it. So then to have the opportunity
to do it at home I think is amazing.
And especially if that's the product you're building, it
becomes better throughout that because all of a sudden, if
something weren't to be wrong, then it's a user issue.
Then everyone that tries to do that and create that video can
experience that. So then all of a sudden it's top
of mind, then you're gonna fix that.
Yeah, Yeah, it's a huge advent. It should be a user of your own
product. Yeah, absolutely.
So I feel very fortunate to be able to work on a product that
you can actually use. It's not possible for all
products, right. What are you building at ING?
It's a it's a consumer face sustainability.
Related, So it's in the ESG domain, we capture public
sustainability reports and we provide insights based on.
That to see organization use that in the weekends.
No, no, basically not. Like I I like it and I feel like
I know the insurance and outs of the product because I spent the
extra time and effort on it. But it's not a podcasting tool.
Like if it was a podcasting tool, I would create a podcast,
use the podcast tool, and then be an expert on that.
Yeah, that's cool. It's different.
If Riverside is listening. Yeah, sponsors, sponsors, yeah.
So yeah, man, this has been a blast actually learning from
your experience that V very much product minded as well as kind
of the intricacies in how you operate as well as how the team
operates. Thank you so much for sharing.
Before we round off, is there anything you still want to
share? I know I think it was a great
conversation. Thanks so much.
Thanks for having me. I really enjoyed it and yeah,
looking forward to connecting more in the future.
Awesome. Then I'm going to round it off
here. I'll put all Venom socials in
the description below. Check them out, let them know
what you thought of this episode.
And with that being said, thanks again for listening.
We'll see you on the next one.