How to Create a Knowledge Base

Justin Norris: 00:00:06

For many revenue operations teams, documentation is like

2

: 00:00:09

a guilty skeleton hiding in the closet.

3

: 00:00:12

We all know when something

isn't well-documented - oh,

4

: 00:00:15

we know it all too well.

5

: 00:00:17

But in a world filled with fire-fighting,

bug-chasing, and 37 top priority campaigns

6

: 00:00:22

with last minute deadlines, finding

the time and mental clarity to document

7

: 00:00:27

stuff seems like a distant priority.

8

: 00:00:29

And so all the undocumented things

remain, put off again for another day...

9

: 00:00:42

Well, listen, I can't find you more

time in the day but I do know that

10

: 00:00:46

documentation becomes way easier

when you have two things established.

11

: 00:00:51

Number one, a clear knowledge

base where documentation can live.

12

: 00:00:54

Number two, you need a process

that removes friction from creating

13

: 00:00:57

documentation, making it easier to get it

done in the flow of work, so it doesn't

14

: 00:01:01

end up permanently in the backlog.

15

: 00:01:04

I don't claim to have everything

figured out, but I wanted to

16

: 00:01:07

show you how we do it on my team.

17

: 00:01:09

The first thing is you need some platform

for the knowledge base to live in.

18

: 00:01:14

We use Confluence, and I like it a lot.

19

: 00:01:16

It's easy to create pages, keep

them consistent and organized, to

20

: 00:01:19

track version history, collaborate,

control access, and so on.

21

: 00:01:23

But there are other tools out

there that will do similar things.

22

: 00:01:25

Fundamentally, I think you just

need something that gives you

23

: 00:01:28

the ability to easily create

these webpages and organize them.

24

: 00:01:32

This means that you don't want to

use disconnected Google docs that

25

: 00:01:35

are hard to navigate and reference.

26

: 00:01:37

Don't get me wrong.

27

: 00:01:38

Docs are great for building.

28

: 00:01:39

I just don't think that it scales

in creating an interconnected

29

: 00:01:43

and evergreen body of knowledge.

30

: 00:01:45

This is our marketing ops

homepage in confluence.

31

: 00:01:48

It gives an overview of our

team and some quick links.

32

: 00:01:51

And underneath you can find all our

docs - about 100 pages and counting.

33

: 00:01:56

One of these is our documentation

guide, which is basically the

34

: 00:01:59

documentation for our documentation.

35

: 00:02:01

So I'm going to look at that as it

helps explain how everything works.

36

: 00:02:05

One of the main distinctions

we make is between our system

37

: 00:02:08

of knowledge - Confluence - and

our system of work - Trello.

38

: 00:02:12

The docs we put in the knowledge base

should be evergreen and a reference.

39

: 00:02:16

The ongoing work and communication takes

place in our project management system.

40

: 00:02:21

This keeps the evergreen

docs clean and easy to read.

41

: 00:02:24

So let's say you have a tool and you're

ready to create a knowledge base.

42

: 00:02:28

Where do you start?

43

: 00:02:29

Well, I think it's super important to

have a clear information architecture.

44

: 00:02:33

This architecture defines the

different types of docs you have and

45

: 00:02:37

creates an order and structure that's

easy to navigate and to build in.

46

: 00:02:41

Our docs are structured

into five main sections.

47

: 00:02:44

About Us is primarily for

other teams at the company.

48

: 00:02:47

It gives a general guide for how we work

and links to important info like our OKRs.

49

: 00:02:53

Next we have Process Docs which explain

how we execute our marketing ops

50

: 00:02:57

internal or cross-functional processes.

51

: 00:03:00

How do we know what to make a process for?

52

: 00:03:02

I say that any repeated activity

needs a process, and any process

53

: 00:03:06

should be documented here.

54

: 00:03:08

For example, here's a doc for our trade

show list upload and follow-up process.

55

: 00:03:12

We have the process itself defined in

Google slides embedded on the page.

56

: 00:03:16

That's okay.

57

: 00:03:17

The main thing is that the

