 Hello. Welcome to our webinar today. Thank you for joining us. My name is Katie Campbell. I am a product manager at the Walt Disney Company, currently working in corporate brand management, working on some of our metadata solutions and reporting solutions as well. Today, we'll be talking about digitizing workflows. And by that, I mean taking workflows that are highly manual or analog in nature and looking for some software or process improvements that we can incorporate as product managers. It is not the cool or glossy side of product management, as our users are often internally facing in this sector of product management. But it is important. It does keep the things moving and going and all the stuff, some things happening. So let's just get into it here today. So a little more about me. I am originally from Baltimore. I say that to let you know that if I'm pronouncing something funny, that is probably why I relocated to the LA area about 11 years ago. I'm a proud parent to a Spinks cat and a Pitski puppy. I tell you that in case they come running through here and you understand what's going on chaos in the blurred background. I have 14 years in digital content management experience. I predate the Apple App Store and also the iPad, if you run the math on that. I've been working in entertainment space for about nine years and five years in software product development. So today's agenda, we're going to go over what a problem statement looks like. I'm sure that you already are aware of that, but what it looks like when assessing internal workflows and finding those efficiencies, how to assess the landscape, estimating your impact, assessing tools and finding the balance between all of those things, which can sometimes be a little challenging. So to start our problem statement, what are we trying to solve with our internal workflows? And to start it is how do we take something that's highly manual and make it more efficient? Are there other manual solutions, which it's not what anyone wants to hear, but is sometimes the solution? Or can we use technology to enhance, supplement, or support some of the work that our teams are doing? So getting to your problem statement, you need to ask the right questions. And this may seem obvious, but I find that running through this exercise with myself and with my stakeholders often helps guide us in the right direction because it's easy to get off track when you have some preconceived notions or assumptions of how things can or should work. So what are we trying to solve? Seems obvious, but sometimes we think we're trying to solve one thing and what we actually should be solving is another. So asking this simple question can help guide you in the right direction. And then are we asking the right questions? If you're not right, asking the right questions, you are not going to be going in the right direction and you're not going to be getting the answers and solutions that you're looking for. Do you have the right people looped in? Are your stakeholders there and present? Are you getting your information from them? Are you collaborating with them? Are you asking them to think about different types of solutions and things that could or could not work? Where are we stuck in our current process? Where are things slowing down? Where are they taking more time than they feel like they should be? And are there process people or technology problems causing those issues? How are we stuck? And then finally, is it a process change or is it a tools enhancement? Often with product, it would seem that, and I guess traditionally, it would be that you're proposing some sort of tooling solution. And ideally, yeah, that's the case. We're talking about getting workflows out of these manual, high touch, super involved processes and getting them more digital. But how do we do that? And do we need to do it with technology? Do we need to find a technical solution? Or can we tweak something over here that allows technology we're already using to work a little better, run smoother, be more efficient? So these are the questions I like to ask. I find it's helpful to run through this exercise. Again, it seems obvious, and it takes a little bit of getting comfortable talking to yourself and allowed if no one's around. But it will help ensure that you are on the right path. It's a temperature check for yourself in a way. So the next step is to assess the landscape. I think we all generally go into a project thinking we have some understanding of how things are and are not working. But you really have to assess it. Figure out where you're going. You need to know where you are. So host a discovery session with your stakeholders. They are your most valuable SMEs. And I think that sometimes as product people and technologists, we can get looped up and thinking, Oh, well, this is the process and the path that makes the most sense. This is the user journey. This is how we're going to do it. But if that doesn't align with your user's workflow, and not only for the task at hand that you are assessing, but their broader workflow, what are their other work streams, and how does this positively or negatively impact that you really need to look at the full picture to understand whether or not the path you're taking is the right one. Include those stakeholders early and often. You need them to collaborate and treat fresh eyes. And an open mind is part of your product uniform. I think we've all gotten into some different kind of looks and feelings while we've been doing this remote work. Maybe your uniform has become more relaxed. You've got a lot of sweatpants going on below the Zoom camera. But when you're going into a project, you always want to be as open as possible. Because if you go in with some preconceived notion of how things need to be done, sometimes you can miss the opportunity to find a creative solution. Workflow mapping. Again, simple but important. Befriend your whiteboard. These are actual pictures of whiteboarding sessions that I have done. And I'm alarmingly going to tell you that these are some of the more simple ones I have done. Several that were much more complex, more boxes, more arrows, more colors. But I like to document everything. I like to document clips. I like to document where there are documents and also identify any red flags. Take that red marker and mark them. If there's a big question mark, put a circle on it or just put a question mark in there. I mean, these are your notes. And as you're going through and figuring out how things really are working today, it's nice to put a pin in things that are giving pause or that you have additional questions about without interrupting the nature of getting your full end to end workflow as it exists today. Because ultimately what we're saying is we have a workflow where there is a lot of high-touch work and there are a lot of semi-technical solutions. We'll say it that way. You may be working with digital copies of documents. But if you are working a lot in documents rather than in tools, something is likely misaligned. So what comes next? We know where we are. We've asked all of our right questions. We have some ideas. We have some things we need to follow up on. How do we estimate our impact? In internal solutions, it can be difficult. I mean, to be frank, it can be a little tricky to quantify and estimate your impact. So how do we do that? You want to quantify where and when possible. Organize. You always want to stay organized as a product person. When you're doing that workflow mapping, bucket your steps and the phases of the overall workflow, where and how you can. See what makes sense for your industry and your project. But getting that organization really does help. Meet with your stakeholders and identify any variations in workflows. If you have a large user base, you may have a group of folks doing it one way, a group of folks doing it a second way, and another group of folks doing it a third way. So understanding where and how those differences exist can really inform the work that you're going to do. Diagram or prototype your proposed updates and concepts. Create those mock-ups and wire frames as needed. Again, depending on your project and the nature of your industry and your work, that may not always be appropriate. But where you can, creating a feeling of address rehearsal, so to speak, will allow you to effectively, maybe not effectively, but at least more accurately estimate the time savings as you're moving into your new workflow. Which moves us into our next step. Estimate. Do a time trial of how the workflow is today. Get some kind of sense of how long it takes. Understand if there are extenuating circumstances or factors that could lengthen or shorten that workflow. And get a good estimate. It doesn't have to be 100%. It can be difficult to do. But have an understanding if there's any flux in that estimate. Assign times to each of those bucketed blocks of your workflow that you previously did. Again, organizing early will help you later. And then log it and do your sum. How much time does it take for each of those steps? And it's one extraordinary longer than another. And then take your prototype, your wire frames, your workflow, and do a time trial. And then figure out what your estimated new amount of time spend is. And then we're going to analyze it. Run the difference. Are you saving a lot of time? Are you comparing your output against your project goals? So if your project goal is to reduce the amount of time spent on this task by 50%, are you hitting that? Are you significantly reducing it? Or is your project goal something less wantifiable? And are you looking to decommission something? Are you looking to get out of spreadsheets? What is your project goal? And are you achieving it via your proposal with your mockups or prototypes and what have you? And then once you're there, revisit and refine. If you're not hitting that project goal, go back to your buckets. And this is where the buckets can really help. Then you are looking at it in manageable pieces. So you can say, okay, here we still have this dependency. And here we're taking this much time. Let's look into this. This is the longest chunk of time. Are there options to optimize what we're doing in this phase of this workflow? Or is it this tool is actually taking a lot of time or it's high touch? Is there a placement for that or something that we can switch around? So you want to revisit, you want to refine. The best plan is the one that has been edited. Going with your first plan may work. You may hit it out of the park on the first try. But it's good to revisit and make refinements as needed. Then, okay, we have our plan. We've estimated. We've bucketed. We've got everything lined up and ready to go. So we know that we have these high touch manual workflows. I've said that a lot of times, but we do. They exist, especially in big companies. And sometimes where you think they wouldn't, in industries, you think they wouldn't. Often in technology, people are still relying on sheet stocks, Excel docs, Google docs, PDFs, things that are not really optimized to linking up your data. They can work for a short time and they do. But they don't work forever depending on how big your scope is. So we got to assess our tools. Unpopular opinion. Excel. Not the enemy. Not the enemy it's made out to be. But it's also not the solution. Excel has been around for a long time. My work does not predate Excel. But Excel has been around for a long time simply because it does work. But if you are getting into data sets that are so big, your sheet's crashing and you're hitting row limits and you have no way to send those documents or share them because the size is simply too big, then you need to be looking into other solutions. But if you're working in a smaller data set and Excel is meeting a need, you don't want to eliminate it just to go replicate Excel in a new software solution if it's not creating the efficiencies you need throughout your workflow. Then, of course, we have third-party applications. Let's go shopping. We know what's out there. Don't always rule it out, but don't make it your only point of view. Don't put stock in capabilities, which is the opposite of how I wrote this bullet. Put stock in your current capabilities as you're talking with these third-party companies rather than their future promises. This is something that I've learned the hard way. So if a company is doing something and you come to them with your use case, you're working with their sales team or their product team, they may tell you we have the solution and we will have it ready in three months. Well, what we know as product managers is that timelines get delayed, mistakes happen, bugs happen, they creep in, they cause all kinds of havoc, and sometimes the output doesn't match what you thought it would be. That's part of the cycle and there may be future iterations that get you there. But if you're expecting a promised solution that is not a proven solution to come in and fix your workflow problems, you may be setting yourself up for failure. You need to assess it and work with your team and work with that team, with the vendor team to figure out and feel out whether or not that's really going to work for you. Stay familiar with the market and its offerings. Get into lists, get into articles in your industry. You know every industry is different, but there are publications and blogs and newspaper sections for most groups. Have a sense of what's going on in your industry and in your space so that you have some familiarity with what solutions exist or what types of solutions exist. You don't want to have to start from square one every time you go out to look for something. And then there's the third thing, maybe what you need is an internal solution. Is it better to build? Custom solutions for custom workflows are sometimes the only path. If you're in a highly specialized area of your industry or in a highly specialized industry, it's unlikely, not impossible, but unlikely that you'll find a software solution that's already built that does what you needed to. However, you should strive for solid foundations with the possibility to add enhancements that are extensible. If you build your foundation too narrow, you're not going to be able to build up enough. That is simple geometry. Your project is going to fall over. So if you're looking at internal build solutions, make sure you're really thinking long term. You don't have to plan end to end from start to five years later, but have some sense of where you may be going. And you might be wrong, but give it a stab so that you know what you're looking at and you know as you're starting to plan the foundation of your project or your software solution, whether or not it's going to allow you to expand in the future. And remember, things change. Stay agile. Consider phase approaches with committed timelines. When you have a committed timeline, you're able to say, okay, we are on track for this phase. And when you don't, you could just be rolling forever. And when you get into that rolling project format, which does work again in certain scenarios, when you get into that kind of process, what can happen is that your project can roll on for so long that the other dependencies and departments and other users start to change. And they may be changing as a direct result of there being no solution for the solution you're put or for the problem that you're pursuing with your solution, or it could just be the industry changes or there's a need in another group that wasn't there before. So if things will change, that is, that is a guarantee. Things will change. And finally, finding the balance between all of those things. Do you need a stop gap or do you need a long term solution? Here are the questions that I like to ask myself and my team when I'm assessing the difference. What is the ideal end state? Where are we going and where do we want to be going? Is this workflow temporary? Is there something that we estimate coming in the next three, six, nine months that would make this workflow vastly different or obsolete? What changes could lead to decommissioning this workflow? Are there things coming trends and trends in the industry? Things that are happening from a business or corporate level? Are there consolidations? Are there expansions? What is the climate like? Figuring out who benefits from this change. Sometimes it's not just your immediate user doing the work, but who is the recipient of the output of your system and your proposed solution. And finally, is the impact worth the resource spend? It's important to ask this question. Again, it's one of those that seems obvious, but sometimes it doesn't get asked. And if your resource spend in either time or money is really significant and doesn't line up with the impact, it may be time to go back a few steps and determine if whether or not the solution you're proposing is really worth the effort. So in summary, and I think these things are obvious by the number of times I've repeated them. Question everything. Answer as much as you can. Document, document, document, document, and quantify. And finally trust your gut. There are certain things that come with experience. If something feels like it's the right path, even though it's not looking so great, that's all comes down to prioritization with your team and discussing with your vendors or your engineers or what have you. If you feel like at the end of the day there's a reason this workflow is more analog and high-touch, then maybe there is a reason for that. And maybe there are other areas of your department or of the work that the broader group is doing that you can optimize and solve with software solutions. So I hope that has given you some insight into how we do things on the other side of companies. Back where nobody really sees what we're doing. And if you have any questions, feel free to find me. Feel free to reach out and I'm happy to answer them in whatever way I can. Thanks again for joining our webinar. I hope that you found this information useful and good luck with your career.