33%
Wiki продукта и описание задач
Для базы знаний можно использовать Google Docs, Dropbox paper, Notion или любую платного рода wiki типа Confluence.

Главное, сразу определить структуру по которой будет вестись документация, если кидать все в корневую папку, уже через 1-2 месяца будет страшная каша из страниц, и при росте команды разобраться будет сложно.
Рассмотрим пример на примере продукта N1.RU

Это классифайд по недвижимости.
Это не вся структура, а лишь пример. Конечно, какие-то части продукта пересекаются, с ростом функциональности продукта, что-то будет переезжать, что-то выбрасывать, что-то обновляться и дорабатываться, что-то просто перелинковываться. Но важно с самого начала помнить о порядке, ведь когда продакт на продукт не 1, каждый должен легко находить и использовать документацию коллег.
Про описание задач поговорим подробнее.
Вы можете использовать разные методологии, но суть всегда одна – из задачи должно быть понятно, что вы хотите сделать, кому это и зачем нужно, какая финальная цель.
Пример того, как может выглядеть шаблон описания задачи:
https://docs.google.com/document/d/1nnPp8lct7-aXj02VqGVjemNWJxoz-wiiOLdJjINErQY/edit?usp=sharing

С таким описанием можно прийти, например, к дизайнеру, чтобы ему было понятно, что от него хочет продакт.
Для разработки этого мало. Чтобы общаться с разработчиками, нужно добавить:
  • Реальные макеты с картой экранов
  • Описанием каждого экрана
    • Сценарии
    • Куда ведут ссылки
    • Как отрабатываю формы
      • Описание каждого поля формы, его тип, варианты значений, обязательность
  • Спецификации
  • Описание алгоритмов и API (если вы технический продакт)
  • Описание сервисов, с которыми хотим интегрироваться
  • Технические требования (если сами не знаете, попросите помощи техлида)
И так для разработки мы получаем уже более подробный документ. Пример:
https://docs.google.com/document/d/1lJfhTj3vDhf631KZuzzB5Yz_C8f2aHRFWDgWVWAto60/edit?usp=sharing

Примеры выше отлично подходят для аутсорса и шареных ресурсов, когда продакт не может надеяться на выделенную и полностью вовлечению команду, его задача, максимально подробно донести то, что он хочет получить и зачем.
Если команда выделенная, можно позволить себе Agile ;)
Гибкая разработка, это не значит, что теперь можно забросить wiki и не описывать экраны и формы, но, документации может быть значительно меньше, потому что вы часто общаетесь с командой голосом.

В таком случае, можно писать так:
Для наглядности пользовательские истории можно собрать в карту историй – User Story Map.

Инструменты:
Совет: не используйте таблицы, так как вставлять что-то в середину таблицы не так просто, как передвинуть задачу или стикер в FeatureMap или Miro.

Если вы любите оффлайн, то делать карты можно со стикерами на доске или стене. Ниже представлен пример карты MVP нового продукта. Стикерами отмечены истории, которые были реализованы.
Теперь у нас есть карта, по ней можно детально описать все истории, приложить к ним макеты, необходимые описания и отдать в работу :)