Zohra: 0:02

Hello friends and welcome to season eight of Inside Tech Comm with Zohra Mutabanna. This season features a collection of conversations that the ideas, challenges, and opportunities shaping technical today. From AI and content strategy to leadership, product thinking, and the future of our profession. Each episode offers a fresh perspective from people doing the Let's get started. Season eight is proudly sponsored by LavaCon. Use discount code ITC26 to save $200 on registration for this conference. I'll share more about LavaCon later in this episode. Hello listeners, welcome to another episode. Today we have from Fabrice Lacroix. On this show, we are going to be exploring how made-to-order rather, bespoke products, are changing content strategy and modern content delivery. And then broaden the conversation to what those as AI mean for how content is structured, delivered, and governed. With that, Fabrice, welcome to my show.

Fabrice: 1:15

Thank you, Zohra. Good morning, and thank you for having me on your show. I'm excited to talk about this subject because I think it's pretty uh both a long-term subject and quite edgy as of the new technologies that we have today. I think that's uh there's an opportunity to revisit the way we tackle long-existing problems for technical So interesting discussion. I'm looking forward to it.

Zohra: 1:41

Absolutely. And I'm looking forward to it too, because I have this will be my first conversation where I'm exploring bespoke products where the documentation is highly contextual. And that's what we're going to dive into. Fabrice, introduce yourself and tell us a little bit about your work.

Fabrice: 1:57

Sure. So I'm Fabrice Lacroix. So by my name, you can see uh here that I'm French, my as well, probably give you a hint. I'm the founder and CEO of a company called Fluid Topics. So we are a software vendor, and the mission of Fluid is just reinventing the way people, well, people will see people means may start being AI agent as well. So search, retrieve, consume, interact with product technical documentation, so complex content most of the time, and with a goal to be achieved. So there's a reason for getting to that content, whether learning, it's servicing a product, supporting customers. So there's always some an operational goal constrain behind that. And it's about trying to make people more efficient at the to be done using that knowledge. Thank you.

Zohra: 2:57

What brings you to this? We are going to definitely explore the bespoke product and the documentation. But what brings you to this conversation about content strategy and modern content delivery?

Fabrice: 3:09

Well, first, probably start with how we created Fluid how we got there creating the company. The company was that this company that I run was initially focused on search technology. And then for any types of use case, so from e-commerce to major publishers, so not specifically focused on tech And for ourselves, we developed an internal product for own tech doc for the product that we had. And we did it in a way that we realized that the tool we using for writing our documentation had structured chunks in it. And that was like 15 years ago. And instead of generating PDFs, we could use those topics, of content, and publish that as it is and render that So it's like we sort of did it for ourselves as an internal project, and we saw our own customers say, Oh my god, I love what you did for your way of delivering your own content. And so we realized that there was something that we had inconsciously or by chance invented something that was to people by the novelty and the innovation it was bringing instead of generating PDFs. Remember, that was 15 years ago, or long style HTML that was a bit clunky. So that's how we started the companies. Like that, we were in the content in search, in content but very generic. And we decided to focus on only product knowledge and that because that was for sure. I mean, delivering PDFs to people, I mean, it's a nightmare for most users to navigate those PDFs and know the should be used. And most of the time they download the PDF, they put that on their laptop so that if you did update your content, they come back to your website to download the next version of the PDF, even though the product may be evolving. So you see your own customers starting using knowledge is deprecated, but because they have that on their to the delivery method, in fact, you create this disconnect between up-to-date content and what people got. So we saw an opportunity to really solve key challenges, and it started with ourselves, and then that became the of the company.

Zohra: 5:28

That's such an amazing story. You literally became you solved a problem, and then you how this would help others. Yeah. So you were your first customer in a way.

Fabrice: 5:38

We were our first customer without knowing we were.

Zohra: 5:42

That's a fascinating story. We are going to be talking about bespoke products.

Fabrice: 5:46

Yeah.

Zohra: 5:47

Tell us what in your context bespoke products are, and how can these products be?

Fabrice: 5:56

