214: Knowledge Management with Tadas Labudis

Charlotte Ward: 0:12

Hello and welcome to episode 214 of the Customer Support Leaders Podcast. I'm Charlotte Ward. The theme for this week is knowledge management, so stay tuned for five leaders talking about that very topic. I'd like to welcome back to the podcast today, Tadas Laboudis. Tadas, it is lovely to have you back. It's been a little while, and I'm really excited about this topic today because it is one that I am up to my eyeballs in this year. And it's it's knowledge management that we're talking about this week. So first, welcome back.

Tadas Labudis: 0:51

Well, thanks, Charlie. Great to be back on this podcast. You know, you spoke about taxonomies last time, I think. Must have been six months now. So very glad to be back and then talk about a new topic about uh knowledge piece.

Charlotte Ward: 1:03

Yeah, yeah, thanks. It was taxonomies, which um I found to be um a really, really interesting chat. And I would encourage anyone to I'll put a link in the uh in the show notes after this chat as well. I'd encourage anyone to go back and listen to that because it was some amazing food for thought. So I'm excited for today because we're talking about really your own personal experiences this time as well, in in terms of knowledge management, aren't we? And the the journey that you've been on. Um so knowledge management as a big topic is and and like can can be we can approach it really conceptually, I think. And I think that's where I think that's where I spend too much time is in the conceptual side of it. It's like I can talk for hours about the ideals of knowledge management and the ideals of knowledge-centered support, and the ideals of uh you know, a unified platform and accessibility, accessibility and uh, you know, like the relevancy and the currency of all of your knowledge. Um, so like conceptually, I feel that's where I spend all my time and maybe a little bit too much time, and also it's like really hard to talk to other people who don't have that interest about it at that level because it's really abstract, right? And I think what's interesting is that when when you approached me to talk about this topic, you wanted to talk about your really personal, like actual live experience of of building a knowledge base from scratch. So so maybe we start there.

Tadas Labudis: 2:38

Yeah, absolutely. So, you know, ProdSite is a relatively young company, and you know, we focus on building an intuitive product. That was um, that's my background, you know, come from product management. Um, and uh we also do all hand support. So our engineers, uh myself, we're we're all kind of involved in doing some support. And you know, at this stage, we're not overwhelmed with tickets and we can handle that, and that allows us to stay connected to customers. So um when we launched the product, we had no knowledge base at all. Because my kind of sense, maybe naive sense was you know, if the product is good, uh it should be intuitive and no one should actually need to read any additional material. You know, that documentation is for legacy products that are like bloated and and poorly designed, and that's why they have the knowledge base. We don't need that. Um, very quickly, we started getting requests from customers saying, Oh, you know, how does this page work? Or how does this report have? Do you have any documentation? It's like, hmm, what kind of documentation would you like? And we started getting all these requests. It's like, oh, you know, I don't know how this topic report works. Um, you know, can you explain like the methodology behind that? It's like, okay, so I started like curating, basically taking one at a time. Uh, I set up a little, I think we did it on on Intercom at the time on their whole product. And we put uh some articles together just to get started. There wasn't much structure to it, just you know, common questions they were getting, and we were adding them one at a time. And I think that's that's what allowed us to start uh quickly and address those pain points without getting overwhelmed about like what's the gonna be the structure, what's the you know, the the hierarchy of these articles, and and just kind of start building. Over time, as the list of these articles grew, we realized that there has to be some kind of drill down between these things. There has to be a logical structure that if a customer wanted to learn about a product, they could go you know by area first and then drill down into questions, also search aspect. Um, and that's when we started kind of rethinking. At the time, we also switched out to a Help Scout, and they had a slightly different product with the more powerful capabilities around the um the knowledge base uh that we were really seeking at that point. Um, so um so I guess at that point we were probably talking about like a hundred articles, and uh those were built over time, uh, but we didn't necessarily have a process for launching a new feature. So we covered the areas that we already have in the product, but as we're launching new features, things change. Either the interface changes and the old articles are wrong or outdated, or um you don't have coverage for those aspects of the product. And that's when we started thinking like, okay, launching a feature is not just getting the feature out, we also need to write the documentation for it at the same time, at least to cover the key aspects. And that kind of became part of a process. We build a feature, you test it, you write a documentation, and that kind of comes out together uh alongside the marketing announcement. Um so we kind of embedded that in our process.

