Ловушка dogfooding'а

Аргумент из sail-muddy-lessons: dogfooding кажется валидацией, но по большей части ей не является.

Команда Sail/Muddy перешла с Discord'а на собственный продукт, вела задачи у себя вместо Linear и открывала Notion только тогда, когда не хватало возможностей своего текстового редактора. Вся компания работала внутри продукта. Любое взаимодействие давалось легко, ведь каждую концепцию они придумали сами.

Внешние пользователи открывали тот же продукт и упирались в стену: "Что мне вообще с этим делать?" Слишком много сущностей, слишком много видов пространств, слишком крутая кривая обучения. Dogfooding доказал лишь то, что в продукте нет багов и им приятно пользоваться людям, которые уже понимают заложенную модель.

Почему ловушка структурная

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

Это особенно критично для инструментов мышления и продуктов для совместной работы, где ценность зависит от того, примет ли пользователь внутреннюю ментальную модель. Для инструментов, решающих одну конкретную прикладную задачу (загрузка файлов, запись экрана, приём платежей), проблема стоит не так остро: там сигнал от dogfooding'а ближе к сигналам от реальных пользователей.

Slack как контрпример

Slack, как известно, вырос из dogfooding'а - его создали как внутренний инструмент в ходе работы над игрой Glitch. Но взлетел Slack вовсе не из-за самого dogfooding'а. Решающим стал внешний сигнал: когда Butterfield открыл превью в августе 2013 года, за две недели заявку на инвайт оставили 8000 человек, а 93% попробовавших продукт уже не переставали им пользоваться. Dogfooding дал отполированный продукт. Но именно внешний сигнал показал, что у продукта есть рынок.

Паттерн такой: dogfooding - это инструмент контроля качества, а не инструмент валидации рынка. Их нужно разделять.

Что делать вместо этого

Взгляд Алехандро: часто команды решают проблемы интерфейса, когда нужно решать проблемы рабочих процессов. Интерфейс - лишь проводник. На самом деле важны сам рабочий процесс и ощущение от его завершения - дофаминовый всплеск при отправке сообщения, чувство удовлетворения, когда вычёркиваешь пункт. Dogfooding не способен показать, нужны ли эти рабочие процессы кому-то за пределами команды изначально.

Связанное

• multiplayer-by-default-failure - multiplayer-продукты особенно уязвимы, поскольку команда по определению является сплочённой группой соавторов
• positioning-vs-vision-gap - dogfooding может маскировать то, что вы не умеете описать продукт
• reps-as-pattern-recognition - как выглядят настоящие внешние итерации (reps)