If you look at many, many industries, how they have evolved over the past 50 years. It's like most, whether it's manufacturing or software or you were spending two to five years designing a product, up your production system, and then you ship that that's the same product for everyone. It's like the Ford model, it's like uh the color you as long as it's black. So it's like one million of the same product, the same for Some industries were more rapidly shifting to more customized products, but I think that has become the norm almost for reasons. Whether you do smaller batches of products because of you are you cannot build a product, imagine a product and that product for five or ten years. See what I mean? It's like even if it's somehow the same product for you do smaller batches and you have to change, adapt your every five, six months, a year, because then your competitors are innovating. So which means like you still you start having more and more diverse products in your product line, and especially you to support products from two, three, four, five years ago. Even though there were the batch was the same for every at that time, you had five versions, five batches of new in the meantime, and then you start you end up having over the world tens, hundreds of different product variants and to support and maintain. So it's the nature of innovation, globalization that puts company in this position that they have to innovate very You have other uh industries where made-to-order is norm. It's like if you take aviation, it's like an aircraft, like an aircraft, you can uh in some cases choose the jet you put in or the uh the flight entertainment system or the seats and the whatever. So an aircraft is almost something that is unique by its And then you have products that are more or less anyway evolve over time. And even though, if at the beginning you produce 200 that are the same for every customer, due to maintenance because they have a long life cycle and they are used over 30 years, they are retrofitted, maintained, serviced, are changed. And they tend even your 100 products that were similar tend to diverge in configuration. And it means that if you want to maintain that product and send a technician, and the technician has to service that they have to make sure that they use the knowledge that with the configuration of that unique product that has become unique over time. And we do have customers like that that, for example, uh one I like, and it's it's a known one, and they do it's not nothing private. We have KONE, the elevator maker, okay? So they are doing elevators. When you build an elevator for a building, it's almost for that building because the number, the floor, the number of floors that you have, the size of the cabin, everything, they have a range of different engines, ropes, trolleys, command control, everything. It's and then they say we take this, that, and that, and that, and that becomes that elevator for that building. And maybe you have six elevators in your building, and at beginning, it's six times the same one, but an elevator lasts, I don't know, 30, 40, 50, 60 years. So, and the six elevators that you have in your tower over 50 years will become totally different elevators because they are maintained. And for one, you can change the engine, the electric and for the another one, you will change the door opening on the fifth floor. You see what I mean? So the system as a whole, each elevator is a system that and has its own life. So if you have to service that and you send someone on the and you say, you have to fix that, I have to do the yearly checks, they have to know what to check and what they are, the instructions that map with the configuration of that that they have they have in front of them. So you see, by nature, products are either make to order, maybe at the beginning, similar but diverge over time, or sometimes really custom products like aircraft from the out from the outset, they are just made for that customer with unique configuration. That's the context, I think. Yeah, it's very complex. Yeah, and the context is accelerating due to many factors. You have this industry for zero thing. It's like now you can order the car that you want. You have 20 options in your car, and you guys I want this that option, and I want the electric windows, and I don't that uh very system, but that sound system, blah blah. So you customize your car when you buy it. And you know that in your car, if you take the leaflet that is in the that's provided, it's for every model. So you have to know what you have. You you know that everybody knows that the leaflet have in your car is about 200 pages, but maybe only 40 pages apply to your configuration because it tells you for doing this for every variance, every but you have to out by yourself what you have in your car and what pages you have to use for, I don't know, changing the battery of the because when you come close to your car, it's opening because it's recognizing your key. See what I mean? But you have five models of that, so you have to know which one you have. We know that. I mean, even for this type of products. And because that industry has become more flexible in its of producing bespoke products, including cars, I'm not about here aircrafts or elevators, which are very, very B2B products, even for B2C products, they tend to be highly configurable. And due to new production capabilities that we have, industry 4.0 and all that, and you have software, more and more as well. So overnight, by upgrading the software, like I don't Tesla does overnight with firmware upgrade, then you've got new capabilities in your in your car. So because of that mix of software everywhere, modules that can be added afterwards or activated afterwards, custom that you do at ordering time. So all of that is the new environment. That's the thing. It's not, and that has nothing to do with documentation. It's the product themselves, it's the industry itself like that. So now the challenge is how do we make documentation adapt these new challenges so that we serve the end customer, the technicians, the support agents, so that they be they become more efficient without being lost with a huge amount of Everything is documented, but you have to know what to use at what moment to make sure that you answer, you act in a way. So, how do we adapt us as an ecosystem? I don't say us as Fluid Topics, we are part of that How does the product knowledge ecosystem, the tech doc from producing the content to delivering the content to the content can adapt so that what we do reflects with this new way of producing product, generally producing uh manufacturers, uh manufacturing and software. And we keep we can sustain the pace of evolution and and the operational needs of the people that then run or the products. That's the challenge.

