<div id="readability-page-1" class="page"><div>*This is the English version of <a target="_blank" rel="noreferrer noopener" href="https://toss.tech/article/technical-writing-2">a previously published article</a>.<h2 id="3d4a360d-33e3-8090-a09c-d06bca2c1b45">What It Means for a Technical Writer to Be a Product Owner</h2>Earlier, I broke down the work of Technical Writers (TWs) at Toss into four areas. The first was building products. But what does it actually mean for a TW to build a product? Let me start with my own experience.I currently lead a product team called the Knowledge System Team. I work alongside developers, designers, and TWs to set the direction of our products and decide on our roadmap and priorities. I interview users directly and bring those insights back to the team. I plan features and sometimes build them myself using AI tools. In other words, I’m not simply someone who communicates documentation-related requirements. I work as a Maker who makes product decisions and helps build the product itself.So why are TWs building products?It comes down to what our product is fundamentally about: documentation and knowledge. TWs have spent years thinking deeply about questions like why some documents are difficult to read, what makes a good document, and how information should be structured so that AI can use it effectively. Over time, we’ve developed our own standards around these questions. That puts us in a unique position to bring some of the most important insights into a product built around documentation and knowledge.<figure id="3d4a360d-33e3-80bc-859f-f7552dca561e"><img src="https://static.toss.im/ipd-tcs/toss_core/live/892b7e0c-fbd5-4ede-b504-8b24fbae7ff0/image.png" alt=""></figure>Our end goal is to turn TW expertise into a product that connects documentation with workflows, allowing knowledge to build naturally as people work and making it easy for anyone to find and use. And here’s the product we’re building toward that vision.<h2 id="3d4a360d-33e3-80c6-a8a4-ee1ed0492bcf">todoc: A Product Built by Technical Writers</h2>How do we build a documentation system that remains effective over time and scales across an organization?Our search for an answer eventually led us to todoc, our internal documentation platform, last October.As soon as we announced the beta, we were surprised by how many positive responses we received: “I want to try this right now,” and “This is exactly the documentation platform I’ve been waiting for.”We realized that the need was there across the board. Teams that were already documenting their work wanted an easier way to connect their knowledge to AI, while teams whose documentation was still fragmented needed an easier way to start building up team knowledge in the first place.Six months later, todoc has accumulated more than 500 documents and 40,000 valid pages, with over 1,000 people using it every month.<figure id="3d4a360d-33e3-80f1-ad7f-feb39f158775"><img src="https://static.toss.im/ipd-tcs/toss_core/live/594a6df6-489d-4ea7-9d53-ac87891d1867/mau_chart.png" alt=""></figure>But why build a new product when we already had GitHub and other documentation tools? First of all, there were several problems with our existing internal documentation.First, documentation built with static site generators (SSGs) was difficult for non-developers to use. Making a small edit meant cloning a repository, writing in Markdown, opening a pull request, and going through review. That workflow may feel natural to developers, but for designers or PMs, it could be enough friction to make them give up before they even start writing.Second, our existing documentation tools had accumulated too many notes and too much “junk knowledge.” There were pages with no clear author, date or purpose; outdated documents that had long since changed; half-finished notes left behind and forgotten. You’ve probably seen this happen. Over time, all of this turns into documentation debt: a growing body of information that’s difficult to navigate, maintain, or trust.Finally, knowledge was fragmented across whatever tools people happened to choose. Some lived in SSG-based documentation, some in other documentation tools, some in code, some in conversations on our internal messenger, and some only in people’s heads. Unless we could bring these fragmented sources together, we wouldn’t be able to build a reliable, usable body of organizational knowledge.So we built todoc around four core principles.1. Anyone should be able to write documents easily.We removed as many barriers to documentation as possible. With todoc, anyone can create and edit documents directly. No matter where the information starts, whether it’s GitHub, another documentation tool, or our internal messenger, it can be connected to todoc.2. Knowledge in todoc should be easy to use with AI.Ultimately, one of the biggest reasons to collect and maintain high-quality knowledge is so that AI can use it. With todoc, putting that knowledge to work with AI is easy. Teams can connect it to their own bots and freely access it through APIs, CLI tools, or MCP. Different teams are already using it in different ways, from powering request-handling bots to organizing product specifications.<figure id="3d4a360d-33e3-8053-9727-dd25dd1b977a"><img src="https://static.toss.im/ipd-tcs/toss_core/live/a9ba2c60-5098-4664-ac23-b00ff04b33c9/chat1_toppings_en.png" alt=""></figure><figure id="3d4a360d-33e3-805d-bc7b-dcc80108b178"><img src="https://static.toss.im/ipd-tcs/toss_core/live/4753c851-3cb4-488a-9608-9e602540a40b/chat2_facepayai_en.png" alt=""></figure><figure id="3d4a360d-33e3-80a2-82ca-f1100e288058"><img src="https://static.toss.im/ipd-tcs/toss_core/live/e3fa0112-2f3f-4c74-b179-e153169a6094/chat3_tinkerbell_en.png" alt=""></figure>3. All internal knowledge should come together in one place, creating a Single Source of Truth.todoc connects fragmented sources and turns them into complete, usable documents, so people no longer have to wonder, “Where am I supposed to find this?” Because there is one place to determine which information is current and still valid, todoc can serve as the organization’s Single Source of Truth (SSoT).4. The system should be built to scale.When a team wants to start documenting its work, it shouldn’t have to choose a new tool or build its own infrastructure. It should be able to start on top of todoc, which is already up and running. Each team is given its own documentation space within one platform.Previously, every team or chapter had to choose its own tools, set up infrastructure, and spend time maintaining it. With todoc, team members can focus solely on the documentation itself. And we’re now expanding this structure to Toss affiliates as well.<h2 id="3d4a360d-33e3-8062-857f-fb8590dbc003">What We Still Need to Solve</h2>We’ve lowered the barrier to documentation, but the easier it becomes to create documentation, the harder it becomes to maintain its quality.This is something TWs have thought about for a long time.In the past, we addressed it manually. TWs reviewed documents themselves and checked whether documentation had become outdated. In todoc, we’ve started automating that work by translating the standards TWs have developed for “good documentation” into the product itself. For example, we provide AI-powered editing as well as bots that can automatically generate first drafts.But people still had to make time to sit down and write things down. After seeing how people actually use todoc, I realized that wasn’t enough.Deciding “I’m going to document this” and then turning it into a finished document takes significant time and effort. So instead, we’re designing todoc so that documents take shape naturally as the work happens.todoc can turn decisions, discussions, and code from our internal workflows into documentation automatically. We’re also building systems that monitor code changes and discussions that happen after decisions are made, so documents can stay up to date without depending on someone remembering to maintain them.<figure id="3d4a360d-33e3-8045-b3e4-ed553685b1b7"><img src="https://static.toss.im/ipd-tcs/toss_core/live/a168144e-43f0-47b7-8b14-ce1335b73f5c/todoc_cycle_en.png" alt=""></figure>And documentation isn’t just about collecting information or generating text. The real challenge is determining what knowledge is still valid.Does a written policy match what has actually been implemented in code? Is this piece of knowledge still being used? How recently was it updated? These are the kinds of problems we’re now solving with todoc.<h2 id="3d4a360d-33e3-8012-b75f-fd0a2a301472">How TW Expertise Is Expanding and Shifting</h2>In the past, one of the most important skills for a TW was the ability to write a good document. Now, the more important skill is the ability to design systems that consistently produce good documentation.The expertise TWs have built up isn’t disappearing. It’s being embedded into systems in new ways.<ul><li id="3d4a360d-33e3-8021-aaa9-d14d2e5e76a2">Our experience asking, “Why are some documents so hard to read?” has become a standard for documentation that anyone can write and AI can easily understand.</li><li id="3d4a360d-33e3-8024-a957-dc73a9493c43">Our judgment of what makes a good document has now become the foundation for AI-powered editing and automated reviews.</li><li id="3d4a360d-33e3-8025-9e79-c84e92a6b6a3">Our ability to identify outdated documents and determine what information is still valid has become a system for identifying knowledge that can still be trusted today.</li></ul>Within this shift, what we need to do is clear:<ol><li id="3d4a360d-33e3-80ce-8aec-e1169087510c">Create a place where fragmented knowledge can come together</li><li id="3d4a360d-33e3-805f-89df-f27c71df8e31">Define “good documentation”</li><li id="3d4a360d-33e3-8095-9a9d-fa81504c5322">Embed those standards into systems</li><li id="3d4a360d-33e3-806f-8025-e8419a4958d8">Make documentation build up naturally from work</li><li id="3d4a360d-33e3-80a5-8963-fdbbfbdf7ec0">Build on top of that so knowledge can keep itself up to date</li></ol><hr>Once todoc has solved all of these problems, this is what I imagine my day looking like as both a product team lead and a TW.<blockquote id="3d4a360d-33e3-807d-b044-f85500087641">I no longer have to post reminders asking people to review documents that haven't been updated in over a month. todoc is detecting outdated documents, notifying the right owners, and suggesting improvements. 

