Episode Transcript
[00:00:00] Speaker A: Hello and welcome to another episode of Can I have it in Blue? A podcast about design, technology, product and everything in between. I'm Alvar Bzera, joined by Tadeo Freida.
[00:00:11] Speaker B: Hey.
[00:00:12] Speaker A: And together we'll explore the high lows and expected terms of product work. We'll be talking about the product management role and how it collaborates with other roles in building products. It's something that we have all faced, especially as product managers and yeah, and we have Tadeo here to share his perspective and experiences to together with mine. So, Tavio, you are a product manager currently at Builders Camp. Can you tell us a little bit about that project?
[00:00:39] Speaker B: Yes, of course. First of all, I would like to thank you for inviting me to your podcast here with the Office of Visual. So for me, I'm very excited. It's my first time.
Regarding Builders Camp, I would say that officially my role is pm, but I would say that I'm a builder and I would say generalist responsible for driving this digital platform where we started to be a platform where we can teach to everyone all of the nuances and areas of how to be a good product manager. But we are shifting together with the reality of 2025 to be more like a builder. So that's why we are changing to Builders Camp and we are trying to teach to the new professionals how to have this mindset of you're not only a translator or collaborator, you are one of the team and you also building the products.
We have basically a platform to help people doing that.
[00:01:44] Speaker A: That's really interesting. As you know, I've accompanied the growth of Builders Cam for a few years now. We even collaborated on theme with the episode and I find it a really interesting shift because, and I agree that as the world evolves and new technologies appear, the role also shifts and changes. So what do you think was the keystone criteria for that growth of the project?
Could you pinpoint a specific thing that led to this evolution?
[00:02:21] Speaker B: I'll say that from my perspective, I think the latest years, things are evolving so fast. And I'm not really referring to when people say, oh, AI is going fast. It's really the behavior and way of people do things. And society is changing. So the only way for you to thrive in the society is to adapt to the changes of the society. And in the beginning, even PM Digital, PM has been a recent role, let's say 10, 20 years.
But how can I say it gained a lot of popularity in these years and people wanted to get it better and go with the hype.
So we Started as this as like let us be a full stack product manager because we truly believe that the good product managers can adapt and shift to all of the areas. Not really a translator, which is important, but also collaborated in different areas. But with this shift, we understand that companies are shifting and we have to shift together. So I think even thinking about the lean startup, I think everyone knows that we have to adapt and society is changing. We have AI tools, everybody knows how it's changing our way of working and we want to make better professionals. Our vision is that we want to be that person and want to help people to achieve that. So we need to change and this is the way we are changing to builders camp where we are putting this mindset of you are a collaborator, you are a doer, you are a builder, you're not only a translator, you are part of the team, you are important.
And that's how we are growing. Basically we are going with the flow.
[00:04:08] Speaker A: That's a really interesting take. Yeah. And especially with AI and all the capabilities that it brought to people that don't know how to code. As in fast prototyping, being able to.
To quickly get something built, not something built ready to ship and to scale, but a prototype, being able to. That allows you to test and showcase and actually validate a lot of your assumptions. I think it really shines a light on the PM role. As you said, we might no longer be only translators and doing the cross functional communication. Right. And cross functional collaboration across different areas. But actually go a little bit deeper into the discussions myself. My background is psychology. I'm not. I don't have a technical background. So I always felt that sometimes I was a little bit out of depth in development discussion or engineering discussions. I don't know if you. If you feel the same, but nowadays, although sometimes I still get way above my depth, I feel that we don't need to rely so much on. On engineers for small tasks or for small changes or even to test and. Or even just to figure it out. We are much more part the process or collaborators as you said. So yeah, I think it creates a great setting for this episode. Would you consider that translation was the core responsibility of a pm and now it's changing.
[00:05:41] Speaker B: Actually I would like to follow up a little bit and maybe go a bit backwards.
We had this conversation before, so if people don't know about how we see ourselves. I remember you saying that you were a good. What was mediator of discussions and translator, which is important is the person who understands both points and knows how to Communicate it and make it easy for everyone. Actually, I don't consider that. So both things are important, maybe different aspects. I think there is no right choice. I don't see as that. Maybe I see myself as not a translator, but maybe a connector because I always have been everything. If I go a bit personal, I'm a bit of a geek. I like to consume a lot of knowledge about everything. I don't have a specific area I like. If something is interesting, I really go deep and I can go really deep and I think that's how it shaped a little bit my person as a professional in a work environment.
So I always been, let's say the chaotic generalist and the connector. So. And I can go in detail after if it's necessary. But all in my experience in the startups or in university, let's say I was never one role. I was a data scientist, but I was a PM Then I do business strategies and even sometimes a therapist to help people how to behave inside of a company.
At the time I felt that I never belonged anywhere. But eventually I saw that this was my strength because I can adapt so fast to different areas. I would say that I'm not the best translator, to be honest, but I'm a good connector because I really understand both sides and if I need to help you on one area, I'll be there. If I have to help you on another area, I'll be there. And at the end is really a translator like you. I don't want to lose Fox, but I would say translate is very good on communication. Maybe I'm not the best on that, but I really connect very well different areas and I think that's how my brain works. I work in systems. I love connecting dots and seeing big pictures and the causes and effects of everything. And for me product it has been a really good and very.
How to say, makes you happy to be here because give your permission for be a journalist. I don't need to be specialized in one area and I think my versatility turned like a strength here on product management.
[00:08:22] Speaker A: That's beautiful. And I fully agree. I think one of the best things about the role is the fact that we are the generalists in a specialist world, right?
[00:08:32] Speaker B: Yes.
[00:08:33] Speaker A: And yeah, some people will freak. I personally love it because it has also always been my profile. Yeah. And I think it strengthens the importance of collaboration. Right. Both within our role and within a team. As in you need someone that is actually an expert of collaboration because we handle different profiles, different specialists, different goals and different mindsets. And somehow from all that chaos, as you said, we need to find a pattern. A pattern that connects everyone and makes everyone roll in the same direction. Do you have any strategies that you use?
[00:09:16] Speaker B: I would say that first program manager in general I think it's not problem management. I think reality life is about all about uncertainty. And this is another topic I think is interesting. I used to hate uncertainty and now I love it.
I'd say that the strategies for collaboration is a mix of communication and organization. I think in communication is a lot of alignment and make sure everyone is seeing the same problem.
I think most important is being human as much as possible. Everyone has a different version of the same thing. Everyone looks things on different perspectives. Every possibility, every option has trade offs, priorities, context. So it's really hard to do this task. So first of all communication is really important. But how do you do good communication? I think the strategy that helped me especially my first experience when I was a junior in a startup was that no one had really sure how to build a really complex product from zero. Our object was to do a web app which was A.B. basically a AI analyst for football. So it had a lot of companies, football coaches, video tactics. It was very complicated. And I think people in this uncertainty have difficulties to communicate. And I think the most important is empathy.
It's really not technical but it understand that everyone is difficult, everyone thinks difficult.
And I think to do good quality work you need to understand the other person. So now I know from your side that you are a good communicator. I try to be, you try to be.
That's something I need to work more. But you, you know your strengths and maybe your weakness is. I don't know sometimes of you told me going in one topic that's okay. Everyone has strengths, everyone has weakness and nobody's perfect and have this empathy to understand that Alvaro will output the best of him doing this. Now I know how I need to behave and not always this thing oh, he doesn't do this good. There is no good or right that's the best of this moment between these people. There is no system that fits all. So it's really empathy to understand both sides and then his organization. But I think that organization is a bit baskill because I'm not a fan of all.
Let's say agile is being literally agile. You don't need to go on a framework. That's how I think it.
[00:12:04] Speaker A: Yeah, yeah, exactly.
[00:12:06] Speaker B: And you need to have some structure. But at the end I think like you told before is more important to over communicate it in the beginning your intentions and not about the task and not really document all the tasks and then accept the flow of everyone. If I'm good. Concentrating one way is less over. Control is over. Communicating in the beginning and less control after because you have to have your, how do I say, your understanding. Not understanding is the word about freedom to, to do the best of what you can do.
But you have the goal. Well, communicating the beginning so you know everyone is aligned and then you can go there. I know I ramble a little bit on the strategies. I try to go on both sides at the end is to deliver something good with collaboration.
[00:13:01] Speaker A: I agree. And no, I don't, I don't think it was a ramble at all. I think it proves your initial point that communication and it a lot comes down to it is hard. It's a hard skill to work.
[00:13:14] Speaker B: People are hard.
[00:13:15] Speaker A: Abstract. Yeah, people are hard. And that's cool. That's cool because that means that they know their strengths and their weaknesses and they stick to it. But yeah, I remember that on multiple projects I feel that the trait of a good PM when starting on a project and I do get that context a lot working in consultancy is to listen. Because if you are integrating a working team especially I've seen a lot of PM just go with their like Agile framework notion templates, JIRA boards and all of that and just apply the, the same formula to every instance and I refrain from that and I do feel the pull sometimes because I like it, I like working, I like organizing and fidgeting and all of that and tinkering. But I enabled myself.
I believe you empathize and the first things I do is to actually listen and speak to the teams to understand what problems they are having with the current process. And then I only create tools to support those problems because I don't want to over engineer a board or a workflow that just creates confusion and extra work and also because that's the best way to ensure people will use it because you fixed a pain that they were feeling on their day to day. I remember it was a hard learned lesson.
One of my first initial projects I was actually at the time working in team with the Visual CTO Gabriel and we were building the board and I went crazy. I had like an ocean full of relations, full of databases.
[00:14:57] Speaker B: And when he saw, yes and when.
[00:15:00] Speaker A: He saw that he was just like no, no, stop this, stop the madness. You need to calm down and you just, you need to focus on what problems we need to solve right now. We just need the board. We are a small team.
You just need a board with initiatives. Focus on that and listen to the pains. And I go back to that conversation a lot because it was an important learning experience. And I also want to touch what you mentioned regarding uncertainty because it's a quote I say a lot to my teams is I'd rather be wrong than confused. As in if I'm wrong, I don't care if I'm in front of a customer or.
And in any situation. If I. If you see me saying or doing something that it's wrong, please correct me. I'd rather be wrong than to be confused because confusion generates assumptions that then generates work. If I'm wrong, I'll fix it or I'll correct it right now. If I'm confused or if the team is confused, then it's, it's worse because then you get wrong assumptions and, and since people don't know that you're wrong, you won't inhibit yourself. You just keep going. And that creates expectations, all of that.
[00:16:14] Speaker B: Interesting. Interesting because it reminds me about another thing you touch in the beginning and you touch again about the listening now about uncertainty but in a different way about in collaboration. Again this reminds me, I think some. This is some thoughts I have been thinking on the last experience in person. One is it's like always listen. It's so important to listen. It's so difficult to really, really, really be focused on the other person.
Not only focus on they saying but really catch the meaning of people are saying this is so important. And this goes to another thing that I'll touch is I would say that is ego and I would say question yourself. Question for me lately I've been doing this and is always questioning myself. Always. It's like everyone has some ego and sometimes we can be a bit arrogant or low self esteem. But always questioning in product work and applying also in life is really good because I'm listening to you and I'm thinking is that right? He's thinking because I. I was thinking different.
Am I wrong? He's wrong is that maybe nothing's wrong. But always questioning all the time the things.
Because it really creates thinking of yourself. Not really. And this can apply to news, consumer news, the politics, anything like really question yourself all the time, really reflect. Like I always try to not assume everything at once and always do. And this can be applied in products like Discovery.
So focus on listening and then questioning question even yourself to understand what the person is doing. And this I think creates truth, whatever it is.
But I think it creates quality work because if we go to more, let's say product capitalism, whatever, it's like you want to deliver the best product for the user, but at the end that's what it is. You are delivering reality and truth. This is good quality product work.
[00:18:28] Speaker A: No, I 100% agree. For example, so visual lead designer Joana does this very well.
I believe she has a researcher's mind.
For example, myself, I'm a very yes man and let's get it done, right. And I sometimes I have to innovate. Yeah, let's, let's do it. Let's do it. And I sometimes I do have to get more into my researcher mindset. As in, okay, let me ask questions first. Because especially when you get a request, right? A feature request or a change request, usually from the product owner or the CEO or whoever owns the product you are working on.
I think let's do it.
[00:19:08] Speaker B: Take the ego of you think it's the best solution and because you're really excited to like this is like let me think, is this like, let me take my.
[00:19:17] Speaker A: Exactly, exactly. And yeah, and with time I developed that muscle because I think just like a real muscle, it's also something with practice you get better at, which is okay, I understand your excitement. I know this is your baby and you want to make it grow, right? But everything costs money. Any change will cost time and money to the team. So let me be the cold headed person here and understand the questions and understand the goal by asking questions, right? And that frame of thought, it's really important especially when collaborating with a product owner or similar roles, right. Because it's their job to keep, to move the needle, right? To keep to, to keep the speed going. So if, and it comes down to empathy, as you said. So if I'm interacting with someone that it's on is on that mindset, I'll probably will have to empathize with it and understand, okay, what this person needs now is someone to pull the brakes a little bit so that they don't crash. Right. On the other hand, sometimes we also have to be the hyper, right? As in the team, for example, isn't aware of the goal, isn't high, isn't motivated, does not understand the big picture, then you probably will have to be the person that. Okay, let's look. This is our goal, this is our vision. We'll do X, Y, Z, solve this problem. It's gonna be amazing. It's gonna get, take time and we'll have questions, of course, but in the end it will be amazing. And yeah, I think it goes down to empathy as you said, empathy and looking for truth.
[00:20:59] Speaker B: So understand really the doing the question, like question yourself like you do, Joanna. Like you're excited, but it's like maybe you are excited because some, I don't know, maybe it's a topic you really love and you get excited about that.
[00:21:13] Speaker A: Yeah.
[00:21:14] Speaker B: And it's not the truth, it's your own reality and it affects the output. It doesn't mean that things are going to get. It going to get to bad because it's just you are excited on a theme, but it's your.
The reality of your intentions, not intention, but your love for the theme. And this is not the truth and this will not be the right output. Do you understand what I mean?
[00:21:45] Speaker A: More or less. As in I think that, how can I say it's a good thing to bring ideas. And as you said, it's will most likely be a good idea. It's just about timing, right.
Products, good products take time.
[00:22:02] Speaker B: Unfortunately, yes.
[00:22:04] Speaker A: I think it's a reality that most people outside of product don't get is that it takes time to get an idea ready for production. It goes through a lot of steps.
[00:22:17] Speaker B: Not only production, but to find the product feeds, find that all the pieces are working even in production. And it takes time.
[00:22:25] Speaker A: Yeah, exactly. I use the, you know, the prd, the resources requirements and yes, the triangle. Right. I use that, that framework a lot because it helps in that discussion. Right. As in you have to balance the, the effort that you have, the team that you have. So when, when you get a new request, you always have to compare with the work that you're doing now. And if you're, as in if your developers are already on it, most likely they have much more knowledge of that, of that feature than of the new one. So even shifting will have a lot of costs. Right. Because it will be starting from scratch.
[00:23:10] Speaker B: That's all about uncertainty.
[00:23:13] Speaker A: Yeah, exactly. Managing the, the knowledge, knowledge that the team has at some point in time is also important for us, I believe to understand.
Okay.
How clear is my team regarding the requirements and where to go and what would be the cost of shifting that just mentioned another strategy to collaborate with different stakeholders. Right. But outside of for example product owners, do you have any experience working with marketing teams, for example, or you do. You said you also did data analysis. If I'm not. Yeah, go ahead.
[00:23:57] Speaker B: No, actually I'll go there. But I would like just to point one thing that I think is interesting about uncertainty.
You were saying that you need to understand what is the situation right now. And I think this has been really helpful for me in a way that when I was younger I was a bit control freak, let's say. And I think everything needs to be really structured and predictable. And then everything crashed on me on my first real big experience in a startup where there was no product. So everything came down. I was like, oh my God, this is awful.
I hate it. It was terrifying.
[00:24:36] Speaker A: Yeah, it is.
[00:24:36] Speaker B: I realized that and I forgot the word before. That was creativity. When you say communicate before and then let the creative of each person do the job. But I think as you say, uncertainty and understanding where you are at the moment, it's where you create the clarity in this chaos. And the creativity is where you ought to put the beautiful thing of delivering, of shipping of product, whatever you want to call it. And you don't try to eliminate it uncertainty, you just navigate with it. It's like where are we? Like you say, how is the situation now? How everybody is online, how is going to be the future? We have no idea. But how are the pieces right now? This we believe this is us and always iterate and that's how life should be.
This for me was a big personal experience and I just wanted to talk about this. I don't know, what do you think? And then I can go to marketing. But I really wanted to go on this.
[00:25:31] Speaker A: No, it's a really interesting take because for a riff, a quote. I also say to my teams, I work a lot with quotes, they help me frame is I'm here to maximize your talent.
[00:25:43] Speaker B: As in you say that, you say that.
[00:25:46] Speaker A: Yeah, yeah. Anytime I'm working with a new team of developers and designers and this is specifically to the product team, I tell them my main role is to maximize your talent because I don't know how to to design and I don't know how to develop.
My main role is to guarantee that those people that are experts and very good at their jobs maximize their creativity. Allow them to be as creative as they can on their jobs.
[00:26:12] Speaker B: Yes.
[00:26:15] Speaker A: Is my number one rule, as in I'll try to. And that implies leaving them with clarity, as in making sure that their questions of where to go, what to do are answered in terms of business, in terms of marketing, in terms of requirements and all of that and then ensuring their focus.
Because as a PM we are the generalists. So I believe that we don't need as much focus time as a designer or the developer. While their focus time is precious, developing or designing flows and all of that that takes focus time and focus time for me is you pick up a task, right. Or a project or anything that you have to do and you are allowed to stick to it and enter a flow, flow state of mind for an hour at least. Because that's when you achieve productivity. So a lot of my work, especially when I'm working more with startups, is being the doorman as in my team is working. They know what they are doing. If you need anything from them, you'd call me first. I, I do the shifts, not my team. Right. And that creates tranquility for them because they are focused. They know that if any issue arise, I'll handle it or I'll call them if I need it. But that, that blocks a lot of distractions that come from the, that hustling right from the day to day operations or the questions that come from marketing, from the, from the product owners, from the users, from, from everything that go from all the stakeholders that I funnel them into me so that I can do that collaboration, make sure unblock who I can and leave my team focused and working on, on what they do best on their talents.
[00:27:59] Speaker B: So okay, yeah, similar thinking to be honest. I think we are in agreement. I thought this about this before going here and it comes a little bit back about the collaboration organization like the product owner, all the hyper organization, all the epics, which I never love it but at the same time I like it. It's bipolar. I don't know but this goes to when I was thinking about product management. It really touched a little bit what you said that I want to maximize what you're doing. And I never liked this idea of product owner in a company and I'll go there.
I didn't forget about my experience. But I always feel that if you know some reports of people saying that the product manager is a pain in the ass, is a control freak, whatever, and I hate that at the end of product manager you are your Robin. Let's say everyone is a Batman and you are the Robin of everyone. So you're here to help them and twist them work. And this is good quality PM in my opinion. And this is what makes people do good work, is good be a good Robin.
[00:29:13] Speaker A: Yeah, I absolutely agree. I mean I know I'm working or I did part of my job well and I'm working with a talented team when my main point of contact with them is on Monday where we do the weekly planning right. And then on Friday where we do the demo, the show and tell of the week. That's Usually our process as a visual we, we start the week with the planning and then at the end of the week each person showcases the work that they've been doing. If along the week I don't even have to address my team, that means my job is probably being well done. I'm hustling, handling operations, slack permission, setting up channels, setting up, helping marketing with dancers about the roadmap or about the features or and helping the product owner with the deck and going to probably to business calls just to answer some product questions. And I reach Friday and I go to the show and tell and the team shows what they've been working on and it's awesome. My job here is done as in I go to my team on Mondays, tell them this is the goals, let me know if you need anything. I go to the show and tell on Friday and I show what they've been working on and I have zero hand on it. It's amazing because it means that the team is clear on their goals. They have been having their focus time and the product is growing.
[00:30:40] Speaker B: I wish I had you. In all of my experience, I never was never like you and I never had someone like you.
[00:30:46] Speaker A: Well, I mean this is the philosophy about it but yeah, in theory that's how I prefer to operate.
[00:30:52] Speaker B: It seems a good experience having an Avro in work. I never had it to be honest. And now is a good point to connect because I was always a doer and a connector. I never is somewhere, I mean I connect but I didn't have someone to help me, which I think I learned with trauma. Right now we are a two man team basically. So we work in everything. I'm more like a doer. My teammate Andre is more like, he's the founder, he's more like that's it, the brain of the idea to go outside. But I'm more the hands on in this. But it always started like this and now I'm gonna explain you why I always think about this, about let's say the planning. Like you have the planning weekly planning. In my experience I never had a standard product manager career, I never had that. I started as an engineer, a data scientist in a small startup. I was a third engineer and there was no pm, there was no structure, to be honest, there was nothing. There was just two guys figuring out some computer vision algorithms because we wanted to develop let's say a good analyst for football coaches. So the context is that football teams you have the coach and you have the medical dogs and you have the analysts before each game. They spent hours analyzing videos and clipping and tagging and categorizing to prepare the game. And this is. So the idea was to develop an app, a video organizer, super intelligent that would capture these tactical fundamentals. This is the context and since the beginning I never had enough around my life. I wish that. So I had to really figure out and I love football. So this was a good experience in a certain sense. I had to be a therapist, understand football coaches. I have to translate to developing and this was also the time I wanted certainty and there was a lot of uncertainty. Nobody knew what we're doing. So we started doing some fundamentals. Then we had to develop the app how to adapt. So I had to work and never connect. I work my goal was to capture the football theory into data scientists, AI or software.
And then I have to connect this to business and then to app. I'm generalizing app to front end, back end at the end I had to connect to people areas and create systems and we had this agile cycles but for me it was always being top of everything and maybe put a hand. I need to understand what was doing the front end because my output was there and I need to understand football coaches. So that's why I never had this experience of planning and having an algorithm in my life. And now it's also is we have some structure, we have some notion. We are trying to be as most organized as possible but at the same time we are a bootstrap company and we are only two and we need to shift fast.
We are trying to put a big picture there and trying to document as much as possible. At the same time we are going as fast as hell.
I don't know. That's a little bit. And that's why I'm always in the top of everything like you say marketing and operations. Now I'm trying to. I know I'm ramble but to finalize I'm trying to use AI as much to automate as much as possible stabilizing to maximize as much your creativity as being in developing something called or even sales how to be as most creative to sell something in marketing.
[00:34:31] Speaker A: Yeah.
I mean AI is a blessing. I use it more and more every day. I think it's my default tool nowadays as in I have to search something I go to in my case chatgpt. But there are others right? And. And yeah and it helps a lot especially on. On our roles that we have to do a lot of documentation from time to time. It's a lifesaver. It's a time saver as well. And. Yeah, and I mean, I don't. I understand that this planning and it's the holistic scenario, it's what I strive for. It doesn't always go like that. I mean, it's natural for you to touch points with your team along the week. But I think the heuristics is that one. As in, always bring me problems. As in saying that to my team, always bring me the problems that you're facing and I'll try my best to solve them.
It's not your job to solve problems. Or if it is, it's a waste because they are specialists and they should do what they are best at. And I'm a generalist. And that's why we are there. Right. In the end, you probably are best equipped to handle uncertainty or weird stuff that pops up, like doing a presence.
[00:35:46] Speaker B: I was there sometimes I wish, but then I'm afraid that it's getting boring if I'm not there. So it's like toxic behavior, chaotic.
[00:35:56] Speaker A: It's sad sometimes. And I felt that before. As in you spent the entire week hustling and. And then you go, you see the product being built and it's awesome. And you're like, damn, I wasn't there. But I mean, it's been done.
[00:36:12] Speaker B: I don't want to take organization out. Like I told you, I can be really good organizing. My experience was like control freak, then super uncertainty. Then there is a middle term.
Organization is good, documentation is good, having a big picture is good. But the same as we went before. Question yourself. Ego, empathy, everything's changing. So the organization itself has to be adaptable.
[00:36:40] Speaker A: Yeah.
[00:36:40] Speaker B: To be something.
It's not adapto. That is always changing. No, that is also not good. But it's like it's not strict to how you behave every day. Do you understand?
[00:36:52] Speaker A: Yeah. I mean the processes should work for you, not you having to work to get the processes done.
[00:36:59] Speaker B: Exactly. That's a good thing.
[00:37:00] Speaker A: Yes, because it can easily escalate.
I mean, tickets, having a ticket for everything when it's not needed and then in the end you end up having a version of the ticket in Notion or in JIRA and then another version of the same problem on GitHub or GitLab or whatever and it just spreads out information.
[00:37:22] Speaker B: Are you going to watch that? Are you spending time writing thing and are you going to look at that after?
[00:37:28] Speaker A: Yeah, most people don't. So yeah, what's the point? Right? I mean, yeah, as in I focus a lot on problems. That's Also my personality. If I don't have a problem to solve, I'm stuck. As in I don't know what to do. I need problems. I think that as PMs and I've told this on more tough conversations with product owners or with clients. That is we as in me, the PM and the CEO, the client, the product owner or whatever you want to call it. We carry the problems so we can't dish out the problems to the teams. As in there will always be fires, problems, bugs, whatever. But we if downloading that into the teams then we are not doing a good job because they they have problems that we cannot even foresee or imagine as developers and designers they have. They are facing the design problems and development problems that other people don't have the skill set to lose. So I believe it's unfair or not at least, at very least not productive to bring problems of business or marketing directly to developers and designers. Because it's a focus shift, right. And they'll spend time that they don't have most of the time, most of the projects, hard deadlines or timelines and it's just not productive for the project as an all. So whenever I can minimize that, I do it. As in no, I'll do that presentation at whatever or you want to have a Twitter live talking about the product, I'll go.
We don't need to bother the entire team, right?
[00:39:22] Speaker B: I think it really depends on the size of your company. Let's characteristics of your company. If I'm not wrong, correct me, I'm wrong. So usually it's a bit of agency consultancy. So you have deadlines of projects to deliver for your clients and there is companies that have one product. There is huge companies have a lot of products.
[00:39:43] Speaker A: Yeah, context.
[00:39:45] Speaker B: I I noticed that because in my case I would sell a builders camp. We are only two and the most important here is to move fast. And this is a little bit accordingly to I think this new generation of bootstrap. If people don't know novc money and deliver fast. So you don't have much time unfortunately to explore some things. And I think that's the good thing of big companies that you can have a good organization structure where you can have things that needs to be delivered fast, things need to be explored, things that could be something nice for the next five years, 10 years. And this also goes to strategy and planning for a long term. I think we can go here a long time. But it really depends of who you.
[00:40:40] Speaker A: Are and where are you and adapting as you said.
[00:40:43] Speaker B: Adapting. Yes. And adapting about the situation.
[00:40:45] Speaker A: Yes, context is really important.
I usually fall back into the startup or zero to one context because it's the one I work a lot at sub visual and also the one I enjoy the most. But yeah, I mean if you are working on a huge company with one product that has decades of development on it, you do have to adapt. Yeah. There in that situation, taking the time to properly do a documentation, making sure that you address all the entire teams to get the knowledge of the entire infrastructure is important. Or else it's. It goes back to the same mindset of saving money and time to the specialists. Right. Because what, what you're doing as a product manager is raising the questions and the possible blockers and restraints beforehand so that you have all that knowledge gathered up.
[00:41:40] Speaker B: This is a little bit the lean startup, I would say thinking and I really like it. Like before I didn't like it because like is accepting uncertainty, but it's accept everything at each moment and adapt. Always adapt moving forward. I wish I had time to do that stuff. But you have to. If you are for example in our case a bootstrap company, you. You need money, you need to do revenue. So you need to do an amazing work of probably managing to understand what is good, what people are looking for discovery a lot. And can this translate to business and move fast. You have to move fast. There is a lot of competition and at the end it's like what is more important to have a good notion, organize it or deliver something that would give to you more revenue is deliver something.
You have to choose your own battles.
[00:42:35] Speaker A: Exactly.
[00:42:35] Speaker B: And I think ego applies in your life. You cannot be everywhere. You have choose your battles and a big company can do that. Can do a planning of 10 years you're not there. You can, you cannot behave as a big company because you're not. And if you do, you're being naive and not responsible in a certain sense.
[00:42:56] Speaker A: Yeah. And I agree fully knowing the pains of going fast and the risks as well.
[00:43:03] Speaker B: True.
[00:43:04] Speaker A: And picking up on the communication as in it sets up an expectancy. Even the word itself, as in being fast, which it's not fully accurate. For example, in my opinion, saying going fast, a lot of people see it as doing a lot in a short amount of time. And I think that's wrong in terms of products.
The way to go to go fast doing product is being assertive. As in know exactly where we want to go.
[00:43:29] Speaker B: That's the point.
[00:43:32] Speaker A: Have the questions answered, do not shift. And whatever time it takes, you are going fast. Because you are being lean, right. You're being lightweight. That's the one thing that we have to do to reach product market fit and then generate revenue. It, yeah, it will take X amount of time, sure.
But we know we are certain assertive of that's where we want to go and that's how we will reach revenue at the start.
So yeah, it's not sometimes the extra feature or the UI or the ux. It's all about understanding your job to be done. Right. The pain that you're trying to solve and laser focus on it and, and yeah, and even that takes time. It takes building a team, getting knowledge to that team. Right. Then doing the designs, doing the development. Even with AI nowadays if you are not assertive, you'll just do a lot that's not worthy, not worth it at all.
[00:44:31] Speaker B: So you really need AI is a good, let's say teacher to be assertive.
[00:44:36] Speaker A: Exactly. Yeah, yeah. I mean because.
And I've done some vibe coding, some pet projects and also add some prototyping at some visual. And it's all about focusing, focusing the AI because it loses it. It starts hallucinating and trying to build, build, build while what you want needs to be laser focused and very assertive.
[00:45:01] Speaker B: Solve the problem. Actually, I'm curious because like I told you we have different companies, we are working. Now I would like to ask you a question because we do some plannings from three months a semester of what needs to be achieved and done. But I would say that this is like the mission we have.
Sorry, the vision where we need what we need to achieve in this, it's true the organization day to day is not the best. Like I told you, choose your battles. But in your case, since you are an agency, how do you. I'm curious, how do you deal with creating expectations of someone is paying suvisual? No, how do you manage this expectation of lean but you want to deliver the lean that maybe is good because you don't know and the company doesn't know what's going if it's going to fit or not or at the same time their expectations, they are paying you for something. Now I'm curious, how do you work with that?
[00:46:03] Speaker A: Yeah, no, that's a great question because.
Well, first of all it depends as in if we are on a team augmentation project, as in we have our developers, right. And they basically join an ongoing team on a big company that doesn't involve what you mentioned. Right. Basically with that they have the. The company itself gives the deliverables and all of that. And we are basically just doing team augmentation.
The team, the developers join and follow the company's processes. But from time to time we get a project more 0 to 1, as in, let's build this from scratch.
And we always, because that's part of our culture and going back to what we said before, we take ownership of the problem, as in, which we really try to understand what it's trying to solve. The product itself, make questions, do research together with the client, client, and we get really involved into that process and in part to align expectations. As in, we don't take for granted that the plan that is presented to us will be like, okay, we just execute the plan. No, we think about it, we question, we research with the clients to make sure that if we are on a zero to one project, whatever that one is, we build it. We thought of it together also because a lot of the people, the founders that come to us, they don't necessarily have the product experience. Right? They work with digital companies or they have business background or marketing background. They don't necessarily have the product background. And doing products is a science on their own. Right. The process of doing, the discovery of that frame of thought, it's a skill. So we work with the client itself to come up with what will be the 0 to 1 and the path to get there.
We involve design, we involve our developers, our product managers through that process. And it's really cool. It's one of the best parts for me.
[00:48:14] Speaker B: This reminds me of maybe you experienced that. Is that so going back to what we said, the good part of all is questioning the real what they really want and really question even your solution to that. But sometimes I think what's most difficult, and that's something I learned in my first experience in the football coach digital product, is that people don't even know what they want or what they know. And people don't even know how to express as. You are like psychology. Yes, Psychologist. Sorry. Because you're like, people are like, I want this, but it's like, do you, do you really want this? To you is like why you think like this? I think like this, but because it's green, you should do this. And then you're like, okay, but how do you do this? How do you perceive if some, in my case statics is going on and then at the end it's completely different and you're like, damn.
[00:49:09] Speaker A: Yeah, it's the mom test, right? And user research, the five whys. It's a great topic. And yeah. And it's important because sometimes you need someone to question outside of the creator's influence. As in I had an idea, I thought about it, I built on it and it's all with my assumptions. Right. So having someone that questions those assumptions is actually really healthy for, for the product or the project and not have just a bunch of of yes men's that just say okay, we'll do it and do whatever you say while the chances are you don't have exactly that experience. Right. Or so that discovery and planning the process is part of who we are outside visual. Especially when we are working on a zero to one founder scenario.
[00:49:58] Speaker B: And I believe people hire you to help on that because maybe it would be easier for just doing accepting. But then I think people know that Supervisual is good on the helping them really set the beginning and question themselves.
[00:50:16] Speaker A: Yeah, well, I agree. I hope so.
[00:50:19] Speaker B: At least you are the one who should know.
[00:50:23] Speaker A: No, they do and we do really great products. I'm biased but yeah, I know we do and we had that feedback that working with the founders that we actually help them right in building and going from that zero to one stage which is really hard on a startup.
So yeah, I'm sure if you have anything else you like to say, if not, we'll wrap up the the episode.
[00:50:49] Speaker B: I think something that I'm thinking now to conclude, I think that understanding a lot, the human nature and psychology, it helps you to understand yourself I think is one of the key things to deliver good work on a professional level and personal level. It's something I'm thinking that understanding yourself, human nature, it really is the base of everything we have been talking about expectations, communication, talking uncertainty.
So that's the only thing I think I want to say.
I think we should explore a little bit this personal psychology level of ourselves and as a community and maybe I think this is the basis of quality of life, quality work.
[00:51:44] Speaker A: I agree. And going back to what we discussed, the cornerstone of collaboration is indeed empathy. Right. And being able to understand and understand yourself because in the end you also collaborate with yourself. Right. So yeah, I think it was a great conversation. Thank you very much Tadil and for those of you listening, I hope you enjoyed as well and see you soon.
[00:52:09] Speaker B: Yeah, thank you so much for inviting me again and if anyone wants to connect to me, I know that I always going to do these jobs. See you and thank you so much.
[00:52:19] Speaker A: Thank you everyone. Bye bye. Thank you Tado.