Zohra: 13:27

Just listening to the complexity of the options that can how one has to create content, a variant of that current that product is just mind-blowing. So, what does that variable really mean for the content that these bespoke products?

Fabrice: 13:46

I guess you can look at the now the ecosystem can look at from different angles. Either you start from the people that consume the content, and then you work, you work backwards and say, what's the on how I should produce that content, or you go the other and you say, uh, how can I adapt the content I have, putting technology on top that makes that content more dynamic, custom as well, so that it can adapt to the product and uh people just have the instructions that are relevant to configuration that they have. So you can go both ways, starting from the consumer of the or starting from the production side of the knowledge, ways are valid. I think probably we could start by looking at how the average way of doing is or was for many, because there's an history behind. I mean, if you write your content, say with Word, because you had one manual for one product, okay? And you were releasing one product every five years, every years in your every two years in your company, and you had 10 manuals for that product, and then it's two years and then you you release a new version of that product. Probably what people were doing is like cloning the doc, it's like duplicating the doc, copy-paste everything, and then they started editing the word files to change what was new to the product. So remove sections, chapter for features that had add new sections, new chapters for that describe the new of the product, or adapt some existing content because there was a lot of similarities between the two products to the two versions. So it's like an incremental work, and you would like duplicating that content. So it works, and probably that's the best way to do it, if you release a new product every two years, why bother up super complex systems with structured content? Because the costs and the complexity of maintaining structured content with managing the variance into your CCMS and all that comes at a cost. There's a complexity, there's a learning curve, there are tools, everything. And if you don't have that need, probably be pragmatic. Whatever tool you use with more like desktop publishing, I Word, not to mention any brand here, but I mean we can. I mean, Go starts with can be from FrameMaker to HTML like based products. So all these products that are a bit more sophisticated more valid for tech doc than Word is, but still are very oriented. And you you would be on a approach, the strategy would be and adapt. The problem is that if the the pace of really start then that becomes a bit difficult. And especially if the product that you had you had selled years ago start being keeps on being maintained, and uh something broken in your documentation, you have to open all the files in every past version of your product to fix documentation. You see what I mean? It's like, or if the I don't know, the lowest change, or if you change the name of your company, or whatever legal or security thing that you forgot, you have to add some warnings, whatever in your doc just to protect you from or whatsoever. If you have duplicated your doc 20 times and you had need fix one, you need to fix 20, in fact. So that's where people that already had this challenge of variants, many products switched to data and structured and componentized content and documentation so that you don't copy paste duplicate. And I think the more you are, the more sort of reuse. I don't like that even I don't even like the term reuse in it's more like even reusing the same doc sometimes. People think of reuse because for the same doc set, the knowledge, same paragraph may be used multiple times. It's like reusing a cross product. That's see what I mean. So it's really a reuse at scale, at large, at long time. But I think the more you move towards this complexity of products made-to-order products, the more structured is uh is an obvious way to start. I mean, there's no way you can tackle generating bespoke if you don't like, if you don't have chunked content, so content, topic-based content. It's pretty obvious. No, uh shouldn't be a surprise to anyone I say that. But the moment you transition from document-oriented to structured content because there's an acceleration in in the pace of your product release, or your product your products become more and more made-to-order and specific to customers, you're facing the moment at which you have make the decision on when to switch.

Zohra: 18:35

Yes.

Fabrice: 18:36