Documentation stays trustworthy without anyone having to constantly look after it. I no longer have to manually update the project management tools. Everything the teams produced along the way had already been captured and organized. I can spend my time thinking only about what we should do next. 

Release announcements and answers to recurring questions are all captured and preserved. New team members, and teams integrating with us for the first time, no longer have to repeat the same questions over and over again. Every time someone does a piece of work, it leaves behind knowledge that helps everyone else move faster.

I would open my laptop, and quietly close it again, because there was nothing left for me to do, as todoc is running perfectly on its own.</blockquote>This is where Toss’s Technical Writing Chapter is headed: turning TW expertise, and the standards behind that expertise, into systems.Beyond that, we want to put systems in place that enable every organization to document its work well without relying on TWs to manage it.And once that system is in place, we’ll move on to the next problem.</div></div>

토스테크

*This is the English version of a previously published article.
What It Means for a Technical Writer to Be a Product Owner
Earlier, I broke down the work of Technical Writers (TWs) at Toss into four areas. The first was building products. But what does it actually mean for a TW to build a product? Let me start with my own experience.
I currently lead a product team called the Knowledge System Team. I work alongside developers, designers, and TWs to set the direction of our products and decide on our roadmap and priorities. I interview users directly and bring those insights back to the team. I plan features and sometimes build them myself using AI tools. In other words, I’m not simply someone who communicates documentation-related requirements. I work as a Maker who makes product decisions and helps build the product itself.
So why are TWs building products?
It comes down to what our product is fundamentally about: documentation and knowledge. TWs have spent years thinking deeply about questions like why some documents are difficult to read, what makes a good document, and how information should be structured so that AI can use it effectively. Over time, we’ve developed our own standards around these questions. That puts us in a unique position to bring some of the most important insights into a product built around documentation and knowledge.
Our end goal is to turn TW expertise into a product that connects documentation with workflows, allowing knowledge to build naturally as people work and making it easy for anyone to find and use. And here’s the product we’re building toward that vision.
todoc: A Product Built by Technical Writers
How do we build a documentation system that remains effective over time and scales across an organization?
Our search for an answer eventually led us to todoc, our internal documentation platform, last October.
As soon as we announced the beta, we were surprised by how many positive responses we received: “I want to try this right now,” and “This is exactly the documentation platform I’ve been waiting for.”
We realized that the need was there across the board. Teams that were already documenting their work wanted an easier way to connect their knowledge to AI, while teams whose documentation was still fragmented needed an easier way to start building up team knowledge in the first place.
Six months later, todoc has accumulated more than 500 documents and 40,000 valid pages, with over 1,000 people using it every month.
But why build a new product when we already had GitHub and other documentation tools? First of all, there were several problems with our existing internal documentation.
First, documentation built with static site generators (SSGs) was difficult for non-developers to use. Making a small edit meant cloning a repository, writing in Markdown, opening a pull request, and going through review. That workflow may feel natural to developers, but for designers or PMs, it could be enough friction to make them give up before they even start writing.
Second, our existing documentation tools had accumulated too many notes and too much “junk knowledge.” There were pages with no clear author, date or purpose; outdated documents that had long since changed; half-finished notes left behind and forgotten. You’ve probably seen this happen. Over time, all of this turns into documentation debt: a growing body of information that’s difficult to navigate, maintain, or trust.
Finally, knowledge was fragmented across whatever tools people happened to choose. Some lived in SSG-based documentation, some in other documentation tools, some in code, some in conversations on our internal messenger, and some only in people’s heads. Unless we could bring these fragmented sources together, we wouldn’t be able to build a reliable, usable body of organizational knowledge.
So we built todoc around four core principles.
1. Anyone should be able to write documents easily.
We removed as many barriers to documentation as possible. With todoc, anyone can create and edit documents directly. No matter where the information starts, whether it’s GitHub, another documentation tool, or our internal messenger, it can be connected to todoc.
2. Knowledge in todoc should be easy to use with AI.
Ultimately, one of the biggest reasons to collect and maintain high-quality knowledge is so that AI can use it. With todoc, putting that knowledge to work with AI is easy. Teams can connect it to their own bots and freely access it through APIs, CLI tools, or MCP. Different teams are already using it in different ways, from powering request-handling bots to organizing product specifications.
3. All internal knowledge should come together in one place, creating a Single Source of Truth.
todoc connects fragmented sources and turns them into complete, usable documents, so people no longer have to wonder, “Where am I supposed to find this?” Because there is one place to determine which information is current and still valid, todoc can serve as the organization’s Single Source of Truth (SSoT).
4. The system should be built to scale.
When a team wants to start documenting its work, it shouldn’t have to choose a new tool or build its own infrastructure. It should be able to start on top of todoc, which is already up and running. Each team is given its own documentation space within one platform.
Previously, every team or chapter had to choose its own tools, set up infrastructure, and spend time maintaining it. With todoc, team members can focus solely on the documentation itself. And we’re now expanding this structure to Toss affiliates as well.
What We Still Need to Solve
We’ve lowered the barrier to documentation, but the easier it becomes to create documentation, the harder it becomes to maintain its quality.
This is something TWs have thought about for a long time.
In the past, we addressed it manually. TWs reviewed documents themselves and checked whether documentation had become outdated. In todoc, we’ve started automating that work by translating the standards TWs have developed for “good documentation” into the product itself. For example, we provide AI-powered editing as well as bots that can automatically generate first drafts.
But people still had to make time to sit down and write things down. After seeing how people actually use todoc, I realized that wasn’t enough.
Deciding “I’m going to document this” and then turning it into a finished document takes significant time and effort. So instead, we’re designing todoc so that documents take shape naturally as the work happens.
todoc can turn decisions, discussions, and code from our internal workflows into documentation automatically. We’re also building systems that monitor code changes and discussions that happen after decisions are made, so documents can stay up to date without depending on someone remembering to maintain them.
And documentation isn’t just about collecting information or generating text. The real challenge is determining what knowledge is still valid.
Does a written policy match what has actually been implemented in code? Is this piece of knowledge still being used? How recently was it updated? These are the kinds of problems we’re now solving with todoc.
How TW Expertise Is Expanding and Shifting
In the past, one of the most important skills for a TW was the ability to write a good document. Now, the more important skill is the ability to design systems that consistently produce good documentation.
The expertise TWs have built up isn’t disappearing. It’s being embedded into systems in new ways.
Our experience asking, “Why are some documents so hard to read?” has become a standard for documentation that anyone can write and AI can easily understand.
Our judgment of what makes a good document has now become the foundation for AI-powered editing and automated reviews.
Our ability to identify outdated documents and determine what information is still valid has become a system for identifying knowledge that can still be trusted today.
Within this shift, what we need to do is clear:
Create a place where fragmented knowledge can come together
Define “good documentation”
Embed those standards into systems
Make documentation build up naturally from work
Build on top of that so knowledge can keep itself up to date
Once todoc has solved all of these problems, this is what I imagine my day looking like as both a product team lead and a TW.
I no longer have to post reminders asking people to review documents that haven't been updated in over a month. todoc is detecting outdated documents, notifying the right owners, and suggesting improvements. 
Documentation stays trustworthy without anyone having to constantly look after it. I no longer have to manually update the project management tools. Everything the teams produced along the way had already been captured and organized. I can spend my time thinking only about what we should do next. 
Release announcements and answers to recurring questions are all captured and preserved. New team members, and teams integrating with us for the first time, no longer have to repeat the same questions over and over again. Every time someone does a piece of work, it leaves behind knowledge that helps everyone else move faster.
I would open my laptop, and quietly close it again, because there was nothing left for me to do, as todoc is running perfectly on its own.
This is where Toss’s Technical Writing Chapter is headed: turning TW expertise, and the standards behind that expertise, into systems.
Beyond that, we want to put systems in place that enable every organization to document its work well without relying on TWs to manage it.
And once that system is in place, we’ll move on to the next problem.

2. Beyond Our Expertise

댓글