[Podcast] How Paligo is filling a niche in the CCMS market for complex documentation

Tom: My name is Tom Johnson. Today I’m talking with Anders Svensson, located in Stockholm, Sweden. Anders is a co-founder of Paligo, a popular online platform for technical documentation, and we’re going to dive into all kinds of interesting questions today.

Anders, can you just introduce yourself a little bit for audio for the audience here? Tell us who you are and what you do.

Anders: Sure. Great to be here. I’m Anders Svensson. I am one of the two main co-founders of Paligo and I was a consultant in this business for nearly 20 years working mainly with XML solutions, single-sourcing and helping customers implement types of CCMS solutions and so on.

I did that for a long time until I met my co-founder Frank and we decided to start our own platform.

Tom: Now, correct me if I’m wrong, but Paligo is about six years old now.

Anders: No, it’s actually just a little over four years old. We started in late 2015, we started Paligo as a company and it’s been relatively successful compared to other kinds of startup ventures that I’ve seen in the tech comm space that try to take off and then sort of fail.

Tom: Paligo seems to be successful. Can you reflect a little bit on why you think Paligo is succeeding in this space where others might not be?

Anders: I think what we’ve done is basically, we’ve found a niche, or a gap so to speak, that we think was not really filled. I know there are many CCMS systems on the market and many of them come out of Germany. They have some really big CCMS systems there.

Many of them are just really large behemoths though, and really expensive, and this is well known if you hear people talk about CCMS systems. They think of really expensive systems and they usually typically take a really long time to implement.

It’s not unusual to have ‌12 years of just deployment time. So what we wanted to do was to fill that gap on the one hand, make it more accessible.

But, first and foremost, we wanted it to be like a modern platform in the cloud. People expect to find any type of tool nowadays in the cloud, like if you want to have a project management platform, you have tons of those to use in the cloud.

But there was nothing we saw that we found fulfilling this need for technical documentation. So we basically wanted to do something that was as powerful as these existing CCMS systems, but really accessible in the cloud and instant deployment, and most of all, user-friendly. So getting really high user adoption was a really important focus for us.

We had seen in consulting days, that one of the main problems with getting a structured authoring project to succeed was getting user adoption because these systems were not really very user friendly. So I think what we did was that we made it accessible in the cloud and we made it really user friendly, taking advantage of the modern cloud platform. It’s interesting to reflect on, on this niche between or to have a CCMS that people can actually implement quickly that’s affordable.

Tom: Can you talk a little bit, let’s back up a little bit, for users who may not even really know what a CCMS is, let alone why they would want one. Can you fill in the big picture here and just give us some basics about what’s wrong with a help authoring tool? Why would somebody want a CCMS, what are they aiming for and what does it do for them?

Anders: So, I’ve written articles about this too but, basically the thing is, a help authoring tool has, you know, has a similar purpose in many ways. You want to reuse content and you want to divide it up into topics that are usable chunks of content. So yes, there are some similarities there, definitely.

But the thing is, when this scales, it becomes really difficult to manage and that’s when you really need a CCMS. Because if you start taking your documentation and you’re breaking it up into small reusable chunks of content, if you start at the macro level, you’re breaking down the documentation into topics for one thing, and you get tons of topics that you need to be able to keep track of and manage and so on. And then what a CCMS does, it doesn’t just go down to the topic level; it goes way more granular than that.

So a CCMS, a component content management system, keeps track of every single little component and that could be anything from a topic down to the smallest text fragment really or even single words.

So one of the main differences is that a CCMS is database-managed. So the database keeps track of all these little pieces where everything is reused, even where a single word or variable or a text fragment, exactly where that content is reused. And all these relations and that sort of control is what you really need.

When you start to scale documentation, if you have complex documentation, you need to single-source and reuse content, then you also need to be able to manage it like that.

So it’s that, and then the ability to collaborate globally, which you can do in the CCMS or especially a cloud-based CCMS. You can be basically anywhere in the world and everybody is working on the same content.

Tom: I find this interesting on this question of scaling because this is a question that many people have asked me around doc code. They say, “well, it’s fine for small kind of projects, but it doesn’t really scale. And you’re talking about scenarios where you have many, many topics and you start to reuse content. I’m wondering, at what point do you think companies would be justified in transitioning to a CCMS?

