 Welcome, everybody. My name is Ryan Durfee. I'm going to be talking about how to scale your product management effectiveness using knowledge management. And before I begin, I'd like to say a quick thank you to the product school for giving me the opportunity to present on the topic on which I am very passionate. A little bit of background on me. I am currently a senior technical product manager with AWS working in the marketing and analytics space. Before that, I spent a number of years with Comcast Technology Solutions as a product manager working in the media and video delivery space. And prior to that, I ran a network operation center for the CDN network for level three communications. My LinkedIn profiles on the slide. And I'll also mention a disclaimer. The views expressed here are my own and do not reflect those of my current or previous employers. So let's dive in and talk a little bit about product management. The first thing I would point out is that the thing that makes product management such an interesting profession is how many areas of the business that it touches from legal and regulatory to finance and budget to engineering and development, customer experience, sales and marketing. I can't think of one major portion of the business that product management doesn't touch. Now, the upside to that is that the profession is very exciting and interesting. You never run out of things to learn or different things to get involved with. The challenge to that is the sheer volume of information you have to manage as a product manager to be effective in your role. You have to know a little bit about each element of the business and be able to talk about it intelligently and retain it over time. Being a product manager can prove to be additionally complex and due to a number of additional factors. If you think about organizational size, when I've worked in smaller organizations, I've worn multiple hats where I've had to fill different roles. That adds to the workload of the product manager. If you are managing multiple product lines, that can also add a lot of challenge as well as managing a small team of product managers to help with certain products. And then there's always the side projects you get into either for your organization or personal passion projects or personal development. Those can all add to the knowledge load that you carry as a product manager. With that said, I'm going to ask you to do a little thought experiment with me and try to quantify what your current knowledge load is. We'll think of that in terms of some tangible things. I ran a little thought exercise for myself and I thought about the last six months, how many people have I interacted with in terms of contacts? How many links and documents have I interacted with in terms of learning my business or working on projects that I'm involved with? How many day-to-day tasks have I completed? How many meetings have I participated in? And I was a little shocked when the numbers showed up. I worked with 150 different people in the last six months. I've worked on 200-plus documents. I've executed 350 day-to-day tasks and been involved in 200-plus meetings. That is a staggering amount of personal information to manage from day-to-day in a fairly short amount of time. And you can imagine how that scales over a number of years or even a decade of product management. So the next thing I want to ask is that you consider your current scalability. With where you are today, could you take on another product line? Could you maybe start managing a small team or add a team member? And do you still have time to do personal development projects or passion projects? And that sentiment leads me into why we're here today. So thinking about how do we scale ourselves from a knowledge management perspective? Onscreen is one of my favorite quotes. Bill Gates stated, how you gather, manage, and use information will determine whether you win or lose. Now, the drama of winning or losing at a corporate scale aside, I would paraphrase this statement for product managers into how you gather, manage, and use your personal knowledge will determine both your effectiveness and scalability as a product manager. I've found this to be true in just about every role I've done for a company, and especially true for the product management role. So now let's think about how we manage our day-to-day knowledge. I drew a little sketch. This is kind of the default knowledge model that most of us use coming into a company. And it's a traditional hub-and-spoke model. You're basically the hub, and you interact with a bunch of different software applications and documents to store your day-to-day knowledge. You probably have multiple applications for contacts. You probably have a bunch of links in your browser. You probably have a bunch of documents and share points or a folder file system per task. A lot of people are using specialized apps or JIRAs. You might have them in a spreadsheet. And then notes can be all over the place from documents to specialized applications. And I'll ask you to think about a couple of specific examples and how well this particular system scales. I'm often reminded when a LinkedIn contact pops up on my screen as a notification, and I don't recognize that contact. And I pull up my LinkedIn system and I have 1,000 contacts in there. And I can't remember where I got half of these contacts. I don't remember what contacts they were in. I don't remember when I made contact with them. But that gives you some idea of the challenge of managing information over time. Another way to think about this is when a new team member joins your team and you're tasked with getting them caught up on your current projects. Think about all the systems you'd have to go into to get them appropriately caught up. How would you get them all their documents? How would you get them links to all the key systems they need access to? How would you inform them of the timeline or history of your product? How would you familiarize them with time? How would you familiarize them with the different people that you're interacting with or that you've interacted with over time? And as you can see, it's quite challenging when you think about all the different applications and discrete pieces of information that you have to share from a personal knowledge perspective. So now let's think about the challenges of this hub and spoke type model. And the first challenge I would point out is that the tools we're using to manage our day-to-day knowledge, they're separate. They don't communicate with each other, the data within them, it's difficult to relate it to one another. If you ever have to collate or report on it or share your knowledge, you're left digging into multiple documents, multiple systems, which are spread all over the place. The second major challenge that I see with this traditional knowledge model is scalability. With you sitting as the hub, it becomes an exercise in how many connections can you remember between all of your personal pieces of information? And how long can you maintain that memory? I personally find that my RAM memory is pretty limited. I do have longer term memory, but I often need cues to jog that memory. So my own personal scalability is very limited in this respect is over time, just like the LinkedIn example, you acquire this knowledge or these contacts or these documents, and it becomes challenging to maintain all of that in your readily accessible memory. So now I want to introduce a couple of concepts that have really helped me to scale my own personal knowledge management over the years beyond the standard model. The first idea is that it's a lot easier to manage knowledge if you can consolidate it in one location. Bringing it all together in a single system just makes for easier scalability. And the other idea I'm going to introduce is the idea that you can categorize and relate all of your knowledge to one another. And this helps with contacts and relationships and remembering information over time. So the first concept, consolidating knowledge. I've tried this a number of ways over the years. I've tried taking copious amounts of notes and documents. I've tried various applications. But at the end of the day, the thing that I've learned is that if I can tabularize my data, things like documents that I'm working on, links to different resources, applications, my contacts, my tasks, my meeting notes, key decisions that have been made in my product, if I can put that all into tables in a single application, it becomes significantly easier to work with. So putting it in a single application, structuring it into discrete records, columns, validating your data, all the things that kind of go along with data management. And then you also get the advantage of being able to time stamp data as it comes into your single application. So you can get a time stamped record over time that helps you also structure your knowledge. The second concept is the benefits related to categorizing and relating your data. So your categories are essentially your memory key to finding information and relating it. And categories or taxonomy could be different projects you're working on, different product lines, different teams, job functions, administrative functions. All your work and all your personal knowledge can be broken down into groups of these, and that can tie into things like meeting notes and contacts and tasks and documents and links. And these knowledge relationships, they go every which way across the model. So meeting notes can be related to a certain project you're working on, can be related to certain contacts that were in that meeting. Tasks you're working on can be related to documents that either are an output of that task or an input to that task. And it can also be related to different contacts that you're working on tasks with or for. Documents are often related to projects and various contacts from where they came. So if we bring these two concepts together, what do we achieve? We move from our original hub and spoke type knowledge model to more of a point-to-point network. And what I'm describing here, if we combine this idea that we're bringing together our knowledge in a single application and then we're relating it, we're effectively building a knowledge management database. Now, I'm not suggesting that you have to use a database application, but that's effectively what I'm suggesting you create here. And this solves two of our original problems. First, you're no longer the hub in the model. You're no longer responsible for remembering all the connections. The connections are actually documented inside the model. And your model is now time-stamped because as you enter data into your system, it's all been tabulated and stamped. So you're no longer sitting at the center having to remember years and years of information and how everything links to one another. And the other problem we're addressing is the fact that our traditional knowledge management applications don't relate to one another. They don't communicate with one another. So with all of your knowledge in a single model, you can now do things like search and filter and collate all your knowledge in one place. So the overall benefits of switching from a traditional knowledge management model to a model more like this, you get scalability. You're no longer the hub. You have lifespan. This model can live on forever, regardless of how good your day-to-day memory is. It's built on taxonomy and relations. That means all of your personal knowledge is connected to the rest of your knowledge through categories, through relationships. You can filter, sort, and search on the entire knowledge base, which means you can pull information. You can pull every note you've ever taken on a particular product. You can have every contact that you've ever worked with on a particular project. You can collate all that data and report on it and hand it over to other people and share it. And then you also get the chronology, the timestamps element of it, so that you can filter down to certain time periods or understand when you learn a piece of information. So let's assume for a moment that I'm a better salesperson than I really am, and I've convinced you that you want to explore this idea as far as how to manage your knowledge. I've experimented over probably a decade with some of these concepts. I've tried spreadsheets. I've tried hybrid spreadsheet applications. I've tried true databases. There's pros and cons to them all. I would say if you go down this route or want to experiment in this area, start out with ease of use. I would definitely recommend you start in a spreadsheet application. It just makes for much easier data input. A lot of the modern spreadsheets are cloud-based, highly redundant, which they didn't use to be. You can create basic relationships between data. I would definitely say that a true database is overly complex and the user interfaces to those are really problematic if you're just getting started. There are some newer hybrid tools that are sort of in between a spreadsheet and a database, which you can potentially use. I would get your data into a single application first into a spreadsheet and then explore porting that data into more advanced applications that you can play with. So once you've selected a tool, the next step is kind of building out a basic set of tables. The things I've found that are obviously shared across every job discipline, you're going to have a table of categories. These are your projects or products, lines that you're working on. These are your administrative functions and different platforms that you need to gather data on. You're also going to have contacts, documents, I store links to all my documents and links to all my different applications in a documents table. And then you're going to have day-to-day tasks. I also build out a status table that relates back to my tasks. But the idea here is to get started, you're going to build a basic set of tables and then you're going to start working on your habit forming because it is a process to go from putting all your information into your standard applications to moving over to a new system. And if you're going to do it right, you really need to try as much as you can to abandon duplicate copies of data because the data entry in managing your knowledge this way, it does take quite a bit of effort. And if you're putting stuff in two different places, you're never going to maintain the habit piece. You can still store information in other places I still use a handful of browser bookmarks just for speed. But for the most part, all my major links to documents applications I store in my knowledge base. And then there's going to be mandatory systems that you have to use like ticketing. You're still going to use those, but to the extent possible, you want to keep all of your knowledge in one place. The next key to going this route is creating a taxonomy or categorization system. And there's kind of a few things I've learned over the years. Building a first and second layer to your taxonomy is incredibly helpful. Going much beyond that is, it gets wasteful really quickly. And I've found that I don't really use more than two layers. If it goes down to a third layer, it becomes overly complex. Taxonomy, as far as building out your categorization system, I found that using a synthetic hierarchy, where you actually only have a single layer to your taxonomy, but it contains two different elements, is incredibly helpful, especially if you're using simpler tools like spreadsheets or hybrid databases and you are not a proficient database user, having your taxonomy and categorization system in a single column just makes it far easier. And you can make a single column act as though it were two columns of data. The other thing I would suggest is brevity in creating your taxonomy. These are going to be used as labels, as columns, all over your data. So to the extent that you can shorten your taxonomy and keep it brief, you're going to reap benefits from that. The next step is tailoring your database to your needs. So adding tables that are custom to whatever product lines you're working on, whatever teams you're working with, whatever platforms you have, you're going to start building out new tables week over week to help you with your specific workload. You're also going to need to refine your columns. There's going to be days where you're adding columns, there's going to be days you find that you're not using columns you've created and that they can just go away, but it is a process over time. And then once you've kind of built out the fundamentals, you can start creating filtered reports and data views into your knowledge database. And this is where you start to really reap the rewards of keeping everything in one place. I have different reports like active tasks that are in priority order. They're sorted by their projects. I have a project contact list, so all the people that I work with on a particular element or product line that I'm working on. I also have a table of active updates that are sorted by category and project. So these are updates on the product lines I'm working on that are most relevant to the recent past. And it's information I hand out to my boss or information I hand out to teammates on a regular basis. So let's do one last thought exercise. What if you had all of your data in a knowledge management database? What if it was consolidated and organized? What if it was rapidly accessible across months or years? What if you could easily collate that data and report on it and share it with your teammates? What would change for you? Would you get more done? Would you be more effective as a product manager? How would change your business impact? I think the answer to these questions is fairly self-evident, but I've found over the years that taking an approach like this and organizing my data really well has made a huge impact on my ability to scale my own product management skills. I've been able to take on additional products. I've been able to manage small teams. I'm not saying it's been easy or perfect, but it certainly changed my ability to get things done. And then final thoughts. The quote on the screen is something I found true time and time again, and that's that organization is a journey and not a destination. There's no one right way to do knowledge management and to scale your product management effectiveness. This is just one way that I've learned over the years that's helped me quite a bit. I would encourage you to experiment and share everybody's difference. You may play around with some of these ideas for a while and find a different way to go about this. But if you do find something that works really well, please share it back with the product community. And the last thing I would encourage you to think about over the long haul is our organizations have very similar challenges to knowledge management as the individuals within those organizations. And I would encourage you to think about, how do you apply these concepts to your business as a whole? Is there a better way for you and your company to organize your knowledge to make it more accessible to the staff within that organization? So that's it. Thank you very much. And I hope these concepts help you in some way.