Ответ простой - CPO (Chief Product Owner) и CTO (Chief Technical Officer).
Другими словами - хозяин продукта и технический директор.

Но чаще всего это делает просто Product-менеджер или поручают Project-менеджеру.

Вам надо понимать зачем вам документация. Потому что многие путают ее с регламентами работы внутри компании и документе должности сотрудника.

Мы даем такое определение документации - документ, рассказывающий о продукте, его появлении, функциях. Подробное описание технических особенностей, функциональных требованиях, сценариев использования. Помогает разобраться в продукте или вспомнить, как работает определенный его функционал.

Вот готовая структуру документации. Мы остановимся на каждой части попорядку.

№1. Введение - расскажите о вашем продукте.
Что представляет ваш продукт, кто ваше целевая аудитория, можете рассказать историю о том, как появилась компания или идея продукта, какие особенности, на каких платформах, технические требования и др.

Эта информация открывает дверь в ваш продукт, знакомит и интересует читателя, вашего сотрудника.

№2. Общая структура.
Начало технической части по продукту. Здесь лучше рассказать об используемых технологиях, базах данных, серверной части. Предоставить ссылки на GitHub, swagger, CMS.

Конечно, все зависит от продукта, как правильно развернуть локально проект или предоставить правила работы по проекту для Front-end и Back-end разработчиков.

№3. Пользовательская часть (UI/UX, Flow).
Часть, которая включает файлы на дизайн и блок схему работы продукта.

Мы рекомендуем заранее подготовить файл в Figma или Miro, где вы структурно покажете Flow ваших пользователей:

• какие есть экраны;
• как между ними осуществляется переход;
• какие есть условия;
• кому открыт/закрыт доступ и др.

Чем подробнее будет схема, тем будет лучше для погружение в продукт. Просто дать платформу, мобильное приложение и сказать сотруднику "изучай" - мало. Нужно пройти по сценариям, которые есть, прочувствовать и ощутить особенности продукта.

№4. Функциональные требования (описание работы функционала).
Думаю из подзаголовка понятно, что нужно отразить в этой части:

• название функционала;
• подробное описание его работы.

Кто-то оформляет функционал в виде User Story / Job Story. То есть берут за основу поставленную раннее задачу. Это помогает ответить на вопрос "Зачем это нужно и какую боль закрывает?"

Работу функционала нужно описать очень подробно. Эта информация пригодится Product-менеджеру, разработчикам и тестировщикам, чтобы понимать как уже реализован функционал, чтобы его доработать или сделать дополнение к нему.

Здесь уже на выбор:

• Notion - могу посоветовать данный шаблон. А вообще очень много и других. Вот ссылка на все шаблоны.
• Confluence - разработан специально для документирования и создания баз знаний на проектах.
• Archbee - сервис для создания технической документации.
• Miro или Figma (это на усмотрение).
• Собственный сайт с приватной частью раздела.