Are we talking about thousands of topics or just hundreds of topics? When is the right time to scale up to a CCMS.

Anders: I think it’s really hard to generalize like that. It could be, I mean, typically our customers will have thousands of topics, yes, but we also see customers with the smaller documentation sets. I’m not sure if they would reach more than 1,000 topics still.

But, I wouldn’t say it’s impossible that we have a number of customers that have hundreds of topics and still have this need, because it’s not all about that. It’s about, if you think about it, the CCMS is about content reuse.

So even if you did have just a few hundred topics that might actually become thousands of topics in your output because you’re reusing them.

The determining factor is if you have complex documentation, and by complex documentation, I mean complexity in some sense. So that could be, you’re documenting multiple products for instance and, and probably these products share some of the documentation, some of the content or it could be other multiple dimensions. Maybe you have just one product but you have multiple versions that need to be live in parallel. You need to supply customers with different versions of this.

For instance, if you have a software product, it could be in multiple languages or it could be for multiple audiences. It’s really common that customers will filter and profile content for internal audiences, support agents, external audiences, and so on.

So the common factor is, if the documentation is complex in any way, that’s when I think you need CCMS and single-sourcing.

Tom: Hey, thanks for unpacking that. I think what you say makes a lot of sense.

You know, you mentioned, “What makes documentation complex?’ You’re sharing content across different products.

You have multiple versions of the product. You have many languages. You’re  supporting different audiences. I think that’s a good way to look at it.

I think a lot of times when people look at technical documentation, especially in the space I’m at, where there’s a lot of developers who contribute. They really don’t grapple with more complex scenarios like this, right? Where you have reuse across these many different modes.

Tom: I kind of want to talk a little bit more about reuse. Because I was recently listening to a podcast with Mark Baker, who is retired but was still interviewed for a podcast, and always has good insights. He was a strong champion of reuse. But he seems to be heading more towards, or a little bit against, reuse at the granular level and I’ve seen other people kind of push back. At what level do you reuse content? Some people restrict it just to the reuse of topics.

How granular should tech writers aspire to reuse content? Should they be reusing content down to the sentence, or is that too arduous to try to maintain?

Anders: I think it depends partly on the environment you’re working in, but also it will vary widely from user to user or customer to customer. So I think I know definitely that many companies will have the need to reuse on a very granular level.

But the important thing is balance. And I wrote an article about this where I think the important thing is you have a lot of different tools in Paligo to reuse content. So they have the macro level on topics and even publications. You can reuse publications inside publications and so on.

So the macro level, and yes, many companies get their massive reviews from there, but then you can go down to smaller components inside topics and so on and you can go down to the text fragment, you can go down to variables. And I think the important thing is to keep a balance there. You shouldn’t really do it just for the sake of it, just because you can. But you really need to think about your information architecture and where you get the most benefit.

Many customers will see, for instance, some customers have a lot of variables and they really do reuse them all over the place, and it would be a massive work if they had to to write different kinds of content for this. You know, the, the typical copy and paste case that you wanna avoid.

So yeah, I don’t think you can generalize and say that that one or the other is better. It will be different from case to case, basically.

But, I think what we see mostly is that customers do use many of these features, but they won’t always use all. I mean, I can see cases where we’ve seen that they get a lot of reuse from the topic, reuse the publication, reuse maybe the variables, and then they could reach out to us and say, do you think that we have this case?

Now, do you think it would be a good idea to use the filtering techniques as well? And you can see that maybe they get, you know, a small fraction of a percentage of extra benefit from that, and then it’s not usually worth it but others will have the, the opposite situation.

Tom: Cool. Yeah, I am. I definitely want to follow up and find articles you’ve written on that because I think the balance is key.

I remember one time I was working on documentation that involved implementation of a product in three different languages in PHP in Java and C++.

And the implementation shared commonality of around, I don’t know, 70% was the same right?

You do these steps. But then it differed, obviously, the code samples differed, and I remember it was really hard to try to figure out how much should I try to be reusing content and at what point does it become too just cognitively difficult to try to like keep things synced across these different products.