Charlotte Ward: 6:06

I think I think that's a I think that's um I think there's an interesting tipping point here that I just want to kind of explore explore with you a little bit. One, I completely understand like that move to a process of creating documentation as you release things. That's the the mark of a maturing product. I mean, as as idealistic as you were in those early days, believing that a product doesn't need documentation, I'm so pleased you made the decision to actually produce documentation as part like systematically. That was such a good decision. But what happened then with all of that earlier knowledge? And I mean, all of that earlier knowledge also what although it was it had by this point some sort of a hierarchy, some sort of a structure, what form was it taking? Was it still very much QA? Was it response to a problem by and large, or was it already kind of coalescing into more of a documentation style, anyway?

Tadas Labudis: 7:05

Yeah, so I think um we try to approach it from the perspective of asking a question and then uh the article's an answer. And um, you know, trying to to kind of follow an example of other companies that you know, I've looked at Xero quite a lot, uh, intercom their own documentation or I guess knowledge base and seeing like how do they do it? Because what's the point of reinventing the wheel? You know, we're a small company, we don't need to like come up with our unique style. Um, we just need to make it work uh and do the job. So I notice a lot of companies are using this kind of question and answer format, and that's what we adopted. It seems to work well. Um, when it comes to the actual structure of it, um it's it's much easier to do that on Help Scout because this the categories you can apply multiple categories to one article. So it's more of a networked approach of you know, you could approach a given article or question from different angles. Um for example, if you're talking about plan limits, you know, that could be under billing, but also could be under reporting uh as the limits kind of affect your reporting or what data you're getting in. So we could add that one article into other categories. At the same time, you could also apply tags so uh the search terms are picked up correctly as well. So there's many different entry points for an article. Uh, but I think the biggest um kind of revolution or something I'm really kind of proud of is integrating, taking those articles back and integrating them in the product experience. So, what I mean by that, so kind of trying to be trying to offer that assistance to the customer when they need it the most or what are likely to need it. So um essentially, if you're on a product side and you are on a given report page, we dotted these little question marks and and hyperlinks that can open a relevant article uh that's associated to that section of the product. So if you're looking at a sentiment report, that report um you know has we have an article that talks about the methodology we use for sentiment, how to read the report, how to use it. So we added a little question mark when the user clicks on that, a little sidebar appears on the site and they can read that information context. And if they drill down into any other articles or links in there, they kind of keep uh that context of the feature side by side with the article or information. And they can close that anytime and go back to their work. Um and that was really enabled by uh the Help Scout uh product that you know it's a pretty unique approach. I've never seen that before in any other uh knowledge base that I used. And you know, that again became part of a process. So now every time we ship a new feature, we not only write the article, but we also embed it in the relevant uh section of the product.

Charlotte Ward: 10:07

Yeah, yeah. And actually that's more than you know, when when you when you talked about like little question marks, I was thinking this is kind of tool tech tooltips, isn't it? But it's much bigger than that. Like this isn't, you know, this this is a single sentence or a fragment set, fragment of a sentence definition of the thing I'm hovering over. It's really quite in-depth access to all of that knowledge, right, when you need it. Um do you do just as a slight aside, because I do work for a data company in my day job, um, do you do any onward, do you do any correlation or onward tracking of those behaviors in terms of how your customers interact with that knowledge within the product?

Tadas Labudis: 10:50

Yeah, so this is uh, I guess, you know, when you think about maturity around these things, I feel like we've made progress towards, you know, going from no documentation to having it and then embedding it. Uh when it comes to analytics, I think given the volumes we're getting, there are B2B product, often kind of large enterprise users, um, we don't have necessarily like the statistically significant volume or throughput to be able to say, you know, this article is underperforming or that article uh is being requested a lot, we need to prove it. So that analytical aspect uh is something I think for the future, once we scale a little bit more. Um, although we do get some insights as to which articles are being consumed or read by our customers. And uh we also can see um in the knowledge-based search whether there were any failed searches or common searches that could indicate new articles might need to be produced. So um not very, unfortunately at this point, not very tight on the analytical side or like closing the loop, uh, but very excited about getting into that a little later once you mature.

Charlotte Ward: 11:57

