Roles and Responsibilities In Building Technology

How are roles and responsibilities tied to making quality product decisions? Well, today I'm going to talk about that and I'm so excited to talk about it because it's one of those things that we all take for granted. We know that there's different disciplines, we know that there's different roles, we know that there's different things and needs of all of our teammates. But do we understand and are we open minded to the fact that there's going to be crossover, there's going to be complications, there's going to be things that get in our way. But today I want to show you how to think about it in a way that's a little bit more open, a little bit more transparent and something that you can do as a product designer, as an engineer, as a creative person working on projects with other people to really understand these disciplines. So let's just dive right in. So right now I have FIGMA open and what I want to do first, first is talk about roles and responsibilities. So the roles, the things that you have on your team to be able to accomplish the overall outcome or the goal, right? Teams like sports teams have their different positions, design teams have their different positions, organizations and businesses have their different positions and roles. And then we also have the responsibilities like the things that need to get done in order to get, get closer to the outcome. But the challenge here is there's a lot of bleed over between different roles. And it can be quite a bit of a challenge when you're first starting out and you got to do a lot of things. But let's just dive right into this. So the first thing that I want to draw your attention to is the business needs. So whenever it comes down to anything, you got to really understand that the business that you're working with, the business has needs. It doesn't always like mean that just because you're a product designer, just because you're an engineer or just because you're, whoever you are in your role, you still gotta be mindful of what the business actually needs to work, what it needs to function, what it needs to develop. There really isn't a gray, a gray area around this. Like you just have to know how the business, what the business needs. And oftentimes the business or the product manager is usually the person who has this information. But it can be crossover, like I was saying before. So the second thing that we want to be open minded about perspectives. You're going to have a lot of people and a lot of different roles in your team. It's really important to understand which perspectives and the perspectives that you need to hear from your overall team. Now I'll go into the different roles here in a second. Perspectives is a really important thing. You know, thinking about it, who am I working with and what perspectives do they have? What history do they have from their old companies? And also what are the. What are the understanding of what. What their perspective is today? The third one is who's doing what and what are their swim lanes. The other reason why we have roles and responsibilities is because if we're all working on the same thing, then there's a lot of crossover and a lot of duplicate efforts, a lot of duplicate work. And there's also, you know, there's certain people that are responsible for something which we're getting closer to that responsibilities on the far right side here. But you got to understand who's doing what and what are their swim lanes. You know, you don't want to product and design and engineering all doing the same thing, but you can have leads and have them be working towards the same thing. But it can get pretty complicated if they're all thinking that they're doing the same thing. And then the last one here is, what are we executing and what does success look like? So even though you have all the roles and responsibilities, but you still want to know, like, what are we actually executing? Because once you get to the idea of what needs to be executed, whether it's the design, whether it's the product requirements doc, whether it's the plan to get there, whether it's the actual code that you're gonna have to write in order for it to work. Right. We're starting to already think about, okay, well, a designer wouldn't be writing code. Maybe not. A product manager probably wouldn't be moving things around in figma, but they could be. And an engineer is probably not going to be designing in figma, but they could be. And there's a lot of different, you know, crossovers, like I was saying. But it's really important to know those roles and responsibilities. All right, so the essentials, you understand the roles and the responsibilities the business needs, the perspectives, who is doing what and where, they're swim lanes and who is executing what. What does the success look like for that area? So now what I want to do is dive into these roles. Now, the roles are important because understanding the roles around you and the people around you is going to help you actually not duplicate work. You're duplicating work. It causes frustration. If you're causing frustration Then the team cannot get in harmony. And the whole goal is to be in harmony. So we're going to talk about harmony in a second. So the first thing that we're going to do is we have product. Product is like the business delivers needs, the product team helps execute those needs. And we have design. Design is helping you understand what and why we're building. So you might hear a business problem and design would go help figure out like well why is that a problem and what are we going to design to solve this that problem. And product and design in this, in this case will be crossing over and cross pollinating quite a bit. We have engineering, okay, so now the engineering is thinking about well how are we going to make this work, how are we going to scale this operation, how are we going to make this work continuously in flow and just be something that works really well for the customer. And then there's business. Business is giving us needs. They're talking about revenue, they're talking about things that are working and things that aren't working. You're hearing from customer success, you're hearing from marketing, you're hearing from sales, like what is actually working in the business. And then that's going to funnel into what we have in the middle, which is the experience. So if I zoom in just a tad bit here and let me bring this little chart over and I'm going to put it over top of these elements. So I want you to think for a second inside this experience. You have your product needs, you have your design needs, business needs. And oftentimes we're jumping around from each one of these elements. We're jumping around and then we're coming in and helping engineering and then engineering is jumping over and helping product. Product is jumping over and helping business. Business is coming in and helping probably product and design. And there's a lot of cross pollination that's happening. But the key is if you understand your roles and your respons, it allows you to work in more of more of like a figure eight or more of a harmony and a more of a symphony type of experience. If product is making engineering decisions, then engineering might be a little fragmented. If design is making all the product decisions, then that's going to be challenging for a product to do what they need to do. And if business is making decisions around experience but doesn't really understand the design or the UX and the reason why they're making these choices, then that's also going to be sort of a challenging action. So I want you to think about when you're going in to product, design, engineering and business, what are your roles and what are your responsibilities? Inside of this diagram you're going to have a little bit of overlap and that's okay. But really getting clear on what needs to be done and why it needs to be done and then going in and focusing on that, that is ultimately what we're trying to do. So if I come over here to my role D diagram and what I'm going to do is I'm just going to remove. Here we go. So we have our product. So the first thing that we need to think about is what are the responsibilities of product? Well, responsibilities of product are making sure that we're working on the right thing. They're making sure that we have the right priorities, they're making sure we have the right elements needed in order for design and engineering to actually do what they need to do. And we're making sure that we actually have budget and work capabilities to actually make this happen. The second thing is we need product perspectives. We need a voice in the team to make sure we are on the right path. And that means tapping into the needs of the business, tapping into the needs of the design team, tapping into the needs of the engineering and the cross team. So product really needs to understand how everything is working inside business because the business is a product, the business is an ecosystem. And we need to understand how all that works. Their other responsibility or their other need or their other perspective that they have is about collaboration. And thinking about how they collaborate with all these other roles in these other roles is incredibly important. So collaboration is another huge thing that they need to be a part of. The next one is communication. Which things are product communicating about the updates, the product releases, the things that are coming out, the things that are up next, the priorities that are in your wheelhouse, those are all really important things to be considering. And then the last one is execution. How is product executing? So this could be like what is happening inside of a Sprint? What is happening inside of a whole quarter? What is happening inside of a whole year? What does the execution look like across the entire paradigm and how are they really optimizing it? Alright, let's go to the next one. All right, then we have the design discipline. The design discipline is about what are we building, right? Where are the wireframes, where are the UX maps, where are the FIGMA files? How are they organized? How do people know to go into the Figma files? How do they need to, how do they know how to give feedback around those things, what are all the design responsibilities? Super important to know then designers have perspectives too. They really care about the user experience, they really care about making it easier and more effective and more functional. And they also really care about solving the needs and serving and solving the problems of the business. This is another really important thing that is, it's also a fun thing for designers because they want to add their perspectives. But oftentimes a product and design perspective could clash here, where a designer thinks that a design should be executed and implemented and a product manager is thinking that it shouldn't be, or they don't want to implement that full scope right now. And that's when you have to compromise, you have to collaborate, you have to communicate like these other elements that we have right here. And this is where you start to learn about trade offs and about design trade offs and understanding. Well, if we can't do it now, can we do it in a couple months from now? And if we can't do it in a couple of months from now, is it even worth doing? And having those sorts of debates and collaborations between design and product is an incredible thing to have at your fingertips because design is still trying to serve and make sure that they're working on the right thing and that they're bringing in as much value as they possibly can. But all that comes back down to this execution. So if you can execute quickly, swiftly and in harmony with your team. And like here, I'll just zoom out a little bit so you can see this other side as well. When you're working in tandem with a product manager and a product designer, these two worlds are often really coming back and forth together. Like when we come in here and we're connecting, these sorts of windows are happening so much. And when we're coming in, it's really important to not cross the boundaries, but it is important to talk, to collaborate, to share these things, Collaborate, come back, communicate, execute. And learning about how the product manager likes to execute, and learning about how the designer likes to execute. And then if you're in a management position, you would be looking at these things from a 10,000 foot view and looking at how your individual contributors are literally contributing. Then we have engineering. And engineering is an incredible, incredible important area which what are engineering's responsibilities? Making sure that they understand the design and the product requirements. This is important because you want to make sure that you're building the right thing. Now if you have an engineering founder, they might be doing a part of the product role, they might even be doing a Little bit of the designer role. But as you grow and as you scale, you're going to have multiple engineers that you're going to need. They're going to need to know what their responsibilities are. And oftentimes like, okay, we need uptime, we need to make sure the product can load, we need to make sure the product is functioning even at the highest peak of an experience. We just need to understand that engineers are there to help build, they're there to help make it incredible. So having the ability for these three disciplines to have shared responsibilities, but also their own responsibilities gives them the needs that they have. And then the perspective. You need the engineering perspective. Because they could also say like, oh, if we do this change, it could save us three to four weeks of engineering costs. Really important, because that could be tens, twenties and thirty, that could be $100,000 depending on the size of your team. Then you have the collaboration. Well, okay, well, now that product and designer are working through things, how are they collaborating with engineers to make sure that their voice is heard, to make sure that engineering perspectives are given, to make sure that their responsibilities are respected. And how can you do that at scale? Then there's the communication, right? What communication, windows, triggers and experiences can you build in to your discipline? As a designer and creator and as a maker, we need to be able to understand these things over time. Because depending on your size of your team and depending on knowing what roles and responsibilities you have in your organization, communication is still going to be something that we're all doing and then you're going to see it again. Execution. And the same thing goes as you open the window and you start to bridge the gap between these different disciplines, you start to see all the different connection points that you have between these three pillars, product design and engineering. And then as we go in to the most important one, which is hearing the business perspective, understanding what the responsibility of the business is, running the company so that everybody above the product, design, engineering can even have a role, can even have a job, can even have something that they're working on together. So their responsibility is to keep the business up, to keep the business making them effective, but also really supporting what the overall goal and mission is envision is of the company. And that's why it's so important to hear the business perspective. For anything that you're building and anything that you're trying to create and not assume that you just know what it is that the business needs. You got to really understand and have a connection point between these disciplines. And that's why product is so close typically to business. Because business is giving product typically high level requirements, high level vision. And then the product team and the design team go, and they go, go to work together. And then they integrate engineering into that window. Collaboration, how are you collaborating with business, how are you communicating with business and how are you executing with business? So business understands. And then we start to see even more connection between all of these elements. And then you start to see at a high level, we have a lot of focus that we need to do as a unit, as a team. Now inside of this team, you might have multiple designers, you might have, or you might have more product, like two product managers, you might have six designers, and you could have more like, you know, like 24 engineers. And then in business you might have your core leaders and executives that you have to work with. And it's so key. Let me just move these a little bit closer so you can get this visual. Because we start to think about, we have a lot of people that we really need to unify. And when you know what the roles and the responsibilities are for all these individuals, then you can really help them feel supported. You can really help them be aligned. And this is why roles and responsibilities is so important. Because all of these teams have swim lanes. And if we think about those swim lanes now that we have all of these different individuals in product design, engineering and business, when we talk about those swim lanes, there might be projects. You have projects. Sorry, projects. You have goals, you have opportunities, and you have like, let's see here, Projects, goals, opportunities. And each one of these things, the product is driving those things. And then you have runways and you have roadmaps and you have quarters where you're working and breaking down each of these important projects with goals. And then you find opportunities. And then of course, you have outcomes. That was the one I was missing here. And then you have these projects, goals, opportunities and outcomes. And as you have these different projects, goals, opportunities, outcomes, these get trickled down to all the team members. And as these get trickled down to the team members, that's why it's so important to have clear rituals and routines and norms for your organization so that they can all function really well together. So I know this starts to get super complex, but this is why collaboration and roles and responsibilities and communication and having perspectives and having the responsibilities of your team so that you can execute better is so key and so important. So today, when I want you to come back to it and I want you to think about how do you operate and where do you sit inside your organization and what can you do to better understand the roles, the responsibilities and how you participate in that overall life cycle of your project? You know, from zero to one, from project to project, from quarter to quarter, from day to day, what are you doing to set yourself up for success with your team so that you can hear these different perspectives and you know, like, okay, who's making the decision? Probably product manager who's working on how to make it work, engineering, who's helping with the flow in designing the overall user experience. And user experience does cross a lot of, a lot of boundaries, right? With service design, where you're thinking about like the end to end flow from an onboarding experience with a customer all the way to when they're first touching the experience and the product, like the app or the website. And then absolutely, as they renew and as they upgrade and as they go through that, that's the user experience, Right? But everybody is, everybody's responsible for the user experience. But design is responsible for the actual execution of that design experience. Engineering's responsible for the execution of how it gets built and the speed and the execution of the thing and product is helping make sure that the vision is executed and the product is coming together. So I hope this was helpful and I want to encourage you if you have questions, if you have comments, if you want to understand more about this or figure out where you fit into this big giant puzzle, then I'd love to chat more with you. You can visit NextLevel UX me to learn more about Next Level UX, which is my coaching and development program for makers, creators, designers where I teach a lot of these things. And then also I want to encourage you to like and subscribe if you haven't yet done that. And then also check out some of the other videos and other content, content about a lot of this, this sort of content for high performance coaching and high performance design and product coaching. I hope you enjoyed this and I will see you in the next one. All right, see you, Sam.