So it’s definitely a challenge, and that’s really where I think technical writers hit their stride in trying to figure out the best way to reuse content when it becomes important and when it becomes too tedious. So I like that idea of balance.

Now, I do want to transition into another topic because we’re talking about reuse and Paligo recently integrated with Zendesk, which is a very popular support platform. I’m wondering if there’s opportunity to reuse content now between KB articles or other support articles and tech docs. And if you can talk a little bit more about just this Zendesk integration.

Anders: Actually, it wasn’t that recently, we introduced our Zendesk integration in 2017. But we’ve had that for quite a while and it’s been really successful. We did kind of botch the marketing of it though. But I think we were still lucky because customers discovered it anyway, even though we didn’t have much marketing at that time. So it’s really one of our most successful integrations.

And so when we did this, we actually took a decision. We wanted to integrate with the knowledge-based platforms and help desk centers in general. So, at the same time, we also integrated with Freshdesk and Salesforce Knowledge. So those have been going well, and especially the Zendesk one has taken off really well.

And I think that was a good decision because yes, I do see that there’s really, I mean, companies want their content in their knowledge bases in their support centers so they can deflect tickets, and so on.

But they generally see that to produce documentation on that platform is very limited, and they still have the same needs as companies publishing to other platforms, other outputs, or whether it’s PDF or HTML5 or wherever it might be, the need is still the same to reuse content, single-source it.

And so the, the difference here is just the destination, basically. So that’s what we saw. We can do this. We can provide this powerful platform for content reuse but still have them published to, if that happens to be their Zendesk Help Center, they can still publish it there.

And we have some amazing setups now from some customers that are, that are publishing, reusing their content into multiple products, into multiple Zendesk centers, reusing it for different versions for Australia, UK, US, and so on. So we have multi-branding to take care of that. And basically the driving force is the same. They want to reuse their content.

And so what you may have heard, if you heard some recent news about this, I’m not sure, but we do have a really big update to this coming out, which we call a Zendesk integration 2.0 internally.

And so this is gonna take it to the next step, basically providing the technical writer with tons of control for really granular mapping of your reused content in Paligo and where it maps to your articles in Zendesk.

Tom: I think that’s really cool. You know, I’ve always been sort of just perplexed at the splits between documentation and support in many companies. I’ve worked in support, and they always have their own world of tooling that is separate. And when they try to pull in docs, they end up just copying and pasting little key snippets related to friction points. They anticipate and it drives me nuts because, you’re just pasting that over. How do you ensure it doesn’t go out of date?

And you know, why isn’t there more integration between the two? I think there’s a lot of missed opportunity when support and docs are separate and it’s a difficult thing to conquer because the support people have different tooling needs. So it sounds like Paligo has got a lot of integration points to help meet support in the tools that they want to use.

Anders: I think that that the situation that you mentioned where, you know, you have these people working in support, cutting and pasting, and so on. That probably is something that evolves over time and it works up to a point. But then, all of a sudden, they find themselves having this really massive documentation and become a real mess.

And at that point, that’s when we usually see them coming up with a really complex migration project because they need to get out of that mess and, and get it organized.

Tom: I mean, I think a lot of companies accrue documentation debt for a number of years until they hit a crisis point, and then they suddenly have to do this huge project.

Tom: I want to talk about other fragmentation of tools. While we’re sort of on this topic, not just in the support space, but more in the developer doc space.

There’s a lot of fragmentation around API docks where you have maybe a Java doc that’s got its own output. You’ve got maybe a rest API doc with a swagger kind of output. That’s a standalone output. Then you’ve got your conceptual or how-to docs in a different tool?

Does Paligo have any kind of solutions to integrate some of these other types of API docs into, into one experience?

Anders: Yeah, I mean, we are well aware of the rise of API documentation, so to speak, and I know you write a lot about that. And what we’ve seen there, we hooked into this a while ago, started out just allowing users to embed Swagger output for instance. So they could embed it and automatically hook it into their their Swagger, Json or whatever it might be.

But then we got a lot of requests around this, and people wanted more about this sort of integration. So one of the things that we did recently was allow users to import their open API spec. So basically that means they can just import a Json or a YAML file.