And the switching cost, and I'm not talking about the itself, just the switching cost, that moment where the decision to say we need to move to structured content, a tough decision, I guess. Because now I guess you you you know that. I mean, we're on the authoring side, which is less uh we are more on the delivery side, as you know. We understand why people come from unstructured content, copy paste, because of the slow pace of product release, less and all of that. But with the evolution of more made-to-order, faster shorter release cycles and all of that, I think that every company is almost forced to move into this direction, meaning to structured authoring, which, by the way, helps reusing content for variants of product. You still have to create, take a topic, and if some of the that is contained in the topic must be adapted for the next version of the product, you still need to do it, but you duplicate a topic or edit a topic with conditions in the topic and not the entire document. So that's one. Now, if you look at it from the delivery side, even though had customers that had switched to structured authoring, were still generating one manual per product or per variant or per method of the product. So it means that if you were KONE and you have uh, I think they have about 1.6, 1.8 million elevators installed Okay. So I think that customer, because I I could mention any uh, I don't know, an aircraft like Boeing or Airbus or whatever, but the numbers are smaller, and people would say, ah, still tackle the subject manually or with something a bit but I mean homegrown system. If you take it at a larger scale, we're talking 1.8, 0.7 uh this different elevators. What is the solution that you have to make sure that a will uh can work? How do you deliver that contact? You have two options. One, for every elevator, you generate a dock set that to that elevator. So imagine that from everything from the engine to the control to the whatever, everything cumulated, you have to whatever, 10, 20 manuals, each being 200 pages. So it's like about five, let's say 5,000 pages. I don't know, but I give you numb. I mean, you can easily imagine 5,000 pages for everything one elevator for all the subcomponents there there is in. So you you generate 5,000 pages of 5, 10 documents, but now you multiply this by 1.8 million. So you have to generate 18 million documents, which like a billion pages. It's a bit of the same content, but always for that engine that uh door opening mechanism for that floor, and then repeat that. And if you have a hundred thousand elevators using the same engine, that's the same content, but that goes with other of content for that configuration, that product, not but you multiply over and you generate and you spend your time publishing, maintaining, publishing somewhere, storing billions of pages, tens of millions of documents, just so each elevator has a doc set that is representing, that is for that. At elevator, because it contains only the content that is the configuration of that elevator. And when I say elevator, you can mean aircraft, car, truck, whatever, a CNC machine, software. So let's take elevator as a generic concept. So that's one. So you see the cost of generating, storing that, and because every time someone maintains that elevator and a piece, a part of that elevator, you have to regenerate the documents so that they reflect the changes that you made on the product itself. And if or if uh the documentation you add some security when changing that electric motor motor, if that motor in 200 elevators, you have to regenerate 200,000 times the that contains this security warning because you change only. So you see the scale at which you end up if you generate and then you store that somewhere, and then you can tell to your technician, Bob, when you go inside, you check the number, the ID of that elevator, and you go to that folder whatever, and then you got all the docs, and we are sure they are just matching that elevator, and then you can the elevator without using the wrong information and is there. I mean, it's impractical, it's intractable. You cannot manage and generate tens of millions of and billions of pages like that. So, what's the other way of doing? You do differently, you generate a manual where you have for all the or every electric motor has its own document 100 or 200 pages, every door opening mechanism, every cabin road, every command control, blah, blah. So you just sort of print out, generate everything per unit, and you say to the technician, well, select from the what you need. But how does the technician know what's needed? Or you put the load, the workload, the complexity of the right information, you put that to the on the Because you ask to the technician to make the effort to from the bookshelf the right document that is matching the that the it has in front of him, which is not very convenient because they don't always know what's in that elevator. And they have to start by looking at the configuration and then say, okay, it's that engine, so I need that You have to make sure to pick the right one, the latest one, and not the one they have on their laptop. So there's a complexity that becomes an operational and that's something you want to avoid as well, because you want to deliver the exact information to the technician so they don't have to think of it. And that's where we say, okay, what would be the best case? It's like you don't pre-generate, you don't generate a just like the dream, and that's why I said earlier on you from the consumer perspective. You are the technician having to service the elevator, the the car, whatever. You are in front of that device, or you know the you scan a bark a QR code or whatever is the unique ID of that and you have a database that says for this range of product, from that number to that number, or for that unique ID, this is the configuration, this is what's in the product, this the hydraulic pump version, this is the model, this is motor model, this is the whatever. You take that as a description, and then you you take and you dynamically render manuals that contains exactly matching that description of the device. And you do that on the fly, real time. So there's no pre-generation of content, there's a manual that exists on paper in HTML, but you just take the content on the one side, the description of the elevator, and then you dynamically render something that is matching configuration so that even if the document the of the system is changed in one minute, then because it's all dynamic and real-time generation, real-time rendering by the pieces of content, then you've got something that uh uh that people can rely on. They know it's up to date. So that's the idea behind like write the knowledge, write the knowledge at a level of granularity that reflects the that could be the variants of the system, and have a somewhere that describes for each batch of product, unique whatever, the list of components, the BOM, the bill of of that system at a high level, and then render the doc with that information.