knowledge base provides context

58

: 00:03:20

and easy way to access it.

59

: 00:03:23

Our tools and platform docs are a

catalog of all the tools in our stack.

60

: 00:03:27

We don't go deep into systems

architecture or enablement here.

61

: 00:03:30

It's just a simple page that specifies

what the tool is, the MOPS owner,

62

: 00:03:34

the vendor points of contact, and

how to log in or provision users.

63

: 00:03:39

This gives a lot of

clarity around questions.

64

: 00:03:41

Like, do we use tool XYZ?

65

: 00:03:43

Or what tool do we have for ABC use case?

66

: 00:03:46

Stuff like that.

67

: 00:03:48

Enablement docs are mainly focused

on users outside of marketing ops.

68

: 00:03:52

These are our "how to" docs.

69

: 00:03:54

We mainly have these organized by tool.

70

: 00:03:57

So, for example, in the Marketo section,

we have guides and training on our

71

: 00:04:00

email templates, how to localize our

headers and footers for our different

72

: 00:04:04

markets, how to build smart lists

to create an audience, and so forth.

73

: 00:04:09

I think of these docs as answers

to frequently asked questions.

74

: 00:04:13

Creating these will have a very high

ROI when you can answer questions by

75

: 00:04:16

sharing a link to your docs, instead of

repeating the same answer multiple times.

76

: 00:04:21

And let's face it, we don't have

everything memorized either.

77

: 00:04:25

So these docs are also

valuable for operators.

78

: 00:04:27

I refer to my own docs constantly.

79

: 00:04:31

Lastly, we have system docs.

80

: 00:04:33

These are documents for significant

operational systems that our

81

: 00:04:36

team builds and supports.

82

: 00:04:38

For example, our lead flow,

lead life cycle, routing, email

83

: 00:04:42

preference center, and so on.

84

: 00:04:44

It's important to note that these

systems can involve multiple platforms.

85

: 00:04:48

For example, our lead routing system

involves Marketo Salesforce, our routing

86

: 00:04:52

tool, Distribution Engine, multiple

enrichment providers, and so on.

87

: 00:04:57

These are essentially internal

products that deliver specific

88

: 00:05:00

functionality to the business.

89

: 00:05:02

Let's look at our lead routing docs.

90

: 00:05:04

These systems can be really complicated.

91

: 00:05:06

So it's important to break up the docs to

create bit-sized pieces of knowledge that

92

: 00:05:10

can be accessible to different audiences.

93

: 00:05:13

Here, we start with some general

information about why routing

94

: 00:05:16

is important and a high level

overview of a leads journey.

95

: 00:05:19

Then we have dedicated pages

that are sources of truth for

96

: 00:05:22

core business definitions.

97

: 00:05:24

For example, our geographical

territories are different

98

: 00:05:27

routing scenarios or our SLAs.

99

: 00:05:30

By separating this knowledge out, it

makes it really easy to send a page

100

: 00:05:33

about our territory definitions to a

business user without making them go

101

: 00:05:37

through a bunch of technical detail

that they just aren't interested in.

102

: 00:05:41

But those technical

details are very important.

103

: 00:05:44

The litmus test we use for documentation

is: if our entire team disappeared

104

: 00:05:48

tomorrow and had to be replaced, would

the new team be able to take over

105

: 00:05:52

seamlessly and know how everything works?

106

: 00:05:55

This sets a pretty high standard, but it's

really important to have that clarity.

107

: 00:05:59

Otherwise systems become

impossible to manage and scale.

108

: 00:06:02

We forget why we have things set up in

certain ways, and it creates a lot more

109

: 00:06:05

risk of stepping on rakes by making

changes and accidentally breaking things.

110

: 00:06:10

So the technical details cover all the

system design and configuration elements.

111

: 00:06:15

These pages are geared towards technical

users and other ops professionals.

112

: 00:06:20

In writing the documentation itself,

aim for clear and simple language and

113

: 00:06:24

an organized and appealing layout.

114

: 00:06:26

This makes it easy to

understand and to maintain.

