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

Команда придумывает продукт: «А давайте сделаем AI-сервис, который превращает сайты в дизайн». Звучит неплохо. Но само по себе это ещё ничего не значит.

А теперь другая ситуация. У дизайнера есть сайт, который уже работает в проде. Макета в Figma нет. Нужно внести изменения — и начинается:

  • открыть сайт;
  • делать скриншоты;
  • переносить блоки в Figma;
  • восстанавливать размеры;
  • искать шрифты и подбирать цвета;
  • собирать компоненты и повторять отступы;
  • а потом ещё объяснять разработчику, что именно нужно изменить.

И это приходится делать снова и снова. Вот здесь появляется уже не идея, а боль.

PMF начинается не с идеи продукта. Он начинается с момента, когда вы находите проблему, которую люди уже решают костылями.

Именно на таком инсайте построен целый класс продуктов HTML → Design. Например, плагин HTML to Figma описывает исходную проблему просто: production-сайт существует, а Figma-файла нет, поэтому его приходится вручную пересобирать. Браузер при этом уже знает реальные размеры, стили, позиции и шрифты — остаётся научиться перенести это в редактируемые слои.

Почему это хороший пример продуктового мышления

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

Не «мы придумали конвертер HTML в Figma», а «люди регулярно сталкиваются с тем, что интерфейс уже существует в коде, но его нет в дизайне, и вынуждены вручную восстанавливать то, что уже есть». Это два принципиально разных способа смотреть на продукт.

Настоящая боль часто выглядит скучно

Когда мы ищем идею для стартапа, хочется чего-то грандиозного: «изменить образование», «перевернуть рынок дизайна», «сделать AI для дизайнеров». Но хороший продукт часто начинается с гораздо более прозаичного наблюдения:

«Почему я опять должна делать это вручную?»

Именно такие фразы стоит ловить в исследованиях. За ними обычно скрывается повторяющееся действие, потеря времени, ручная работа, ошибки, костыли, переключение между инструментами, раздражение — и деньги, которые человек уже платит за решение. Чем чаще человек сталкивается с проблемой, тем интереснее она для продукта.

Самый сильный сигнал — человек уже придумал workaround

Это один из моих любимых признаков хорошей продуктовой боли.

Если пользователь говорит «да, у нас есть такая проблема» — это интересно. Если говорит «да, я каждый раз делаю вот это…» — намного интереснее. Потому что он уже тратит ресурсы на решение.

Он может вести таблицу в Excel, копировать данные между системами, использовать несколько сервисов, писать скрипты, просить разработчика, делать работу руками или платить за сторонний инструмент. То есть рынок уже существует до того, как вы создали продукт.

Вы не создаёте потребность. Вы делаете существующее решение проблемы лучше.

HTML → Design: пример «спрятанной» боли

На поверхности задача кажется простой: «перенести сайт в Figma». Но если посмотреть на workflow дизайнера, становится понятно, зачем это вообще нужно:

  • есть production;
  • нужно изменить интерфейс;
  • Figma-файла нет или он устарел;
  • дизайнер вручную пересобирает интерфейс;
  • тратит часы;
  • и только после этого начинается настоящая работа над продуктом.

Самое интересное: проблема возникает не потому, что дизайнер не умеет работать в Figma. Она возникает потому, что источник истины уже находится в другом месте — в браузере и коде. Поэтому продукт не «экономит несколько кликов», а убирает целый ненужный этап. Это гораздо более сильная ценность.

Хорошая боль отвечает на вопрос «почему сейчас?»

Проблема может существовать десять лет. Но почему продукт становится актуальным именно сейчас?

В случае HTML → Design появился интересный контекст. AI и современные frontend-инструменты позволяют собирать интерфейсы всё быстрее, и возникает новый порядок работы: идея → AI → HTML/React → работающий интерфейс. А дальше дизайнеру снова может понадобиться Figma — и появляется обратная задача: code → design.

Это уже не случайная проблема одного дизайнера. Это изменение самого рабочего процесса — а вокруг таких разрывов и появляются новые продукты.

Новые технологии часто не уничтожают проблемы. Они создают новые переходы между инструментами. И каждый такой переход может стать возможностью для продукта.

Но боль ≠ PMF

Здесь важно не совершить обратную ошибку: нашли сильную боль → сделали продукт → «у нас PMF!». Нет. Это только начало.

Product-Market Fit — это ситуация, когда определённый сегмент пользователей настолько ценит решение, что продукт становится для них по-настоящему необходимым. Один из известных способов это проверить — вопрос Шона Эллиса:

«Как бы вы себя чувствовали, если бы больше не могли пользоваться этим продуктом?»

Варианты ответа: очень расстроился бы / немного расстроился бы / не расстроился бы. Классический ориентир — 40%+ тех, кто выбрал «очень расстроился бы». Но это именно ориентир, а не закон: его нужно читать вместе с удержанием, реальным использованием и сегментацией пользователей. Подробнее про методику опроса.

И здесь есть важная мысль: PMF нельзя придумать. Его можно только обнаружить и постепенно усилить.

Как на самом деле выглядит продуктовый процесс

Не так: идея → разработка → запуск → реклама → PMF. А скорее так:

  • наблюдение;
  • проблема;
  • как человек решает её сейчас;
  • насколько часто она возникает;
  • сколько ресурсов он уже на неё тратит;
  • кто испытывает её сильнее всего;
  • можно ли сделать решение существенно лучше;
  • первые пользователи → повторное использование → готовность платить и рекомендовать → PMF.

Поэтому хороший продакт-менеджер большую часть времени проводит не за придумыванием фич, а за попыткой понять: что здесь на самом деле болит?

И вот где начинается самое интересное

Если человек говорит «да, у меня постоянно возникает эта проблема» — это ещё не повод строить продукт. Если говорит «я сейчас решаю её вот таким ужасным способом» — уже интереснее. Если «я потратил на это три часа вчера» — ещё интереснее. А если «я пробовал три инструмента, и ни один нормально не решает задачу» — вот здесь стоит остановиться и очень внимательно послушать.

Потому что перед вами может быть не идея для фичи, а рынок.

Задача продуктового человека — не в том, чтобы первым придумать решение. А в том, чтобы настолько хорошо понять проблему, чтобы правильное решение стало почти очевидным.

Я разбираю такие боли — как находить их в исследованиях и превращать в продуктовые гипотезы — в CaseSociety. Если тема близка, оставайтесь рядом: продолжение будет здесь.