And Paligo turns that into proper Paligo topics, structured authoring topics, and then they can basically integrate it with the rest of their documentations that I think that’s, there are a lot of players in the API documentation space. So we’re not really trying to be one of those tools and and compete on that level.

Where we see our unique selling point is basically what you just said, that the companies that have this really complex documentation, they usually need to integrate with the rest of their documentation.

So they have the user documentation, the admin documentation, whatever it might be, so tons of documentation. But then they also have their API docs. They want to integrate that with the rest of their documentation.

They can do that in Paligo now with the Open API spec import and so on, and keep working on it like that. Utilize the content we use in combination with this and that’s pretty cool.

Tom: I’m really happy to see that you’ve got an import for the open API spec. That’s great. And so, does that make the content in the open API searchable? I know that Paligo has Algolia-based search. If I import my Swagger file or open API file into Paligo, does that make it make each of those end points or parameters searchable?

Anders: Yeah, but I would say that basically, it all depends on what you wanna do with your content after you import it. So, I mean, we have many different kinds of output. And we have some HTML5 help centers basically creating an entire portal for the web.

And you can definitely utilize that and integrate with Algolia or elastic Swift type or whatever search engine you want to use. So that’s definitely part of it.

But many of them will also just use our API style output, which is more like a stripe like the type of three panel with the code switching on the right side, that stripe made popular. So it depends what they want to do with it.

But yeah, they would have all these possibilities, and in some cases, they might, if it’s a bigger customer, like we have some really large software companies. They might want to have a customized output with this and if they want to have, like one of our really large enterprise customers is using this and creating a Federated search with Algolia.

So they integrate both the documentation, and the rest of their whole documents set their entire site with a Federated search for Algolia.

Tom: Hey, let’s just define Federated search for those who don’t know. My understanding of Federated search is just search across multiple different outputs. Can you maybe just define what you mean by Federated search?

Anders: So basically that’s exactly it. The documentation that they produce in Paligo will just be one part of all the content that they want to search. So they may have, you know, content from marketing or you know, other departments that’s created in other environments.

They want to put all of this together in a large portal, but be able to search in everything, and they can do this with the Algolia integration. So we provide the part for Algolia that handles the search for the documentation, but that can then be integrated into the larger search for the entire portal that they have.

Tom: And a recent update, Paligo now offers faceted filters in the search. I was reading in recent release notes and I’m pretty excited about this. And this is especially applicable to Federated search if you have lots of different content types in there.

Can you talk more about what the Faceted filtered search provides, how it’s implemented, what is the user experience?

Anders: Yeah, sure. I mean, faceted search is something that’s fascinated me for a long time as well. And I wanna say that basically, you can use it out of the box. So if you want to, you can just basically enable it. And then out of the box, you use our taxonomy feature to tag your content, different categories, classifications, and so on. And so you decide basically what you will want to use as facets. And then this will automatically create the faceted search page for your HTML5 output.

But I would say in practice, the companies that are most interested in faceted search are usually pretty large companies with really complex documentation that they need to provide this filtered search for.

And so it’s more common, really, that they don’t just use it out of the box, but they want a sort of configuration for them where they can basically hook it into any kind of metadata. So if they wanna use the filter metadata to apply for this or other types of attributes, whatever it might be.

But the out-of-the box solution that anybody can just use and enable uses‌ taxonomy-based classifications. But basically, you have a lot of freedom there ‌to set this up. I think this applies to basically anything in structured authoring and you also need to do your information architecture. You need to figure out, you what classifications of our content make sense for us and build these taxonomy trees or whatever it might be that you’re using to create these facets.

Tom: Yeah, I mean, I think there’s a lot of information architecture in developing a taxonomy that’s gonna make sense, that’s gonna fit the product. And I like your tie back into the complex documentation you were talking about earlier with products that have different variants, different versions within each variant to the product, different languages, different audiences, different locales, platforms, all that stuff is essential right to provide filters for.

And certainly, if you’ve got documentation with that many different aspects to it, unless you have these filters, it’s gonna be really hard to provide a search across them. So I think that seems like a key component in this whole solution and something that fits the CCMS landscape quite well.