Yeah, yeah. I I it's something I'm super excited about as well, I think, is like be being able to work on the at those analytics and figuring out not just what knowledge-based articles customers are using and you know, did you find did this solve your issue for you? Yes or no, kind of questions that that are great for like informing ticket deflection and all of that, which I I know that our uh listeners will be keen to hear about. But but also I'm super interested in things like um, you know, a customer used this article. What did they do next? You know, I I think though that's like I think that's deeply interesting. If they searched for something and used it, fair enough. But then did they go where you expected them to next, either in the knowledge base or in the product? I think that's really super interesting.

Tadas Labudis: 12:49

Yeah, so one of the things uh we are doing for that is obviously our product is instrumented in uh analytics. Um, you know, common things which pages are being viewed, which um I guess features are being interacted with. Um, so because we have those articles embedded in the product, um, when someone clicks on them, we can track that event as well. So it's not something we've done a lot on because it's very contextual, right? Sometimes an article might give you general information, sometimes there's an action to be taken, uh, which may or may not need to be taken. So it's kind of hard to assume what the user should do in all cases, but we have that ability to create these funnels, uh, or I guess measure these behaviors as we're uh exactly for that reason because we have it embedded, so it's much easier to see the relationship between the articles and the behavior in the product. Um, but it's it's a great idea, you know, it's not something we've done much on, and and now I'm thinking well, all these different kind of parts of the ad could come back to and measure and leak. So I might do that after the session.

Charlotte Ward: 13:53

Yeah, oh could you come back and tell me like what you find? I think that because that's that's I think you know, sometimes I just I go to bed at night dreaming of this kind of thing. Like, how can what what would I do if I knew that? Like if a customer was on that screen and they, you know, you popped up a bit of information, but then they did something you entirely didn't expect that that might be captured in your product telemetry, but might not necessarily if they're interacting with the knowledge instead.

Tadas Labudis: 14:22

Yeah, I think for me, you know, I guess what's the point of uh knowledge base at all or like embedding articles, writing articles? Um, I think for me uh it's not about deflection at this point, um, but more about reducing friction for the customer. So if they're struggling with something, if you think about all the steps that we need to like write up their query, wait for response for us to like verify it, clarify it, respond, you know, that could take some time. And even if it's like half an hour, um that's still too long. Um so if there's an article, if you can prevent those experiences, if you can uh predict what might be interesting, surface that information robber in place, then it will lead to greater product experience. So I don't think about knowledge bases as the flection strategy, more about an augmentation of the product experience. Um and I think managing it from a central repository where I guess you're not relying on developers to write that product copy, you know, that's that's another point. It allows us to have uh yes, non-technical users can control uh the product experience as it relates to kind of that that packaging of the product without relying on developers to go in and change it in the code. Um and I think that's another big aspect is uh any anything that requires development, you need to go through like a sprint development process and it needs planning and takes away from other core features. So anything you can do to reduce that dependency, I think is a big plus.

Charlotte Ward: 16:00

Yeah, yeah. And and I I do agree that while ticket deflection is is an attractive metric for a support team, and and certainly like it can't be argued that if you can take work away from your support team, nobody's gonna complain. Um but but I think also I think that is a point, I think that is a point that's often lost when it comes to giving customers access to the knowledge they need when they need it. It's it's not just about ticket deflection, it's not about load reduction, it's it's more about uh augmenting their experience. And therefore, I think it's about like increased product activation. And I think it's also about fundamentally it's it's a success metric, isn't it? It's not not a metric, it's a a success mechanism, right? I think that it is another way in which you can uh fulfill your brand promise, frankly, fulfill your product promise of of enabling your customers to achieve their business goals.

Tadas Labudis: 17:06

Absolutely. I think um it's uh you know it's something that should be taught about as the features uh or products are being developed, and I think oftentimes isn't uh part discussion, it's kind of like an aftertot, launch this feature. Oh, you know, we don't have documentation, people are asking these questions, then put documentation in place. I mean, there's nothing wrong, you can't predict everything, but just to get the basics in um for someone to explain the feature is a great value. Another thing we do is actually we write the documentation in a way that I guess it would read more like uh marketing copy. So it's not like a night and day difference between our marketing emails and reading these articles. So we often embed those articles into our marketing materials as well. So if you have a newsletter announcement um about a new feature, we would say you can learn more about it here and direct them to the article, which then often links back to uh experiences or screenshots in the product, so kind of completes that understanding and then um actually it helps with um I guess uh activation of those features. So it's not kind of after the fact thing once people have the features, but actually helps us upgrade accounts and sell new functionality.