Zohra: 26:41

The content strategy conference taking place this October North Carolina, with more than 70 sessions and workshops speakers from companies like Salesforce, TikTok, T-Mobile, and LavaCon brings together content strategists, documentation and content professionals to share practical ideas you can apply right away. And yes, it's known as the Fun Conference too with networking therapy dogs, comfort llamas, storytelling, and karaoke. Use discount code ITC26 to save $200 on registration. For example, when you talked about structured content itself, and 15 years ago, we started with PDFs and then we started thinking about content reuse or componentization, but granularity. I would say granularity became very critical as we started and chunking content, topic-based authoring, and just the of not just a human career, for me at least, but just the of the process of content development, curation, and delivery. But then I feel thinking from a content delivery perspective and then thinking backwards, what the impact and what technical how we try to solve that problem. I think that is so essential. It's not just writing and pushing that out into the world. There is this complex problem solving that happens. And from my personal perspective, that's why I said it almost encapsulating what a journey for a tech writer looks

Fabrice: 28:14

So yeah, I'm not inventing, I'm just describing what

Zohra: 28:17

Yeah, exactly.

Fabrice: 28:18

It's just like, okay, that's the evolution. Now, what is interesting, if you look at it from a content at a deeper level, for example, you started componentizing chunking your content for reuse and maintenance of that Interestingly, the way you chunked your content and the way you designed the grain, the granularity of your content was probably not driven by the delivery, but how much you could reuse and you were chunking it alone. You say, Oh, this paragraph, we are going to reuse that section, that section, and that section. So let's try to factor in that paragraph. And then that became a topic. So the topic, the granularity of your topics, grains was driven by authoring optimization, regardless of the itself, which is particularly true because you could PDFs, not from Word or whatever document-oriented system, from data. And initially, when you look where data comes from, I mean, 90% of the companies switching to data 15 years or 20 years ago, maybe probably were still generating PDFs data. So the move to structured authoring was not driven by what I described, this bespoke product, but more like optimizing authoring or versioning and keeping versions and avoiding copy-paste, but more like from an authoring optimizing your job as a tech writer, I would say. Okay. If you look at it now from the subject of today, which is products, the granularity of the content at some point has to match with the granularity of the subsystem of that can be changed and evolved over time. So there are two levels of granularity that needs to be or contains, like a Russian dolls. It's like one is the granularity that you need as a tech to optimize the maintenance of your content and the content in 20 places when you change something, which makes sense. But as well, you have to make sure that you have a that can be at a higher level, the way you do the maps or submaps, for example, that say, okay, now I have a section something that is the boundaries of that are for this pump, that hydraulic pump version, that version. See what I mean? Because when you start generating dynamically rendering serving content to a technician for matching the of a machinery you have in front of you, the granularity as well must must exist for at the level of the BOM, the bill of material of that machine. So there's an enlightenment here to be consciously well. And I think it's more maybe more maybe at the map level or submap level that you that you should manage that. And you should need to design maps at some level that everything related to that pump model, or these pump with the subtopics and metadata describing which topic to what model. Because metadata becomes a key subject here, as you can I mean, everybody, I guess, in the audience started to that oh my god, how do you describe that that topic applies to that version, that subcomponent, that version of the pod, that engine motor, that whatever. Well, it's all metadata driven. It's about tagging content for that. So, but again, you put metadata, you can tag content if the content is consistent for that tagging for when you tag it. You cannot tag something that contains, I mean, or you put 20 tags if it applies to 20 variants of the product, but if then it mixes up a bit. See what I mean? So the chunking as well has to be consistent with the way are going to tag your content, and you are going to tag content to describe, to map to the components, the hardware components, the BOM of the system. So that becomes a key subject as well. This is what is the tagging strategy that we need to How should we tag content so that then we can dynamically those pieces of content? I mean, dynamically or not, by the way. I mean, if you were to generate a PDF that contained the information for that product, you have the same issue. It's not because we do it dynamically that you don't have the same challenge if you want to pre-generate the doc and 20 billion of pages or 1.8 million sets of documents. You would still have to build the documents that contain what's needed based on metadata and mapping metadata with and configurations of the products. But we also know that it's stupid to pre-generate. So the the metadata and the need of tagging and the need of structuring content to align with the modules of the and how that those products are built has to be taken in the content architecture. And then whether you pre-generate or do dynamic need that.