Since we’ve been talking about API Docs and some of this integration, I want to touch upon how people who might maybe have a Docs code implementation. Maybe you’ve got Jekyll or Hugo or Gatsby. And you know, you’ve, you’ve started small because maybe in the developer doc space, you just have one language, there’s one version, there’s one product, but now you’ve grown, you’ve got multiple languages, you’ve got a few different types of audiences.

Now, you’ve got versions and you, like, you need to scale up. How hard would it be for somebody to transition from one of these static site generators and Doc’s code models into Paligo.

Anders: Well, it’s really hard to, to give a general answer to that. But I think what we’ve seen is, we see this quite a lot. So it will usually be some sort of middle step where we transform it first in into maybe an html version. Something like that is an intermediate step. And then we will import that with one of the existing out-of-the box imports.

But I don’t think that you can. Basically, the companies that have this need realize that they will have some work to do. I mean, they can use the imports to speed this up. But any time you go from an unstructured environment into a structured one, you really need to do the mapping, so to speak, because you’re going into an environment where content is opposed to being semantically tagged up.

So you need to still do that work, but you can speed it up through the migration and usually that part isn’t that hard and it will usually work fairly quickly, doing this intermediate step, and then just import it.

But you would still need to, to make some decisions. What are we gonna map this to and probably some post-important work too, if you wanna do it really right to structure it up. So it really follows good best practice rules for how to work with structured authoring.

Tom: I think you mentioned, starting from an HTML output and using that as an import point.

I think that would make a lot of sense because all of these static site generators pretty much generate html. That’s their sweet spot. And html seems to be pretty standard to work with to import into other tools.

But as you say, if your source format isn’t structured and now you’re trying to reuse content, it’s goning to require somebody to think how you’re going to reuse that component.

And inevitably when, when you move into this XML space, which is gonna allow this reuse and more programmatic manipulation of content, ‌people will start to wonder well, ok, this is DocBook and we’ve got other XML formats like DITA. What do I have to know?

DocBook as I understand it, is a lot more flexible. It’s more kind of, I don’t know, it’s not as tightly constrained around the very specialized types. But what does somebody need to know about DocBook to transition their content into this space? Do they need to know the DocBook schema? What do they have to consider?

Anders: No, I mean, this is one of the things we really like that customers will come to us and say they basically love how Paligo has taken structured authoring and made it fun.

So basically, I think that is really great praise.

And so we’re really trying to. I mean, you’ve got the full possibilities of a really rich structured authoring XML content model and you can do pretty much anything that you would need. If you’re a hardcore XML user, you can do anything you need there.

But we’re trying to take the complexity out of it and we have users coming from really traditional environments.

If it’s Microsoft Word, or wherever, it might be that you take to this really quickly, there’s a little bit of a threshold to get over, get into the mindset of structured authoring and thinking about content in a semantic way and so on.

But once they get over that, and that doesn’t take very long, usually, it really comes naturally that you don’t really need to learn DocBook in any way.

And basically, just to make that clear with some of the misconceptions. I wrote an article recently about why we chose DocBook instead of DITA, even though I’d been working as a DITA consultant for many years.

And the thing we did was basically, we did a customization of DocBook, you could say, to make it topic-based. So it was more if people are coming from DITA, for instance, they will feel right at home because we have the same kind ‌of topic-based thinking.

What we didn’t want though, was specifically this topic typing, which we felt was just constraining. And in my experience, this was one of the big hurdles for customers migrating. I often talk about this as trying to force a square peg into a round hole and what DocBook differs there.

So if we, if we got the topic-based part where we split content into topics, have these reusable chunks. That was the important part. The topic typing part is just taking it a bit too far. It’s like saying that, OK, so you’re gonna write ‌instruction tasks. So you’ll only need these few elements. That’s the way in my mind, and real content, real live content doesn’t really work like that. It doesn’t fit into those neat little models.

So basically DocBook does have the same rules and Paligo does have the same rules in its customization of this content model where you do need to follow a certain structure, and you can’t really do structured authoring without having rules because that’s the core of the entire concept.

