Основные составляющие хорошего PRDПогнали дальше - начало тут
https://t.me/proproduct/1034 Можно очень легко проверить, хороший ли PRD: дайте его вашему CEO, разработчику из другой команды и уборщице тете Глаше, а затем спросите:
1. Что делает команда
2. Зачем она это делает
3. Как она это делает.
В идеальном случае ответы должны быть одинаковыми (что никогда не случается). В близком к идеалу случае ответы должны пересекаться в ключевых деталях.
Уборщица у нас здесь появилась не случайно, но об этом ниже :)
Первое, с чего начинается PRD, это
указание стадии проекта. Я выделяю Exploration (движение от 0 к 1, с миллионом неизвестных и 50:50 шансом на успех) и Execution (четкое понимание рисков, подводных камней и успеха).
Почему это важно: у вашего читателя сразу создаются правильные ожидания. От проектов в исследовательской стадии не стоит ждать точного соблюдения сроков или конкретики в метриках.
Следующая часть –
проблема, которую мы хотим решить. Кто наша целевая аудитория? В чем их "боль" или задача? Откуда мы знаем, что это реальная проблема и ее стоит решать? Почему она важна для бизнеса?
Почему это важно: в PRD это один параграф, но в реальности требуется большой объем работы, чтобы его написать, - иногда "просто" прошерстить предыдущие исследования, чтобы найти необходимые данные; иногда организовать дополнительное исследование или анализ, чтобы валидировать некоторые аспекты проблемы.
Этот параграф нужно зачитывать на каждой встрече, у команды он должен отскакивать от зубов. Удивительно, но в процессе работы над решением определение проблемы начинает трансформироваться в неожиданные формы - если его не зацементировать изначально в головах коллег.
Третья часть -
определение успеха и цели. В какой момент мы поймем, что решили проблему? Что изменится с точки зрения пользователя? Какие метрики лучше всего выразят это изменение?
Почему это важно: опять же, позволяем команде договориться об общем понимании успеха и подумать, что и как мы будем измерять. Не должно быть такого, что фича уже почти готова, и тут команда спохватывается: а что нам нужно мерить. Это приводит к: 1) конфликтам в команде из-за разного видения; 2) неточности (а иногда и невозможности) измерения ценности; 3) микроменеджменту в процессе.
Четвертая часть - наше
предлагаемое решение. Я люблю делать так:
⁃ сначала one sentence pitch - описание решения одним предложением;
⁃ затем 3-4 ключевых аспекта пользовательского опыта;
⁃ открытые вопросы и риски;
⁃ дальше ссылка на дизайн-файл, где подробно прописаны пользовательские stories/flows и все аспекты взаимодействия на разных платформах;
⁃ ссылка на техническое исследование.
Почему именно так: как говорилось в прошлой заметке, любому человеку, который откроет ваш файл, должно быть понятно, что вы предлагаете сделать. Наша Уборщица появляется здесь во второй раз, чтобы подчеркнуть этот пункт. В PRD все максимально ясно и понятно. В техническом и дизайн-документах - уже уходим в дебри и глубокое описание всех взаимодействий. Но начинаем все равно с питча и списка вопросов и рисков, которые, по идее, должны вычеркиваться по мере проработки последующих пунктов.
Пятая часть:
ключевые этапы и даты. Условно это может выглядеть так: M0 - какая-то подготовительная работа; M1 - MVP; M2 - закрытая бета; и так далее. На каждом этапе должны быть прописаны критерии перехода на следующий этап: что мы меряем, на что смотрим, за каким фидбэком следим.
Почему это важно: ни один хороший продукт не делается за один заход и не запускается сразу на 100% пользователей в идеальном виде. Нужно продумать и договориться, что нужно валидировать в продакшене в первую очередь; какие вы предвидите итерации; какие условия должны быть выполнены для запуска.
Шестое:
дополнительные ресурсы. Дашборды, предыдущие исследование, любые другие релевантные документы. Создавайте такую базу знаний по проблеме, чтобы 1) это была единая точка входа; 2) если в дальнейшем вы решите сделать итерацию или перепридумать продукт, у вас был доступ ко всем нужным материалам.