Charlotte Ward: 18:32

Yeah, yeah. So I think what we're saying is like that knowledge is so much more than just uh a few articles thrown together. Um you have to have this kind of much more holistic view of it, don't you? And and I think a consistent tone and a consistent um uh like an approach that ensures that the right people have it at the right moment.

Tadas Labudis: 18:58

Yeah, absolutely. Yeah and you know, a lot of these things uh I wouldn't necessarily say we knew up front when we were getting into it. We kind of took it step by step and then realized that the kind of the value and the power um or like how interconnected uh the knowledge bases. I guess another thing to touch upon as we were developing these public-facing documents uh on the knowledge base, we also realized there's a need for certain things to be written up for internal use. So uh for that we use our our usual big cake on Notion where we built up all kinds of documents. And these are reserved for processes that wouldn't necessarily affect the customer if they wouldn't run those processes. Let's say uh we need to set up a new account and there's a manual step that we need to do. Um, you know, it's great that I know or a developer or someone else on the team knows that process, but if you want to scale, we need to make sure they're consistently documented, they're consistently done. And that's one way to ensure that is to kind of dump your knowledge into an article in consumable form, uh, put it in a place where someone could look up even if they don't have that context or training, and then build that up over time. So as we're building our public documents uh and knowledge base, we're also building our internal wikis for uh for processes that we run.

Charlotte Ward: 20:22

Yeah, yeah, that that makes complete sense. And I think that's really important for all sorts of reasons. And and the the whole um the whole kind of sphere of knowledge, public and private, um, it just benefits every part of your organization from getting you out of the weeds because you can pass on the knowledge passively without having to answer every single question that comes from from a customer or from a new hire, but but also just maximizes the success for your customers and your internal folk as well, right?

Tadas Labudis: 20:58

Absolutely. And um I guess uh one challenge that I'd like to raise and maybe hear your thoughts on, uh kind of maybe turning the tables a little bit, is um the documentation still relies on someone interacting with reading it. And if it's slow, um that could detract from its purpose in the first place. So it kind of requires a level of motivation from the user. And I think that balance is shifting a lot these days where people are overwhelmed with lots of products that they're using, they don't have the time to really dig in and work on one part of time. They might be switching between different tabs. Maybe from your side, have you seen uh any kind of best practice around making sure that you kind of hit that right spot with documentation that's easy to consume but also informative at the same time?

Charlotte Ward: 21:50

I I don't know about best practice. I mean, I'm a huge advocate for knowledge-centered support, which I think can inform the documentation. I I think it blurs that line between a support knowledge-based article and your formal documentation. And I think in blurring that line, you increase consistency of tone and approach, and and I think um also tend more towards bite-sized knowledge. I think like deeply contextual what I need to know when I need to know it in the in the tone and from the perspective that I expect it as a customer, you know, rather than what my engineers or product managers kind of think the customer ought to know and think of how is how a customer talks about the product. So I I think I think just my own ideals around that would be kind of bite-sized and in the customer voice. Um, and I think you're right. I think this is just what the way we're tending anyway. I think the the days of I'm I mean, I spoke to uh other people this week who who all had varying takes on this and varying um, you know, examples, but that kind of uh, you know, it's the contrast between somebody giving you the the little pointy you need, right, when you need it, and like having the the big user manual next to you, you know. I've I've literally got a cupboard of to show my age now, Oracle 8 manuals over there.

Tadas Labudis: 23:27

Well, they must be huge.

Charlotte Ward: 23:28

Yeah, and and they they they fill a shelf. Um, I probably I probably only ever used 3% of the pages in those manuals. Um, and they were all on paper, obviously. No, and I and I think that's like a very, very traditional approach to documentation. A documentation approach to knowledge is get everything out there, provide the in back in the day, the index, in the hope that the people who were going to consume that knowledge would know how you'd referred to it in the index to find the bit that they needed, which is obviously horrific and was horrific back then. Um but uh but I think that I think we're moving rapidly and thankfully away from that way of producing knowledge.