But we don’t take it that far. You have more flexibility. So if you’re writing ‌an instruction, you have the procedure element with the steps and so on, you should use that. But we don’t force users the same way to say, OK, now you only have this little subset of elements because you’re gonna write us instructions.

Tom: I think that makes a lot of sense. I like the balance between freedom and, and having some rules. And I agree, I think DITA takes it too far with the topic type, the specialized topics. And I know DITA has tried to move towards more lightweight and more general kind of approaches.

But even so, I agree with, with the analogy of the square peg in the round hole. That was my experience, and especially if somebody is in a Dax code environment, they’re used to having a lot more freedom to write according to the dictates of the content, not necessarily to the schema, but at the same time, as you say, you’ve got to have some rules or you can’t really do anything with the content, right? It’s some balance there.

Tom: And we’ve talked about a lot of things and, I just wanted to cover one more topic, because I know that this was a huge part of your recent release. You recently added 2-factor authentication, which I think is interesting. I mean, just having authentication itself seems to be a huge need. I’m constantly running into this problem at, at my work. We don’t have a great authenticated environment for users. We‌ have a tool we use, but it’s not great.

But you’ve, you’ve gone ahead and added 2-factor authentication for this as well. Just kind of curious, why the push for more security for documentation? Are you working with partners who have really strong security needs? And maybe you could just talk a little bit about that?

Anders: So basically, like I mentioned before, when we started out with Paligo, we initially started with an intention to fill this gap also for SMBs and maybe mid market companies, but as we’ve grown and added more and more features and so on, we are starting to attract more mid market and enterprise customers.

So yes, part of this, it’s not really about pushback, but part of this is the requirements from these kinds of customers. The bigger companies, they do have a lot of security requirements and we get these long lists of of security features that we need to fulfill.

So yes, this has been on the wish list for many of those, but I think it’s really more mid market customers really that are interested in this. Whereas ‌enterprises will really usually want a single sign-on, SSO. And we’ve had that for a long time, but the two-factor authentication was like an additional layer that we offered. And so basically, right now every plan has access to this and it’s up to them if they want to enable it or not.

But then on the higher plans, like the enterprise plan, we also have some additional features around this where they can have a global control over this if they want to enforce two factor authentication and so on. So it’s not a pushback but a need from our customers.

Tom: I remember I used to work at, at a company that was bought by Experian and one time we wanted to use just a, a simple tool to do some document review that was actually based in markdown and the security department in, in order to put the content on this third party host had this huge list of security requirements and we sent them to the to the vendor and they’re like, you’re asking for Fort Knox security and this is not the price point for that. It is totally not aligning.

And so I think it’s, it’s great that you’re able to provide the security that an enterprise would need based on probably very robust requirements, and yet not be out of the price range that people are looking for with this sort of solution.

So are there any other features that you want to talk about in Paligo or recent releases, or other other topics that we haven’t gotten to?

Anders: Yeah, I mean, one of the things that we’ve been investing a lot of time in is our collaboration features. So we’ve put a lot of effort into making sure this is also one of the things that comes out of talking to customers and, and customer requests over time to really simplify collaboration.

And I mean, we’ve had this for a long time with the ability to collaborate globally, doing reviews globally. I have real time updates on the same page, so to speak, but we put a lot of effort into ‌ improving that and making sure that you can have contributors working on the same page and basically an online editor just opens up, in context, in a really simple collaborator interface.

So that’s one of the things that we’ve been, investing a lot of time on and coming up, we have this big release. I think by the time this airs it might have actually be live.So in the next few days we’re going to have a release for our, like I said, we call it the Zendesk integration 2.0, that I think is gonna be really popular.

I know it’s going to be really popular with our customers because it really puts all the control in the hands of the technical writer. It’s like a cockpit, basically, for making sure that they can take their really complex documentation, and knowing exactly ‌what happens to it in Zendesk. So that’s gonna be really nice and you’ll see the release for that in a few days.

Tom: The collaboration piece is cool to see and it’s worth sort of commenting on because I’ve been doing some research on tools and I’ve always been kind of dumbstruck by seeing so many different companies using Microsoft Word, you know, and I never really understood that. I thought, “Are so many people using Word for their docs?”