Zohra: 33:22

Yes.

Fabrice: 33:23

But now that we have that and the product becomes so fast and it doesn't make sense to pre-generate everything, we can render those documents on the fly as well.

Zohra: 33:32

We started this conversation. You touched upon now, we have AI on the scene that's going to consume, and generate. How do things change here?

Fabrice: 33:41

I think that makes the what I described even more Because imagine that an AI system assistant or intelligent that do maintenance or prepare maintenance or whatever. We know that AI is good, but it can hallucinate if you too much content or if you provide that becomes the I mean, you remember the the two things I said: either you pre-generate everything or you pre-generate nothing, but got a manual that describes everything from all the in 20 variants. Is that your base PDF that you use for fitting AI? The AI may start hallucinating because it starts pieces of information because it doesn't know exactly the of the elevator. See what I mean? So that's even more true. I mean, you can expect, and even that is wrong sometimes. You can expect a human to sort of filter out while reading and say, no, this is not the the version I have, this is not the car I have. I don't have that option in my car, so I don't need that. See what I mean? That's what you would do when you look at your car leaflets say, no, no, I don't have that option, so I don't have that. Let me look. No, it doesn't look like my audio system, so it's not this You move to the next page and say, Oh, looks like my my sound system I have in my car. So that's what I was looking for. So you do something like that, and as a human, you start out from a large manual what's not relevant and what's to focus on what's relevant and looks like the context in. The problem is that if you take the same leaflet and you it over to your AI system and say, How do I do this with my audio, my sound system? And there are 20 sound systems, different sound systems in that leaflet, how can you expect the AI system to make it's using the right piece of information? You take a huge risk. See what I mean? It's like uh and even if you say, I got this this sound and this uh this is the documentation for all the possible systems, you have to make sure that the content is organized in a leaflet so that it's not ambiguous to the LLM and make sure that the LLM use the right one. So if you want to avoid that risk, just provide to the LLM what is exactly the content that is matching the configuration the car you have, the elevator you have. So filtering out content before handing over content to the AI system for helping you do things or diagnose or give you a solution is even more critical than it is with humans. So contextual documentation, contextual knowledge, context, the fact that you know the configuration of your your elevator, and you know exactly what you have in front you, and then retrieving exactly the content, all and only, it's like the truth, all the truth, only but the truth, and over to an AI system only the knowledge that applies to the context you're in. If you want to avoid system, and then AI becomes pretty Most of the problems you have with AI nowadays with the LLMs comes from overloading them with too much is generic or not applicable, like all the models of system for every Tesla model or every car model that you and not the one you have in front of you. So you have to filter out and select the contextual that you hand over to the AI, even more than with humans. So what we describe here, managing content at a granular correctly tagged, so that it can be retrieved and served in a contextual manner to an AI system is key to AI performance.

Zohra: 37:14

Basically, what you're telling me is dig into the values skills that you have developed traditionally and apply more strongly as even more.

Fabrice: 37:24

