Brittany Ryan - The hidden power of information assets The role of documentation in product success

This talk discusses the integral role of documentation in product management, using Lego as an analogy to illustrate the importance of clear instructions and inspiration in product development. The speaker, Britney, leverages her 17 years of experience in product management and communications to challenge attendees to consider their documentation as a core asset rather than an afterthought. She highlights the necessity of understanding user needs and emphasizes the need for comprehensive information assets that empower various stakeholders, including customer support and sales teams. The session details the complexities of managing product documentation in a banking software company while exploring strategies for creating a self-service information ecosystem that enhances user experience and reduces onboarding friction. Additionally, Britney touches on future initiatives involving AI and how information management must evolve in this landscape to maintain relevancy and efficacy.

All right, as I understand it, we're at the top of the hour. In theory, the audio should be working fine. Still some people trickling in. This is a bit of an outlier presentation at a Dev World conference, but for those of you who are either in the product management track or particularly interested in product management or maybe you're super uh nerdy like me and love information, then

you're in the right spot. On that note, we're going to get started. Uh I'm holding my phone because fun fact, Canva does not work with most uh presentation tools. So, I'll be using my phone as a clicker today. So, pro tips for anyone out there in the same situation as me. But, okay, welcome everyone. We're settled in. I'm going to jump into a place that we can

all probably relate to. Lego. Whether you have kids or you're a grown-up kid, there's a lot of Legos being given away today, I see, and yesterday as well. Lego is really a product that was, as we know it today, brought around in 1949. But it wasn't actually until 15 years later that they introduced instruction manuals with their products, which is kind of interesting if you think about

it because you can see that well blocks, they stack on top of each other, they click together, you can do things with them. Why do you need an information set, you may ask? Today, if you look at a basic classic box of Lego, you get a template inside that Lego box. And that pamphlet is made up of a mixture of things. It's not just instructions on how

to click a block together with another block. Even though it's for four-year-olds or grown-ups, whatever it might be, it's part inspiration and part instruction. What you see here on the lefth hand side is some ideas. It's things that you can create. It's opening your creative mind. It's thinking like, how can I get more out of these blocks? How can I create a world with these blocks? But

it's also for something slightly more complex like this helicopter here. step-by-step instructions to achieve this helicopter result. For me, this is a really helpful point of reference to get everybody kind of thinking about the same thing, information and what it can do for your products. Who am I? Well, I uh my name is Britney and I have about 17 years of experience in both product management and

communications. My origin story is actually in advertising and communications and really for the last 12 years I've been pretty strictly focused on product related activities. before scrum and agile were really a thing for those of you in the room who uh can relate. Uh yeah, we were doing product related work uh back then. So that's why uh I'm here kind of now building products to communicate better

about products which is like a a full circle uh picture to be in. But basically what are we here today to do to ask ourselves how many of us are treating our documentation like a core asset for our product development instead of like an afterthought as part of that development life cycle. And more interestingly, how do you personally or your organization define documentation? Now, I know all

of you in the room have different types of products, different levels of product maturity, different levels of complexity in your organization. So, I'm not going to attempt to make some broadstroke uh consistency here, but I hope that everybody walks away with a slightly different angle of consideration for information in their product space after this. Okay, let's go back to the textbooks. product management. If you look, if

you Google image, if you look at any kind of diagnostic overview of what the product development life cycle looks like, you're going to get basically these milestones. Some pretty standard stuff. We all know it. We've all heard it. It's back of the uh napkin, obvious basic phases. But even at this point in time, when I did a Google search last week and I was checking like, hey,

has this really evolved in the last 10 years? I'm still asking myself, yeah, but what about how it's being consumed? Obviously, at this stage, we're reporting on KPIs, there's performance indicators, there's AB testing, there's all sorts of data points that are indicating to us whether our product is successful or not. But at the end of the day, on the other side of that product, there are humans

consuming these products. And those data points are good indicators, but they're not the full story. And everything that we are putting into our products to test them, to learn about our users, to learn about the pains that they're experiencing actually is expertise that we as product experts have that can really play a critical role in the information assets that are produced about your product. So asking ourselves,

