Промпт · Ревью

Критика PRD по ролям

Приём Lenny Rachitsky

Это адаптация чужой практики: разбираем методологию автора, переписываем под наш формат и показываем, как применить, на примере ниже. Первоисточник →

В бенчмарке моделей зону «Документация» сейчас лучше всех решают: 1. Claude Fable 5 — 9,8 · 2. Claude Opus 4.8 — 9,8 · 3. GLM 5.3 — 9,6

Промпт

Ты — опытный продуктовый консультант, который разбирает PRD с трёх позиций, чтобы найти слабые места до того, как документ попадёт в разработку. Критикуй жёстко, но справедливо: каждое замечание опирается на текст документа или на его отсутствие, а не на догадки о команде.

Входные данные: — PRD: [вставьте текст документа].

Разбери документ трижды, отдельными блоками:

  1. Как CTO: реализуемость, интеграции, скрытая сложность, зависимости от других систем и команд. Отметь, что в тексте звучит просто, а в реализации окажется дорогим или рискованным.
  2. Как продуктовый дизайнер: пользовательские сценарии и дыры в опыте — что произойдёт, если шаг не удался, данные не пришли, пользователь вернулся через неделю.
  3. Как аналитик: измеримость, полнота метрик, можно ли будет отделить эффект фичи от фона и какие выводы окажутся шаткими.

Каждый блок строй одинаково: сильные стороны документа, замечания по существу, что уточнить у автора. Не придумывай деталей, которых нет в PRD: отсутствие нужного раздела — тоже замечание.

В конце: — 5 вопросов, которые автор должен задать себе перед следующим чтением документа; — топ-3 правки по приоритету: что исправить в первую очередь и почему это важнее остального.

Пример данных

Данные вымышлены. Замени их информацией о своей задаче.

PRD «Проверка домашних заданий с ИИ-помощником», платформа «Курсора» — онлайн-курсы для школьников 12–16 лет.

Проблема: преподаватели тратят 8–10 часов в неделю на проверку домашних заданий, поэтому проверяют выборочно: по опросу преподавателей, 40% заданий проверяется позже чем через 3 дня после сдачи, часть остаётся без обратной связи.

Решение: ИИ-помощник проверяет текстовые домашние задания, формирует отзыв и оценку по шкале от 1 до 10; преподаватель подтверждает или правит результат в личном кабинете.

Сценарий: ученик сдаёт работу, через 5 минут видит отзыв; преподаватель открывает очередь проверенных работ и подтверждает одну нажатием.

Интеграции: задания уже хранятся в платформе, видеоплеер уроков есть.

Метрики: среднее время проверки работы, доля работ с обратной связью в течение суток, NPS преподавателей.

Команда: один разработчик и один методист, срок — 6 недель.

Пример ответа

Один из возможных результатов. Проверь факты и адаптируй текст перед использованием.

Разбор глазами CTO

Сильные стороны: команда сразу ограничила амбиции — один разработчик и 6 недель; исторические данные уже в платформе, миграция старых записей не нужна; преподаватель в контуре подтверждения — это снижает цену ошибки.

Замечания:

  • Самый дорогой и рискованный блок — «ИИ-помощник проверяет текстовые работы и ставит оценку от 1 до 10» — описан одной строкой. Не сказано, какая модель или сервис, как считается стоимость проверки одной работы и что с работами на несколько страниц.
  • Контур обработки данных при ИИ-проверке не разобран: работы школьников придётся передавать модели или inference-сервису — это передача данных, даже если миграций нет. Неясны поставщик и хостинг модели, срок хранения текстов и используются ли они для обучения, что с персональными данными несовершеннолетних и согласиями родителей. Без ответов пилот на реальных работах запускать рано.
  • «Через 5 минут ученик видит отзыв» — жёсткое обещание времени ответа. Вечером перед уроком сдачи наверняка идут пиком, и выдержать 5 минут сложнее, чем в тесте; сценария «проверка заняла дольше» в документе нет.
  • Из интеграций описан только плеер: очередь подтверждения, правки преподавателя и то, что видит ученик после правки, — это тоже интеграция с кабинетом, и её нет в PRD.

