Basic understanding of Product and Design Operations

So you have teams, you have people, you have designs, you have product engineering specs, you have activity diagrams, you have workflow maps. You have all these things that make your product function or be understood or loved. But how do you understand this when you're first getting into design or into product? I'm gonna help you right now, and we're gonna break down what it looks like to set up your team, set up your products, and set up your operations as a creative. And let's just have some fun with this. So without further ado, let's go. So the first thing I wanna draw your attention to is what we're gonna be talking today is just about product and design operations. Like nothing fancy. We're just getting right into it. Now, I wanna first start with just the people. Now, the people inside of your team. You might have a team of, say, you know, you could have a team of 50 people. You could have a team of 10,000 people. And the key here is knowing who's in your team and what do they do and what are their responsibilities and how do they work. And I think it's really important when you first join a company to really understand the people side, because you could have a really big team, you could have a really small team, but it's not good to just assume that you have a certain amount of people doing a certain amount of things. It's really important just to ask and understand how many people you have in your team. Now, if you're a designer, then you can start just understanding how many designers are in your team, and then you want to branch out a little bit further. Further. Now, after you understand your core team that you're joining, then you want to understand how many teams overall there are in the organization. So there could be a blue team, a red team, a yellow team, a purple team, and all of these teams have certain responsibilities inside of the organization. And I'll also show what that looks like. But the first steps that we need to do, we need to understand the people, and then we need to understand the teams. Then what we want to do is start to understand the products and services that are supported by those people and by those teams, right? So the first thing to do would be to think about, okay, from, you know, in this product, let's just say there are. Let's just say there's 10 products inside of your company, and inside your company, you have 10 products. And these are the top 10 things that the company sells, the company works on, the company provides. So what you need to do is Think about which one are you responsible for and then how are they connected to the other ones. So I know 10 products is quite a bit, but more products and services and more companies are getting more expansive and their ecosystems are getting bigger. So it's okay to start mapping these things out slowly and then you can work your way up to understanding the entire organization. For example, LinkedIn, Lynda.com, facebook, they have a good solid, like you know, eight to nine to 10 different organizations and things that they're serving now. Each one of those has like team A, team B, team C. And then those teams are assigned to those products and then you have leadership and management and you know, a whole nother realm of support around these certain products and teams. So this is one way to look at it. Then inside of each of those teams, you have the business goals, you have the players on the team, you have the product specs that actually tell people how it works, what it does and how it functions. And then you also have these, what we call confluence docs, which are ways for you to transfer information. It doesn't have to be in the JIRA confluence, but it can be in notion, it could be in figma, it could be pretty much anything you want. So this is a way for you to share knowledge with the team. The Storybook is basically a way for you to tie your designs and stories from design system back into a product. Figma is the design tool that most teams are using these days because it is a universal tool. It's PC and Mac supported and it also helps allow multiple people to work together at the same time. And then you have decks and stories to be able to tell the stories of what you're doing. And decks are kind of like keynotes. And keynotes are essentially presentations, alright? And then you have the project level amount of work for these. And then you have these typically linked to tickets. And linked to tickets just mean like inside of this document you need a link from your designs to the information of the logic of how it works. And then that's how people can understand how to break it down. So let's dive into what a breakdown actually is. All right, so here's a breakdown. So the breakdown today is talking about Product one. Now let's just say Product one is a made up name. You don't have to know exactly what the name of the product is, this is just for demonstration purposes, but you got to know the name of the product, what it does, the number of projects needed to accomplish the product. Right? So there's typically, maybe for the MVP of this product, you might have like 10 or so projects that are going to take you to get to the finalized version of this one. Typically that could be like an mvp. It could be a version one, version two, version three, version four. And this helps you understand, well, what is it going to take to actually execute the vision of this project? And I say projects because, you know, you just got to know that these things take time. It could be a year, it could be two year, it could be three year, could be four year, five year. And when you have those time frames, you just know that, okay, we're gonna have a lot of projects and we're gonna work towards them every quarter, every month, every day, we're gonna get these things knocked out. Then we need to know the number of people available to actually support this and build this. So this is important because if you have investment, then you can hire more people to execute the these projects faster. Or if it's just like one or two people, that's fine too. Then you just need to know that that's how many people you have. And then you have to change your strategy for how you're building it. You might build a little bit faster, you might try to build a little quicker, but if you have more people, more experience, then you might go a little bit bigger up front. It just depends on what your needs are. So then there's like, if not now, when? Well, if we're not going to do all this stuff now, when would we do it? And then you do scaffolding and you understand how to break down things and keep going. So that's breaking down a product. If you're not going to do it now, when are you going to do it? What's the name of it, how many projects needed. And you know, just thinking high level about these things, right? We're talking about product and design operations. Now what I want to do is move down to the breakdown of a project. Now projects are great because they could be super small. They could be a day project, they could be a week project, could be a month project. To be your project, they could be, you know, two sprints. Two, two sprints would be, in an engineering terms, it could be two weeks is one sprint. So you might have two sprints. And it's completely up to your project management, product manager and your team. So here you want to name the project, you want to understand when it's due, you want to understand the business goals of why you even need that project, what's it going to do, what's it going to serve? What problems are you trying to solve? Then you want to come in and understand your design and engineering limitations. So how many people do you have? What are the skill sets? What are you trying to build? Do you need to do some learning? Do you need to do some prototyping and developing? You just need the context of the project. And the same thing goes for creating Confluence Docs and understanding how you can transfer knowledge and information. You have storybooks, so this is basically your design system inventory. So you know what you're building and how you can move really fast. You have your Figma diagrams, you have your decks keynotes, and then we go to breaking down a story. So a project has a series of stories that make up how it works. So if you designed a product and that product has a series of things that are going to make it work right, those would be projects. And then inside those projects you have a plethora of stories. And these stories are usually written in ways where they're like primary user stories. Like as a, as a user, I need to do X so that I can do Y, or I need to solve or I need to be able to do this because I cannot. And that would be considered a bug. But you get the idea. Now number two is we need to figure out where this story fits into the journey. So we're going to need some journey mapping. We're going to need to understand how it works and what's the flow from A to Z. We need to see how it feels, how it behaves when you interact with it, and of course, how it drives impact. Now you need to know how it drives impact, because if you just build things that don't actually help the user or help the business or help the company or help the team, then it's wasted time, opportunity and money. Time, opportunities and money. We don't want to waste those things. So we have our team that's going to be breaking down these user stories and building what I would call logic maps, key journal or journey maps, workflow maps. They're going to be creating like product one sheets and product PRDs, which is product requirement documents that break down all the things that we're building and why. We're going to have a confluence where people can go and understand how it's built. We're going to have engineering documentation, understand what systems and components we're going to be using. We're going to have Figma files that break down the pages of the design and the different components and how it all works. And then we're going to have keynotes that talk about what we built and what we designed so we can actually sell it and talk about it and make sure it's cohesive. Cool. So with all these things, right, Breaking down stories, breaking down projects, breaking down products, breaking down the team involved and how it works, and of course, breaking down the people and understanding your overall people inside your organization. This is really important to just understand. And this is what I would call mapping to learn. And I want you to understand that when you set up your companies and when you set up the structure of your companies and teams and projects, it's okay, it's okay to break these things down visually so that you can take a step back and look at an aerial view of everything that you're working on and everything that you're dealing with. That way it's completely, it's organized, it's confined. And you know how you want to approach it long term, right? These are just ways to help you understand what you're doing, why you're doing it, and what you're going to need to be set up for success. So I hope you enjoyed this. I hope you enjoyed this quick tutorial on just like team operations and product and design operations. There's so much to dive into deep in here. But if you enjoyed this video, then please like and subscribe down below. We're going to do a lot more of these types of trainings and just to be able to help you understand how to get more awareness and understanding of product and design operations, what it takes to set you up for success. And this one today was just really all about helping you understand where you're at when you're jumping into a team, right? You got to understand the people, you got to understand the teams, you got to understand the products it serves, right? The people and the products serve the business. So you got to understand those things. You gotta understand what it takes to organize all the information that's gonna make that business work. Then you gotta understand how to break down products, projects and the stories that are gonna make this thing work, right? And then the beauty of user experience, design and product design and development is you're gonna be able to iterate, test and build those things over time. And you know, when you're first starting out, it's gonna be really messy, it's gonna be kind of unorganized. But the goal is to get it organized week over week over week over week so that you can build your product up. And that takes time and it's fun though, and it is a very magical thing to see it come up. So I hope you enjoyed this video and you know, that's it. I'll see you next one. Alright, later.