are we investing enough to help people use our product? And again, think about Lego. You don't have to have the most complex product in the world for this to matter. It can be a simple product and you can inspire people or it can be a really complex product where you really need to give some complex instructions that people can follow. Why is this important? Well, I could

also spend the next 20 minutes spouting off data. I decided to go a slightly different route, but just to give you some performance indicators and some data points for why this is relevant and why you should care. Yeah, a couple of data points. I mean, on boarding, we all know first- time user experience is really critical. 50% uh of turn can happen in the onboarding process. Things

like uh reducing onboarding time by 20 to 30% if you're investing properly. But not just time to value also reduce friction. Obviously, if someone can get more out of your product, they're going to enjoy working with it. Obviously, it's not just engineers. I mean, this was a Stack Overflow survey of 60% of developers saying, "I don't want to work with the products with crappy documentation." But actually,

we're all humans now, and most of us are expecting like a GPT experience at this stage. So yeah, I think the threshold of tolerance is getting lower and lower by the minute. Also lower churn. Obviously, if you have friction, if you have low time to or long time to value and you have a lot of friction, you're going to get churn and at the end of the

day, you're not having a successful product. Now, these data points can go on and on uh but they are kind of painting a picture for you of how important this is that documentation shouldn't just be part of your standard SDLC. And by documentation, I also want to challenge that thinking as well. You'll notice that I'm kind of going back and forth between the word documentation and information

assets. I'm really trying to challenge everyone to just step back, widen your perspective here, and think more than just the documentation that's being produced. Think again about LEGO. Think about how are you inspiring? What tools are you giving to your sales team to to really trigger differentiation and benefits in the market? What tools are you giving to your customer support teams to provide better support that's more

on point with the value that you're trying to add in your product features? There's a lot of aspects of your organization depending on how large or small you are, whether it's a customer support person or a whole department sitting somewhere on the other side of the globe. At the end of the day, there are various stakeholders in the organization who are helping different parties consume your product.

All of those parties need tools as well to understand your product and the features and the benefits that they bring. So again, what are you as the product subject matter expert doing to make sure that these parties are also empowered and enabled to do a better job to make your product successful. I'm going to switch gears a little bit and I'm going to talk a little bit

about backbase. Just show of hands in the room with the exception of the back basers. Anybody heard of backbase in the room? Couple of people. Okay. I'll just give you a little bit of context so you kind of understand the scope of what we're dealing with. Well, we sell white label banking software quite simply. But uh if I really give a high level summary, there are some

applications that are available out of the box for banks, right? So digital banking experiences. Those applications are built on a platform. That platform is choa block full of capabilities that do different things and can also be built on and expanded upon. And there's of course an integration layer to connect to the bank's core services and things like that. If you take a closer view, you have capabilities

that each need to be described. They each need to be understood and they can all empower the bank to achieve different results in their banking experiences. So again, this is just a snapshot. Uh well, in layman's terms, this is a very complex product and software landscape. As you can imagine, it's also a very complex information space. A bit about scope of our information world. We have something

like 20 plus technical writers at any given moment. We're investing and this is a conservative estimate something like four and a half million each year in different information related assets. And I'm not saying that's an efficient investment. It's got a lot of waste in it. So we're definitely not perfect. But also the speed with which these doc sets are growing is immense. Each quarter it's something like

15% uh increase in the number of docs that are uh having to be well dealt with and squeezed knowledgeable insights out of. So it's it's a complex space to keep up with. Uh I'm not at all here to say that we are doing it right or perfect. We're still a long way from that, but I guess you can kind of get the the vibe. But around 2023,

which I mean this image to me looks a bit like 1996 called and wants its documentation platform back, but uh in any case, this was the documentation state of affairs when I joined the company. It was actually a forums tool. So like good old school forums where engineers can talk to each other. uh but that forums tool was then kind of engineered some more to add some

documentation into it and it became basically a documentation platform uh which was built on a forums tool. So you can imagine that was a little bit like a not not not an ideal situation but also it was limited to the technical documentation and during this time we had a lot of pain points. There was a lot of concerns from the market about uh well backbased products are