Tadas Labudis: 24:11

Yeah, absolutely. And I think what one thing you're seeing is this revolution even in enterprise software, where products are becoming more like consumer products that we would use and enjoy. So this kind of expectation around the quality of user experience, the amount of like learning we need to do on any given product is shifting towards less and less. And I think um bite-sized uh content kind of fits into that um idea. And what one more thing that I was considering and maybe would love to hear your thoughts on, is multimedia and uh knowledge bases. So obviously we're thinking documentation is text, but I guess it could be a video, it could be an audio file. Um have you uh considered or have you used um video in in your um knowledge base?

Charlotte Ward: 25:06

Internally we do actually. And I I think that um I my team is remote, and I've only ever worked, well, certainly for 17 years now, worked with remote support teams scattered. So I think when it comes to thinking about everyone's individual workflow, understanding that we aren't all going to be able to access things in the same way at the same time of day or um or have the same approach to learning, um, particularly in the moment when you need it. The thing I was saying before, like servicing the knowledge to them is as important as serving it to my customers. Um, and and so where I'm going with this is like from an internal point of view right now, multimedia is definitely the way, but I don't mean video and nothing else. I literally mean multiple ways of accessing the same piece of knowledge. So one thing I really encourage my team to do, for instance, is if we are teaching something to a new team member, um, let's record it. You know, have that conversation, have that 10-minute like little educational piece, but record it and then also capture a synopsis so that we have access to the video. We probably have some screen grabs that we've we've got in there as well, and a little bit of a write-up and just gathering it as it's it's it's knowledge-centered internal support in a way, like creating these things that if someone has the time, can go in and soak up all of the nuance and detail by watching that training session. But also if you just want the key points and you want to know what that screen was again, you don't have to find it in a video.

Tadas Labudis: 26:47

Yeah, uh, you know, uh, and there's lots of, I guess, different tools now for quickly capturing that video. It's reducing that barrier. You know, one thing that, you know, if you're thinking about a public-facing knowledge base, one thing that concerns me slightly is, you know, the production quality that's expected from public-facing video and also the skill set, you know, you could have a person who's really good at writing uh knowledge base articles, producing videos like completely different ballgame, you know, especially in the world where we have like YouTube celebrities and like so much video content that's so high quality. Um, have you experimented at all with uh producing public-facing video for emoids?

Charlotte Ward: 27:25

No, and it is scary. It is scary. I would love, I would love to. I mean, also being slightly mindful of our typical users aren't um in the moment necessarily going to sit and consume a lot of video. Um, and considering that public uh sort of quality expectation, uh, the the sort of you know being consistent with brand and bit you know, talking about like meeting certain production quality expectations, I guess, is is is onerous. That whole piece is quite scary. I do know companies out there that do it though and do it very successfully. And one that springs to mind immediately is GitLab, who I'm also talking to this week. Um so listen to that episode. Um make sure it's tune in, yeah. Yeah, yeah, yeah. Um and there's some really interesting and innovative companies out there, but I think a lot depends on the company and the typical consumer as well. I haven't quite dared to do it yet, but I can see the value in it. And you know, and I think for those companies that are brave enough to do it, kind of, you know, kudos to them because I think it's it's an easy way to deliver, like, and and you know, just everything we said, making it accessible, making it in the moment multiple different ways is I one thing I really truly believe is is good enough knowledge is better than no knowledge. So uh I, you know, if that's all we've got, I would probably rather put out that out there. But I think you know that we have to all appreciate that we're working in the confines of you know certain all certain kind of organizational and and in like industry sector constraints and expectations. So there's definitely a bigger piece to think about there, and I haven't ventured into it yet. Maybe I will.

Tadas Labudis: 29:13

Absolutely.

Charlotte Ward: 29:15

Thank you so much, Tanas. I I mean we we went long on that chat, but I I've loved every minute of it. Thank you for coming back. Come back and talk about something else soon.

Tadas Labudis: 29:24

Well, thanks so much, Charlotte. You know, I learned as much as hopefully our listeners have, and uh uh appreciate you having me back on this podcast.

Charlotte Ward: 29:34

That's it for today. Go to customersupportleaders.com forward slash two one four for the show notes, and I'll see you next time.