And in my ‌latest tool survey, I realized that Word is often used in the same way that Confluence is often used for collaboration on documentation. A lot of times tech writers collaborate on docs or content using tools such as Microsoft Word Confluence, Google Docs, Quip, right?

Because you, you need to collaborate with others to create the content and you know, it doesn’t make sense to collaborate further on down the tool chain in terms of your, your publishing. For example, when I collaborate with engineers, we use a lot of Quip at, at my workplace, it’s basically Google Docs by Salesforce.

And yeah, it’s great to have multiple people in there creating and working on the content. And when it’s‌ mostly ready, then I transition it into mark-down and Jekyll, and we publish it and so forth.

But this ability to collaborate on content earlier in the tool chain seems essential. So does the collaboration, do the collaboration features in Paligo, allow that? That development of content that’s in an early state between different stakeholders?

Anders: This was actually the entire intention behind this development, just what you’re saying, basically ‌the typical case. And we did this development in close collaboration with one of the ‌largest software companies in the world, which is one of our customers.

And they specifically asked for this because they said, you know, we have, in our department, we have somewhere around 10-20 technical writers, but we have hundreds of developers that need to write and contribute content.

So what they wanted was specifically this, and that’s what we set out to develop. Basically where you can have a core number of technical writers that do the heavy lifting, the bells and whistles, and, you know, all the fancy reuse techniques and so on.

But then they can just get their content from these. From their engineers, usually just providing them with the publication or an assignment, whatever they wanna use, whatever workflow fits them. And they get into this, they have these light licenses, we call the contributor licenses.

So they get into this light editor with the full context, just an embedded editor, just clicking and writing down their API description, whatever it might be and then the technical writer gets it back and can add all those bells and whistles basically.

Tom: You know, I’ve had a longstanding interest in Doc tools, and I know I’ve written a lot on my blog or I get excited about the Doc code space and all these static site generators.

But I think that a lot of people don’t realize ‌how expensive, and by this, I mean, time consuming, how expensive a Doc code implementation is like. Sure it’s easy to download an open source tool and ‌generate ‌an html page. But when you start to add in other requirements like, we need to localize this, we need to generate out a PDF, and we need to have a robust search and we need to authenticate prerelease beta partners and we need to support multiple versions. It’s like the time it takes to try to figure out how to do this in something like Jekyll is insane.

And this is why I often think, let tool vendors provide the solution ‌and not spend all our time because tech writers, we don’t get paid to develop the tools.

Usually we get paid to write the content, that’s what people want, they want to see the content and they expect it to look professional and it requires a tremendous amount of UX talent as well.

Even if you have a UX resource, that UX resource is not there for the life of the project.They may hack out a solution in Gatsby and then be done with it and then you’re stuck trying to figure out all the details. So, you know, I’m actually a huge champion of third party solutions and full doc tools where you can implement them.

So, you know, I’m glad to see Paligo as succeeding in the space because we definitely need more cloud-based robust tools that can handle all these more complex needs without costing half a million dollars. So thanks for providing, the solutions you do and you have a lot of industry expertise.

You know, you’ve definitely been in this space for a long time and you’ve been inside many doc departments and seeing their challenges and scenarios, and you’ve been crafting solutions for those. So I think it’s great that you bring your awareness here.

Anders: We’re trying to build the tools we always wanted ourselves.

Tom: Well, Anders, thanks so much for coming on to this podcast. And if people want to learn more about Paligo, where would you recommend?

Anders: They go, they just go to Paligo.net.

Tom: All right. Thank you so much. And you’ve also got a blog, you mentioned, you mentioned several articles, maybe people aren’t that aware of your blog? How do they find‌ it? I’ll put links to some of these references in the show notes, but in general, how do you read the Paligo blog?

Anders: So that’s just https://paligo.net/blog/ and they’ll find it right there on the home page as well. I would really love to see people finding out about that. We’re starting to produce more content.

Now, we we feel like basically early on, we had mostly product updates, but we’re now trying to provide much more significant content, hopefully, for people in the space and interested in structured authoring, single sourcing and so on.

Tom: Great. Well, I’ll definitely link to that again. Thanks Anders. I appreciate your time and all your insights.

Anders: Thank you.