hard to implement. Still sort of a perception that we combat but also that it's too conceptual. Great that you're here telling me that you have all these beautiful banking apps but show me like what what can I see to prove that I'm not going to have to invest a lot when I buy this product to build all this stuff from scratch. Also a lot of differentiation doubt

right so a bank thinking yeah if I buy something out of the box how is that making me special in my market? So to what degree do you empower me to differentiate in the market basically? But now let's think about information and what these type of pain points mean through my information brain. What I think about is okay if someone thinks that our products are hard to

implement maybe I should hold their hand through that implementation journey give them more transparency explain to him that them how that process is going to go. If they think it's too conceptual then maybe I should make it tangible. I should let them explore it themselves. Take the salesperson out of the equation, build some credibility and give them tools that they can explore on their own to feel

and understand what that product contains. And if they think they can't differentiate, then I need to do a better job of showing them the configuration options that are available to them, what they can do to get their own results to make their features and to differentiate in their market. What does that mean as far as information assets? Well, it means I need to deliver something that gives

transparency in implementation. It means I need self-ser exploration and visuals and maybe even environments if technology allows and I need to do a better job by offering these configuration articulations and lookbooks and examples like that. So whatever it might be, what I'm trying to explain to you with this is that regardless of what your organization's pain points are and what your strategic objectives are, if you scratch

the surface, there's always an information opportunity in that. And if you think as a product manager, okay, this is the pain I'm hearing, these are our strategic objectives as a company. What does this mean as far as what kind of information can I produce? what kind of tools, resources, assets, whatever that might be to whether it's inspire or give more clear instruction or make people just enjoy

working with your products. It's just to kind of think more holistically about the information landscape around your products. So in practice, what does that mean in the organization? It's not simple. It took us years uh to transition this world. But basically what I'm trying to paint a picture of here is that the information assets that I'm now describing, they lean on input from the whole organization and

they also require perspectives and contribution and processes and all that stuff for all the different aspects of your organization. So it's it's a whole it's a whole pie of information if you will and it's not just what a technical writer produces at the end of an SDLC as part of a definition of done to then submit and then wash your hands of it and check the data

in two months time. super important to consider that there's a whole landscape outside of that. Well, this is our product today just to give you a sense of where we're at. This at this stage of maturity was reached uh somewhere last year. We to my knowledge are one of the very few players out there that has actually created an information platform where all the aspects of working

with our products are in one place. So that is everything from functional information to technical documentation and dev kits, resources, etc. but also implementation methodology and learning resources in one place. We make this available not only to backbers to expedite onboarding and tooling that's saved something like 40 hours a week of preparation of training materials down to now three hours for the training and onboarding team to

just produce information because they can send them to this platform. So it's really about empowering internal tools but also it's available to our customers and partners obviously for self-service exploration has some latent benefits of upselling obviously some natural understanding of wider opportunities with backbased software and last but not least we also make this available to prospects we have something like 9 and a half thousand users registered

today and of those something like 6% are prospects that are signed on an NDA. So we even let people in sooner and we call that sort of appeal to the cut the crap persona in the buying cycle. So at the end of the day when you talk about software this complex and with this type of price tag obviously a financial institution wants to be able to trust

that they are not going to have latent costs or they want to lower the risk in that purchase. It's sort of the cover your ass uh principle in a buying decision as you can imagine and this also plays a role in that. Well, some other insights. I mean, this is the functional information, right? So, we've made it visual. Uh, this is just a CMS behind this, a

basic front end, some images based on Figma, Figma embeds, etc. Configurations. We help business decision makers understand what configuration options there are. Uh, and this is really, you know, this looks laborious. Uh, maybe if you think about the scope of the product I mentioned before, I'm not implying that it's not, but our team is rather small and tidy. Most of them are actually here today. And uh

I just want to basically paint a picture of what's possible if you think smart with resources and tools that you might have already. Um but anyway, this is a also a catalog of a different way to explore our out of the box products. We also have a video library. When you have new features or extensions on features, people can also find videos. Um so we also aggregate