Even more, yeah. I think that's going to be. That's a great moment for the tech writing community because believing that, and that's that's interesting because if look at many companies, how AI started two years ago, it's like IT people say, oh my God, it's pretty cool, it's techy, we're going to do it. And most of the AI projects that have failed in many were not due to AI itself, nor the skills of the tech people that developed the product, but the fact were using like PDFs and collecting everything they could in the company and building semantic indexing around themselves, or putting all the files somewhere in a copilot system, but without the metadata, the granularity. So the context was a bit blurry to the LLMs, the retrieval blurry, and what was handed over to the LLMs, in whether RAG or agentic, was not fully relevant content, applicable content that was the content you needed in that context. And that that is what makes AI hallucinate, meaning not invent hallucinating, I mean give you the wrong answer you you give it the wrong the wrong context and the wrong Right. So it's key that tech people, the tech doc community comes into this AI discussion around the table and say, guys, it's all about the col it's all about the content. It's not about the technology, it's not about the AI, about the LLMs, it's not about training or whatever. Nobody trains model. It's all going to be part of products like ours to prove, give the AI. It's all about what's the quality, what's the tagging, what's the granularity, how we tag our content, how we've put on our content so you can grab the content by the right handle to have the right piece of content. So that becomes a content architecture challenge, knowledge management, content management issue. You used to do, but that was something you were doing for as a technical group for optimizing the way you work. And but you can generate, you can spend countless hours crafting your granularity of your content and tagging your but that was not visible and useful to anyone because when were generating a PDF at the end of the day, all that was flattened, all the metadata that you would have put and there was more use for you for generating the PDFs and right different versions of PDFs, but it was more like a to an end than the end itself. It's not a means anymore. I mean, metadata are not the means anymore. They are the end of the, they are the solution of the So you see, whatever you've done over the past 10, 15 and you know how to do, but you were doing that for you more efficient and managing better your content now the key to the success of AI. So that becomes a necessity, not a means to an end.

Zohra: 40:22

We are almost at the top of the hour for Breeze. Is there anything else you would like to add?

Fabrice: 40:28

I think the the type the challenge for the tech writers and the the tech the tech doc community is how can you make people understand that you have the solution to something they don't they can't stop without you? See what I mean? How get how do you get a seat at the table? How do you voice out that guys, if you feel AI is a complex, then it's not complex. What is complex is content, not AI. So you have to be considered as the experts. You are the AI experts in a way. See what I mean? Because the technology is so good now. I mean, LLMs and semantic indexing and blah, blah, blah. And that's becomes standard in every platform like it's not a technological discussion anymore. So, how can you get people to understand that in your I think that's more your the challenge that you have. How can you make people get you back and say, okay, we need you now, we need you to work on that subject. We are going to almost hand over to you the AI, these AI we're working on. We need you being leading the project almost. And I mean, that's probably we're not there yet. I feel that for many companies it's still like um an IT which I don't believe it is. I think AI is not about, I mean, at least assistant around knowledge and all that, building a chatbot and your doc or your support website or whatever. I think it's not a it's like 10% IT, 90% content.

Zohra: 41:54

So I think you made a strong case, the why, why it is not IT.

Fabrice: 41:59

Now, how do you make people believe you? Because when you claim that, you preach for your yourself. So that becomes less like, okay, they want to be part of But I think there's a we have a moment here where we'll see the companies that understand that the complexity and the success depends on the content, is on the content side, not on the tech side.

Zohra: 42:23

And probably this is a moment, and there are companies that recognizing that. And with that, I'm also seeing an evolution in the roles and away from just technical writing. Nothing wrong with just technical writing. I think there's there's immense respect to that. But with more dev and release roles combining together, content engineering, content strategists, I think this is where you can make the case and you should make the case. And you are helping with that conversation.

Fabrice: 42:52

You should make the case. It's probably one of the most, I mean, tech writing and managers are probably one of the most strategic roles, in a in companies right now for achieving AI-driven And you see, when people thought that AI would start like, we don't need tech writers anymore, we have AI to write I think it's wrong. Internally, we double the size of the tech writing team. We did the opposite. With AI coming, we understood the need of having better more content, tech content, documenting everything knowledge, LLMs don't have access to your brain. They have access to the knowledge that is being written So everything that is implicit should be written somewhere that it can be fed to LLMs, because LLMs don't go to the machine and speak to their colleagues. Everything is about needs to be written down, properly structured, tagged, and that requires more resources, than many companies had invested in in the past. And they need to reconsider the strategic and the importance of content in their AI strategy and the to this digital transformation. So I think that's that's the key point here.

Zohra: 44:09

And on that note, Fabrice, thank you so much for this amazing, conversation. And I hope you had as much fun as I did.

Fabrice: 44:18

I did, Zohra. Thank you so much.

Zohra: 44:21

Thank you for listening to Inside Tech Comm. If there's a guest you would love to hear on the show, please let me know. And don't forget to follow and catch every episode on your podcast app. See you next time.