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