Justin Norris:
00:00:07
For many revenue operations teams, documentation is like a guilty skeleton hiding in the closet. We all know when something isn't well-documented oh, we know it all too well. But in a world filled with fire-fighting, bug-chasing, and 37 top priority campaigns with last minute deadlines, finding the time and mental clarity to document stuff seems like a distant priority. And so all the undocumented things remain, put off again for another day... Well, listen, I can't find you more time in the day but I do know that documentation becomes way easier when you have two things established. Number one, a clear knowledge base where documentation can live. Number two, you need a process that removes friction from creating documentation, making it easier to get it done in the flow of work, so it doesn't end up permanently in the backlog. I don't claim to have everything figured out, but I wanted to show you how we do it on my team. The first thing is you need some platform for the knowledge base to live in. We use Confluence, and I like it a lot. It's easy to create pages, keep them consistent and organized, to track version history, collaborate, control access, and so on. But there are other tools out there that will do similar things. Fundamentally, I think you just need something that gives you the ability to easily create these webpages and organize them. This means that you don't want to use disconnected Google docs that are hard to navigate and reference. Don't get me wrong. Docs are great for building. I just don't think that it scales in creating an interconnected and evergreen body of knowledge. This is our marketing ops homepage in confluence. It gives an overview of our team and some quick links. And underneath you can find all our docs about 100 pages and counting. One of these is our documentation guide, which is basically the documentation for our documentation. So I'm going to look at that as it helps explain how everything works. One of the main distinctions we make is between our system of knowledge Confluence and our system of work Trello. The docs we put in the knowledge base should be evergreen and a reference. The ongoing work and communication takes place in our project management system. This keeps the evergreen docs clean and easy to read. So let's say you have a tool and you're ready to create a knowledge base. Where do you start? Well, I think it's super important to have a clear information architecture. This architecture defines the different types of docs you have and creates an order and structure that's easy to navigate and to build in. Our docs are structured into five main sections. About Us is primarily for other teams at the company. It gives a general guide for how we work and links to important info like our OKRs. Next we have Process Docs which explain how we execute our marketing ops internal or cross-functional processes. How do we know what to make a process for? I say that any repeated activity needs a process, and any process should be documented here. For example, here's a doc for our trade show list upload and follow-up process. We have the process itself defined in Google slides embedded on the page. That's okay. The main thing is that the knowledge base provides context and easy way to access it. Our tools and platform docs are a catalog of all the tools in our stack. We don't go deep into systems architecture or enablement here. It's just a simple page that specifies what the tool is, the MOPS owner, the vendor points of contact, and how to log in or provision users. This gives a lot of clarity around questions. Like, do we use tool XYZ? Or what tool do we have for ABC use case? Stuff like that. Enablement docs are mainly focused on users outside of marketing ops. These are our "how to" docs. We mainly have these organized by tool. So, for example, in the Marketo section, we have guides and training on our email templates, how to localize our headers and footers for our different markets, how to build smart lists to create an audience, and so forth. I think of these docs as answers to frequently asked questions. Creating these will have a very high ROI when you can answer questions by sharing a link to your docs, instead of repeating the same answer multiple times. And let's face it, we don't have everything memorized either. So these docs are also valuable for operators. I refer to my own docs constantly. Lastly, we have system docs. These are documents for significant operational systems that our team builds and supports. For example, our lead flow, lead life cycle, routing, email preference center, and so on. It's important to note that these systems can involve multiple platforms. For example, our lead routing system involves Marketo Salesforce, our routing tool, Distribution Engine, multiple enrichment providers, and so on. These are essentially internal products that deliver specific functionality to the business. Let's look at our lead routing docs. These systems can be really complicated. So it's important to break up the docs to create bit-sized pieces of knowledge that can be accessible to different audiences. Here, we start with some general information about why routing is important and a high level overview of a leads journey. Then we have dedicated pages that are sources of truth for core business definitions. For example, our geographical territories are different routing scenarios or our SLAs. By separating this knowledge out, it makes it really easy to send a page about our territory definitions to a business user without making them go through a bunch of technical detail that they just aren't interested in. But those technical details are very important. The litmus test we use for documentation is: if our entire team disappeared tomorrow and had to be replaced, would the new team be able to take over seamlessly and know how everything works? This sets a pretty high standard, but it's really important to have that clarity. Otherwise systems become impossible to manage and scale. We forget why we have things set up in certain ways, and it creates a lot more risk of stepping on rakes by making changes and accidentally breaking things. So the technical details cover all the system design and configuration elements. These pages are geared towards technical users and other ops professionals. In writing the documentation itself, aim for clear and simple language and an organized and appealing layout. This makes it easy to understand and to maintain. Formatting is super important here. Things like headings, bulleted lists, data tables, or embedding a spreadsheet where you have more rules than can clearly fit on a page. I just want to close now with some information about the process for creating documentation and how to remove friction and make it easier. First of all, don't let yourself get overwhelmed if you're deep in documentation debt, meaning you've got a lot of stuff that's undocumented. Docs are never finished and are always changing. Get your structure in place and then just start somewhere. Also make sure you don't let the desire for perfect documentation be a blocker for creating something. Get a starting point in place that captures the basics and then you can always go back and improve on it. The other main blocker for creating documentation is finding time, but that gets a lot easier if you can create docs in the flow of work that you'll already be doing. For example, if someone asks a question and that knowledge is important, probably takes only a few minutes longer to create a doc versus simply writing an email or a Slack message. So invest the extra few minutes each time, and your knowledge base is going to grow quickly. Another key factor is to make the documentation part of the design and enablement stages for any new initiatives. This means you document as you go, or very soon after you build something, and don't consider a project complete, unless it's documented. You can also be opportunistic with documenting legacy systems. Let's say, you need to make a change in your lead scoring model and want to document it. While you're in that head space, you can also document the model as a whole because the big picture is clear and sharp for you at that moment. Lastly, if there are some important docs that just need to be tackled, you can organize a documentation blitz with your team to make sure it gets done. Just like a call blitz and a sales team, this is a time where everyone can block an hour or two on their calendar, pick an important topic, and just go for it. This creates momentum and accountability, and you'll find a lot gets done in a short time. One final note: documentation shouldn't live only in your knowledge base. Sometimes the most valuable documentation exists inside the platforms themselves where users are already working. I think as a general policy system description should always be populated with a brief note. That adds context and clarity for the user. You can then add a link to either a task request or a more substantive documentation for the user to learn more. These description fields are also a great place for change logs that help note significant updates that have been made. Well, I think you can see that I'm probably unusually passionate about documentation and knowledge management. But whether you love it or find it a chore, the key thing to remember is that a knowledge base is not a luxury or just a matter of hygiene. It's mission critical. You simply can't grow an ops team based on tribal knowledge It's going to lead to chaos and frustration. It's also an unacceptable risk for any growth stage business to rely on knowledge in someone's head just "being there" when needed. So when in doubt, write it down. Thanks for listening.
00:00:07
For many revenue operations teams, documentation is like a guilty skeleton hiding in the closet. We all know when something isn't well-documented oh, we know it all too well. But in a world filled with fire-fighting, bug-chasing, and 37 top priority campaigns with last minute deadlines, finding the time and mental clarity to document stuff seems like a distant priority. And so all the undocumented things remain, put off again for another day... Well, listen, I can't find you more time in the day but I do know that documentation becomes way easier when you have two things established. Number one, a clear knowledge base where documentation can live. Number two, you need a process that removes friction from creating documentation, making it easier to get it done in the flow of work, so it doesn't end up permanently in the backlog. I don't claim to have everything figured out, but I wanted to show you how we do it on my team. The first thing is you need some platform for the knowledge base to live in. We use Confluence, and I like it a lot. It's easy to create pages, keep them consistent and organized, to track version history, collaborate, control access, and so on. But there are other tools out there that will do similar things. Fundamentally, I think you just need something that gives you the ability to easily create these webpages and organize them. This means that you don't want to use disconnected Google docs that are hard to navigate and reference. Don't get me wrong. Docs are great for building. I just don't think that it scales in creating an interconnected and evergreen body of knowledge. This is our marketing ops homepage in confluence. It gives an overview of our team and some quick links. And underneath you can find all our docs about 100 pages and counting. One of these is our documentation guide, which is basically the documentation for our documentation. So I'm going to look at that as it helps explain how everything works. One of the main distinctions we make is between our system of knowledge Confluence and our system of work Trello. The docs we put in the knowledge base should be evergreen and a reference. The ongoing work and communication takes place in our project management system. This keeps the evergreen docs clean and easy to read. So let's say you have a tool and you're ready to create a knowledge base. Where do you start? Well, I think it's super important to have a clear information architecture. This architecture defines the different types of docs you have and creates an order and structure that's easy to navigate and to build in. Our docs are structured into five main sections. About Us is primarily for other teams at the company. It gives a general guide for how we work and links to important info like our OKRs. Next we have Process Docs which explain how we execute our marketing ops internal or cross-functional processes. How do we know what to make a process for? I say that any repeated activity needs a process, and any process should be documented here. For example, here's a doc for our trade show list upload and follow-up process. We have the process itself defined in Google slides embedded on the page. That's okay. The main thing is that the knowledge base provides context and easy way to access it. Our tools and platform docs are a catalog of all the tools in our stack. We don't go deep into systems architecture or enablement here. It's just a simple page that specifies what the tool is, the MOPS owner, the vendor points of contact, and how to log in or provision users. This gives a lot of clarity around questions. Like, do we use tool XYZ? Or what tool do we have for ABC use case? Stuff like that. Enablement docs are mainly focused on users outside of marketing ops. These are our "how to" docs. We mainly have these organized by tool. So, for example, in the Marketo section, we have guides and training on our email templates, how to localize our headers and footers for our different markets, how to build smart lists to create an audience, and so forth. I think of these docs as answers to frequently asked questions. Creating these will have a very high ROI when you can answer questions by sharing a link to your docs, instead of repeating the same answer multiple times. And let's face it, we don't have everything memorized either. So these docs are also valuable for operators. I refer to my own docs constantly. Lastly, we have system docs. These are documents for significant operational systems that our team builds and supports. For example, our lead flow, lead life cycle, routing, email preference center, and so on. It's important to note that these systems can involve multiple platforms. For example, our lead routing system involves Marketo Salesforce, our routing tool, Distribution Engine, multiple enrichment providers, and so on. These are essentially internal products that deliver specific functionality to the business. Let's look at our lead routing docs. These systems can be really complicated. So it's important to break up the docs to create bit-sized pieces of knowledge that can be accessible to different audiences. Here, we start with some general information about why routing is important and a high level overview of a leads journey. Then we have dedicated pages that are sources of truth for core business definitions. For example, our geographical territories are different routing scenarios or our SLAs. By separating this knowledge out, it makes it really easy to send a page about our territory definitions to a business user without making them go through a bunch of technical detail that they just aren't interested in. But those technical details are very important. The litmus test we use for documentation is: if our entire team disappeared tomorrow and had to be replaced, would the new team be able to take over seamlessly and know how everything works? This sets a pretty high standard, but it's really important to have that clarity. Otherwise systems become impossible to manage and scale. We forget why we have things set up in certain ways, and it creates a lot more risk of stepping on rakes by making changes and accidentally breaking things. So the technical details cover all the system design and configuration elements. These pages are geared towards technical users and other ops professionals. In writing the documentation itself, aim for clear and simple language and an organized and appealing layout. This makes it easy to understand and to maintain. Formatting is super important here. Things like headings, bulleted lists, data tables, or embedding a spreadsheet where you have more rules than can clearly fit on a page. I just want to close now with some information about the process for creating documentation and how to remove friction and make it easier. First of all, don't let yourself get overwhelmed if you're deep in documentation debt, meaning you've got a lot of stuff that's undocumented. Docs are never finished and are always changing. Get your structure in place and then just start somewhere. Also make sure you don't let the desire for perfect documentation be a blocker for creating something. Get a starting point in place that captures the basics and then you can always go back and improve on it. The other main blocker for creating documentation is finding time, but that gets a lot easier if you can create docs in the flow of work that you'll already be doing. For example, if someone asks a question and that knowledge is important, probably takes only a few minutes longer to create a doc versus simply writing an email or a Slack message. So invest the extra few minutes each time, and your knowledge base is going to grow quickly. Another key factor is to make the documentation part of the design and enablement stages for any new initiatives. This means you document as you go, or very soon after you build something, and don't consider a project complete, unless it's documented. You can also be opportunistic with documenting legacy systems. Let's say, you need to make a change in your lead scoring model and want to document it. While you're in that head space, you can also document the model as a whole because the big picture is clear and sharp for you at that moment. Lastly, if there are some important docs that just need to be tackled, you can organize a documentation blitz with your team to make sure it gets done. Just like a call blitz and a sales team, this is a time where everyone can block an hour or two on their calendar, pick an important topic, and just go for it. This creates momentum and accountability, and you'll find a lot gets done in a short time. One final note: documentation shouldn't live only in your knowledge base. Sometimes the most valuable documentation exists inside the platforms themselves where users are already working. I think as a general policy system description should always be populated with a brief note. That adds context and clarity for the user. You can then add a link to either a task request or a more substantive documentation for the user to learn more. These description fields are also a great place for change logs that help note significant updates that have been made. Well, I think you can see that I'm probably unusually passionate about documentation and knowledge management. But whether you love it or find it a chore, the key thing to remember is that a knowledge base is not a luxury or just a matter of hygiene. It's mission critical. You simply can't grow an ops team based on tribal knowledge It's going to lead to chaos and frustration. It's also an unacceptable risk for any growth stage business to rely on knowledge in someone's head just "being there" when needed. So when in doubt, write it down. Thanks for listening.