all of this in the relevant views. to try and improve the findability of this information which is still by the way the number one issue that we face even with this uh in right uh I have Lego elephant there's a bit of an elephant in the room we are all here a lot of AI discussions going on so you're probably saying to yourself yeah okay great that

you've done this for the last three years uh but what about now in the AI world super fair point I'm challenged with the same question uh I also don't have the answers but I wanted to at least share share with you what we're doing at the moment on that subject given where we are today given this way of thinking in our organization and given the kind of

technical landscape that we're now facing. What's next for us in an AI world? Well, we're doing two things. First of all, just because we have a beautiful front end that brings all these information assets together doesn't mean it's in a consistent form of data. And it certainly doesn't mean the data is in the same place. So we have a massive data foundation challenge that our team is

facing to bring all of that data into one place in a consistent way so that AI tools can do stuff with it. And secondly, we also are running multiple experience uh experiments and also checking different vendors up against the use cases in our organization to understand what vendors are there playing right now that can cover the most use cases. And we are actually going to bet on

three different horses this quarter. We're going to see what the results are of those three different horses and then we will compile all of these insights into a business case for management and decision-m. So this is just a little bit of where we're at and how we're going about it. Um let's see. It's a rapid train we are chasing to get us there. Okay, that was a

lot. That was fast. That's a lot of product. Now, if I would translate this to some maybe thoughts you guys can take away and take this back to your organizations and to your own products or to your own product team members. A couple of key points I'd like you guys to kind of deposit in your minds. First of all, as a product expert, the subject matter expert,

you have a niche role. That niche role means that you have insights. You have nuggets of information that you carry around with you that are for you meaning nothing but actually can really help someone in customer support or can really help someone who's out in the field trying to convince a buyer. These are nuggets that you have the power to yield as a subject matter expert and

infuse into your activities internally but also into assets that can be consumed by your users. Also, are docs part of your job? Is information part of the job and career framework at your company? I'm not sure. For us, it definitely wasn't. It still isn't in some job functions, but to what extent are we evaluating ourselves on the role of information? So again, not about the definition of

done checkbox at the end of the FCLC, but actually part of a career framework and an evaluation. To what extent are you as a product manager making it part of your requirements and your planning sessions up front? To what extent is it coming out of the pipeline on the other end? And to what extent are those review cycles of the content about your product at all baked

in to the expectations and responsibilities of your role? And lastly, consider the full spectrum. So again, there's a full spectrum here of consumers of information, not just users of your product. There are people that are either helping you sell your products, support your product, etc. I can't express that enough. There's a full landscape of assets that are beyond just documentation that play a role in your product

success. and small but mighty. So I painted a picture of a complex organization, a very complex software, but I also come from the startup world. I come from a one-man bandstand dynamics and Swiss Army knife tools and hybrid multi hat skills. So I really want to impress to everyone here that this did not take a team or even like multiple squads. We we have a very small

team. We have two uh small but mighty content managers. We had product managers and tiny unit of team, some front-end capabilities. And from there, it's basically being smart, building on the tools and processes that are already in your organization. It's just thinking of smart kind of creative ways to just move that needle a little bit, create just an extra asset, to add a little bit of coverage

in that information that you're producing about your product. Also, inspire and activate the people around you. Inspire people around you about the information about your product. Some people say to me like, "Yeah, okay, you make information sexy." Like, that's the whole point. That's the that's the goal. I mean, information is not something we all get up in the morning and think like, woo, yay, docs. But, well,

okay, some people might, but um, but I definitely don't. But actually, product success does get me out of bed in the morning. And if I think about the different tools at my disposal to yield product success, information assets are definitely one of them. And last but not least, provide a view on your assets. Sometimes as product managers, we're taught to like make a stakeholder map, for example.

You know, who are the different stakeholders doing what with your products? You can do the same with information assets. What kind of information assets are playing which role at what part of your customer life cycle and which areas are creating pain? A little bit of service design, a little bit of product thinking, but just focus on information. It's all the same skills we already have as product