115

: 00:06:29

Formatting is super important here.

116

: 00:06:31

Things like headings, bulleted

lists, data tables, or embedding

117

: 00:06:34

a spreadsheet where you have more

rules than can clearly fit on a page.

118

: 00:06:38

I just want to close now with some

information about the process for

119

: 00:06:41

creating documentation and how to

remove friction and make it easier.

120

: 00:06:46

First of all, don't let yourself

get overwhelmed if you're deep in

121

: 00:06:49

documentation debt, meaning you've got

a lot of stuff that's undocumented.

122

: 00:06:53

Docs are never finished

and are always changing.

123

: 00:06:56

Get your structure in place

and then just start somewhere.

124

: 00:07:00

Also make sure you don't let the

desire for perfect documentation be

125

: 00:07:03

a blocker for creating something.

126

: 00:07:05

Get a starting point in place that

captures the basics and then you can

127

: 00:07:08

always go back and improve on it.

128

: 00:07:10

The other main blocker for creating

documentation is finding time,

129

: 00:07:13

but that gets a lot easier if you

can create docs in the flow of

130

: 00:07:16

work that you'll already be doing.

131

: 00:07:18

For example, if someone asks a question

and that knowledge is important,

132

: 00:07:21

probably takes only a few minutes

longer to create a doc versus simply

133

: 00:07:24

writing an email or a Slack message.

134

: 00:07:26

So invest the extra few minutes

each time, and your knowledge

135

: 00:07:29

base is going to grow quickly.

136

: 00:07:32

Another key factor is to make the

documentation part of the design and

137

: 00:07:35

enablement stages for any new initiatives.

138

: 00:07:38

This means you document as you

go, or very soon after you build

139

: 00:07:41

something, and don't consider a project

complete, unless it's documented.

140

: 00:07:45

You can also be opportunistic

with documenting legacy systems.

141

: 00:07:49

Let's say, you need to make

a change in your lead scoring

142

: 00:07:51

model and want to document it.

143

: 00:07:53

While you're in that head space,

you can also document the model as a

144

: 00:07:56

whole because the big picture is clear

and sharp for you at that moment.

145

: 00:08:00

Lastly, if there are some important

docs that just need to be tackled, you

146

: 00:08:03

can organize a documentation blitz with

your team to make sure it gets done.

147

: 00:08:07

Just like a call blitz and a sales team,

this is a time where everyone can block

148

: 00:08:11

an hour or two on their calendar, pick

an important topic, and just go for it.

149

: 00:08:15

This creates momentum and

accountability, and you'll find

150

: 00:08:19

a lot gets done in a short time.

151

: 00:08:21

One final note: documentation shouldn't

live only in your knowledge base.

152

: 00:08:26

Sometimes the most valuable documentation

exists inside the platforms themselves

153

: 00:08:31

where users are already working.

154

: 00:08:33

I think as a general policy

system description should always

155

: 00:08:36

be populated with a brief note.

156

: 00:08:38

That adds context and

clarity for the user.

157

: 00:08:41

You can then add a link to either a

task request or a more substantive

158

: 00:08:44

documentation for the user to learn more.

159

: 00:08:46

These description fields are also a great

place for change logs that help note

160

: 00:08:50

significant updates that have been made.

161

: 00:08:52

Well, I think you can see that I'm

probably unusually passionate about

162

: 00:08:56

documentation and knowledge management.

163

: 00:08:58

But whether you love

it or find it a chore,

164

: 00:09:00

the key thing to remember is that

a knowledge base is not a luxury

165

: 00:09:03

or just a matter of hygiene.

166

: 00:09:05

It's mission critical.

167

: 00:09:07

You simply can't grow an ops team

based on tribal knowledge . It's going

168

: 00:09:10

to lead to chaos and frustration.

169

: 00:09:13

It's also an unacceptable risk for

any growth stage business to rely

170

: 00:09:16

on knowledge in someone's head

just "being there" when needed.

171

: 00:09:20

So when in doubt, write it down.

172

: 00:09:23

Thanks for listening.