Уточнить у автора: ограничения по длине работы, поведение при сбое проверки и при пике сдач, стоимость проверки одной работы.

Разбор глазами продуктового дизайнера

Сильные стороны: основной сценарий ясен и короткий — сдал, через 5 минут получил отзыв; подтверждение преподавателем оставляет за человеком последнее слово.

Замечания:

  • Описан только счастливый путь. Что видит ученик, если считает отзыв несправедлив? Сценария спора, пересдачи и повторной проверки в PRD нет.
  • Шкала от 1 до 10 без контекста: для школьника 12 лет «6» — это хорошо или почти провал? Формы отзыва под возраст аудитории в документе нет.
  • «Подтверждает одним нажатием» — а если преподаватель не согласен? Сценарий правки и её следствий (меняется ли оценка ученика, видит ли он правку) не описан.
  • Нет состояния для работ, которые ИИ не смог оценить: пустой файл, работа не по теме, цитирование вместо ответа.

Уточнить у автора: как выглядит спор с оценкой, что видит ученик при правке преподавателя, обработка нестандартных работ.

Разбор глазами аналитика

Сильные стороны: у проблемы есть опорные цифры — 8–10 часов в неделю и 40% проверок позже чем через 3 дня; метрики затрагивают обе стороны — и преподавателей, и учеников.

Замечания:

  • Ни у одной метрики нет базлайна и целевого значения: сколько занимает «среднее время проверки» сейчас и к какому значению идём? Через 6 недель будет непонятно, получился эффект или нет.
  • «Среднее время проверки» смешивает два разных действия: подтверждение одним нажатием и правку руками. Метрика не покажет, где ИИ реально экономит время.
  • NPS преподавателей — медленная метрика: за 6 недель сдвиг будет трудно отделить от фона, а способа сбора NPS в PRD нет.
  • В PRD нет плана сравнения с фоном: если запускать на всех сразу, эффект ИИ-проверки не отделить от остальных изменений.

Уточнить у автора: базлайны и цели по каждой метрике, способ замера до старта, план запуска (на группу или на всех).

5 вопросов автора к себе

  1. Сколько сейчас занимает проверка одной работы и что мы будем считать «после» запуска?
  2. Что происходит с оценкой и отзывом, когда преподаватель не согласен с ИИ?
  3. Что видит ученик, если проверка заняла не 5 минут, а час или сломалась?
  4. Какие целевые значения у трёх метрик и где мы замерим базлайн до старта?
  5. Что делает система с работой, которую не может оценить, и как часто мы это допускаем?

Топ-3 правки по приоритету

  1. Расписать блок ИИ-проверки: ограничения по длине, время ответа при пике, поведение при сбое и при работе, которую нельзя оценить. Это главный технический риск — при команде в одного разработчика его нельзя оставлять одной строкой.
  2. Добавить сценарии несогласия: правка преподавателя и спор ученика с оценкой. Это самые широкие дыры в опыте, и они затрагивают доверие к продукту.
  3. Задать базлайны и целевые значения метрик и способ их замера. Без этого по итогам 6 недель команда не сможет ответить, сработала ли фича.

Проверьте факты

  • Цифры 8–10 часов и 40% поздних проверок взяты из опроса в PRD: перед запуском метрик сверь методику опроса.
  • Все замечания про отсутствие разделов опираются на текст PRD — базлайнов, сценариев ошибок и плана запуска там действительно нет.
  • Оценка «NPS за 6 недель не сдвинется» — суждение аналитика: в PRD нет данных о числе преподавателей и текущем NPS.
  • Предположение о вечернем пике сдач — типичный риск, но в PRD про пик ничего нет: подтверди по данным о времени сдач.

Из главы: PRD и документация