professionals, just applied to the information space. Okay. In conclusion, four key points. If you walk away and you take nothing else from this, these are the four things I hope you walk away with. Number one, documentation is a core part of your product experience. I will say that again. Information assets are a core part of your product experience. Also, a self-service information ecosystem. And I don't just

mean a knowledge base that can be clicked through or docs that can be found, but the other supporting assets cross-lin and brought into one place. These are some simple things that you can do to really empower people within your organization to do a better job representing your product, but also empower those consuming your product. Also, you don't need a huge team, just the right mindset, a bit

of information, uh, inspiration, make inspiration sexy again, mindset, and kind of rub that off onto others in your company. And lastly, in the AI world, I may be proven wrong about this, but at the end of the day, you are a subject matter expert for a reason. An AI can do all sorts of things. A large learning model can do a lot of things for you, but

what it cannot do is distill your subject matter expertise into something consumable for a machine and there we still play a key role. So no matter which direction your company is going to take with regards to AI and AI tooling and whatever role AI will play in your product uh landscape because it will of course you still play a key role as a subject matter expert in

distilling your knowledge in your mind out into assets that can then be consumed read and understood by AI in general. Okay, I hardly used 20 minutes. Um, I don't even think that there's a way for asking questions here, but maybe if there's questions, I can um, take them. There's a few extra minutes available. Know if anybody has a question. Yes, one second. I'll come down there and

then people can also hear your question if this works. >> thank you very much. >> Yes, I have a question. So, how much of this? >> Yeah, so the question here was how much of this documentation is automated? Not very much. So all of the technical documentation aspects, parts of that and also a lot of the reference docs are automated. But for the rest, there's actually product

managers that are contributing to the information each month on a monthly basis in a template. Like it's not a huge investment, but it's a template we provide. They literally tell us their new features. There's a couple of characteristics about those features and then our small but mighty content management team has a five-day window every month to take those new release characteristics uh enhance them with well better

tone of voice and consistency things like that which now AI is of course going to be supporting with and putting it into the CMS. So there's a mix there. I would say that it's a decent amount of manual generation but from the product from the product subject matter experts themselves and not just the documentation team. It's important to uh to be aware of that. Any other questions?

No. Oh, yes. Yeah. Really great question that you're asking. So, he says, "How do you come to a single source of truth?" Okay. I could easily fill the next seven minutes with this um but I will not. It's actually a very critical point right now because um I'll circle around to that answer. I mentioned about the AI work that we now have to do in that data

foundation. One thing that you'll notice is that even though we have all of these information assets in one place, there are still critical pieces of context that any kind of learning model would need about our product, but they're not in Backbase IO at all. So, for example, product strategy. We don't put our product strategy in Backbase IO. That's for us internally. that's for people in the sales

uh department to understand but it's definitely not something that we are publishing in this information platform but it's obviously critical context that you need if you're going to do anything with a learning model around answering questions about your product. So what that exposed to us is actually a blind spot of an additional single source of truth in a structured and standardized way. So what we're now actually

doing in this quarter is we are introducing uh an additional layer to this which is um what we're calling a central library. That central library is really nothing more than an aggregation and standardization of these key assets that are outside the scope of what we're generally producing today. And they actually serve as the spine I'm calling it the spine of our information world. And they become the

central source of truth upon which functional information is created. and additional assets are created. So in that sense there is a missing link that we have right now. So it's kind of two things but basically the other movement is about confluence. So we kind of laugh it off and I personally am also moderately annoyed about the amount of cleanup I have to now do. But it's a

fair point about a single point of truth because um if there are several little uh I don't know minions creating information in different ways to their own recipes to their own needs. Yeah. How do you uh coh create a cohesion around that and uh simplify that into a single source of truth. Well, we basically have a clear uh role and that clear role is if it's not

in backbase IO and it's not in the central library, it's not true. That's the line we're upholding. Okay, on that note, my time is up. Thank you so much for uh for joining. I really appreciate it. If you have any questions afterwards, let me know.