Я проверил старый продукт так, будто ещё не написал ни одной строки кода. В результате две исходные траектории я бы остановил, а вместо них проверял бы привычку превращать устную мысль сразу в готовый письменный текст.

Голосовой ввод с ИИ: почему обычной транскрибации уже мало

Несколько лет назад идея «Говори дело» казалась мне достаточно логичной.

Я записываю голосовое сообщение в Telegram. Система распознаёт речь, превращает её в текст, понимает задачу и отправляет результат в Bitrix24.

Голосом сформулировать мысль зачастую быстрее, чем печатать. Telegram всегда под рукой. Bitrix24 уже используется для работы.

На поверхности всё складывается.

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

Поэтому я провёл ретроспективное исследование «Говори дело».

Вопрос был простой:

Что произошло бы, если бы я применил сегодняшнюю исследовательскую методику ещё до разработки первой версии продукта?

Две исходные траектории я бы после такого исследования остановил.

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

Я исследовал не приложение, а работу пользователя

Я специально не начинал с вопроса, каким должен быть интерфейс или куда подключить ИИ.

Сначала разложил саму работу.

Человек находится в ситуации, когда мысль проще сказать, чем напечатать.

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

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

Получается асимметрия.

Говорить удобно автору.

Использовать необработанный результат неудобно получателю.

Именно здесь первоначальная идея «Говори дело» смешивала несколько функций:

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

Технически всё это можно соединить в одном продукте.

Но из этого ещё не следует, что пользователю нужен именно такой продукт.

Первая траектория: просто хороший транскрибатор

Самый простой вариант - получить из голосового сообщения текст.

Эту траекторию исследование сильно ослабило.

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

Поэтому предложение:

«Скажите голосом, а я превращу это в текст»

становится трудно защищать как самостоятельную ценность.

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

Я не увидел достаточного основания строить новый продукт только вокруг расшифровки.

Эту ветку я бы остановил.

Вторая траектория: Telegram -> Bitrix24

Это уже гораздо ближе к первоначальному «Говори дело».

Пользователь отправляет голос.

Система понимает содержание.

После этого автоматически создаёт задачу или другой объект в Bitrix24.

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

Но именно здесь исследование показало другую проблему.

Я слишком рано перепрыгнул от пользовательской работы к интеграции.

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

К этому добавляется зависимость от самого вендора. Если корпоративная платформа развивает собственные функции работы с голосом, видео и ИИ, часть внешнего продукта постепенно перемещается внутрь основной системы.

Получается тяжёлая конструкция.

Основная пользовательская ценность ещё не доказана, а вокруг неё уже появился большой интеграционный контур.

Для себя я называю это ловушкой преждевременной интеграции.

Можно потратить много времени на надёжную автоматизацию функции, необходимость которой рынок ещё не подтвердил.

В ретроспективе я бы эту траекторию тоже остановил.

Не потому, что интеграция с Bitrix24 невозможна.

А потому, что она появилась раньше ответа на более важный вопрос:

Какая часть этой работы достаточно ценна сама по себе?

Самый интересный результат оказался между двумя вариантами

Исследование постепенно привело меня к другой формулировке продукта.

Не транскрибатор.

Не голосовой интерфейс для Bitrix24.

А персональный редактор устной мысли.

Сценарий выглядит так:

Я произношу мысль так, как мне удобно. Система превращает её не в дословную расшифровку, а в готовый письменный результат. После этого я использую его там, где он мне нужен.

Например, в письме.

В сообщении.

В задаче.

В документе.

В CRM.

В комментарии.

В запросе к ИИ.

Здесь меняется сама единица ценности.

Исходная запись - сырьё.

Транскрипция - промежуточный результат.

Ценность появляется тогда, когда текст уже можно использовать.

От расшифровки к чистовику мысли

Рабочее название этой гипотезы для меня - «чистовик мысли».

Я могу сказать:

«Слушай, надо бы написать Петрову, что мы посмотрели проект, в целом всё нормально, но по срокам не успеваем, наверное, надо предложить вторник или среду и попросить его подтвердить».

Система не обязана возвращать мне дословную запись этой фразы.

Она может подготовить:

Александр, мы посмотрели проект. В целом всё в порядке, но в первоначальные сроки не успеваем. Предлагаю перенести на вторник или среду. Подтвердите, пожалуйста, какой вариант подходит.

Содержание остаётся моим.

Система не принимает за меня бизнес-решение.

Она преобразует устную форму мысли в письменную.

Для меня это уже другая функция.

Оказалось, рынок уже движется в эту сторону

После исследования я отдельно посмотрел, как развивается категория голосового ввода.

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

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

Российский «Диктуй» позволяет вводить голосом текст непосредственно в приложения и отдельно использовать ИИ для его преобразования. Airword прямо описывает задачу как превращение неровной устной речи в готовый текст.

Google пошёл ещё дальше. В Gboard появился режим «Чистый текст», который превращает естественную речь в структурированный текст, удаляет слова-паразиты, исправляет пунктуацию и позволяет редактировать результат голосовыми командами.

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

Для меня это одновременно хороший и плохой сигнал.

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

Плохой - потому что сама формула «надиктовал мысль и получил чистовой текст» уже не является достаточной отстройкой.

Поэтому следующий вопрос стал сложнее.

Мне нужно понять не то, можно ли сделать «чистовик мысли».

Нужно понять, для какого пользователя, в какой ситуации и за какую дополнительную ценность отдельный продукт окажется лучше встроенной диктовки и уже существующих сервисов.

Почему здесь важен обычный буфер обмена

В старой версии продукта интеграция казалась преимуществом.

Сейчас я смотрю на неё осторожнее.

Если система умеет создавать задачу только в Bitrix24, она связана с Bitrix24.

Если она работает только внутри Telegram, она связана с Telegram.

Если отдельно подключать почту, CRM, таск-трекеры, мессенджеры и документы, сложность продукта начинает расти раньше доказанной ценности.

Но есть универсальный интерфейс, который уже поддерживают практически все программы.

Буфер обмена.

Получается простой контур:

голос -> обработка -> готовый текст -> буфер обмена -> нужное приложение.

С технической точки зрения это выглядит менее впечатляюще, чем автоматическое создание задачи внутри корпоративной системы.

С продуктовой точки зрения у такого решения есть преимущество.

Оно почти ничего не должно знать о конечном приложении пользователя.

Поэтому один и тот же результат можно использовать в разных системах без отдельной интеграции с каждой из них.

Кроме того, последнее действие остаётся человеку.

Система готовит результат.

Я решаю, куда его вставить и нужно ли его отправлять.

Для ранней проверки продукта такая граница автоматизации мне сейчас кажется разумнее, чем попытка сразу действовать от имени пользователя.

Экономика перестала выглядеть главным препятствием

В рамках исследования я отдельно проверил предварительную экономику.

При использованных предположениях переменная стоимость обработки для такой модели получилась небольшой - ориентировочно 18-36 рублей на активного пользователя в месяц.

При этом собственная инфраструктура с графическими процессорами на раннем этапе не выглядит рациональной. В расчёте исследования она начинала конкурировать с облачной обработкой только при объёмах порядка 78 500 минут в месяц.

Я не воспринимаю эти значения как готовую финансовую модель продукта.

Они зависят от реального использования, выбранных моделей, тарифов и архитектуры.

Но расчёт позволяет убрать один потенциальный блокер.

Главная неизвестность сейчас не в стоимости обработки.

Главная неизвестность - будет ли пользователь возвращаться к этой функции достаточно часто.

Исследование не доказало спрос

Это главный ограничитель всего вывода.

После большого исследования легко перейти к фразе:

«Я нашёл продукт».

Такого вывода у меня нет.

Я нашёл гипотезу, которая выглядит содержательнее двух предыдущих.

Но пока неизвестно, возникнет ли реальная привычка.

Сколько раз в день или неделю человеку действительно проще говорить, чем печатать?

В каких ситуациях он захочет получить не буквальную транскрипцию, а переработанный текст?

Сколько ручных исправлений останется?

Какая задержка допустима?

Нужен один универсальный режим или разные способы преобразования речи?

Вернётся ли человек к продукту после первого интереса?

Готов ли он платить, если встроенная диктовка уже закрывает часть задачи?

Пока этих ответов нет, продукта в моём понимании ещё нет.

Есть гипотеза работы.

Поэтому следующий этап - не разработка приложения

Если бы я начинал этот проект сегодня, я бы не писал полноценное приложение.

Сначала я провёл бы ручной эксперимент примерно на 20-30 пользователях.

Человек передаёт голосовую мысль.

Получает подготовленный текст.

Дальше я смотрю не на впечатление пользователя, а на его поведение.

Использовал ли он результат?

Сколько пришлось исправлять?

В какой ситуации возникла задача?

Вернулся ли он сам с новой мыслью?

В каких приложениях использовал результат?

Через некоторое количество реальных повторений появляется намного более сильный сигнал, чем ответ на вопрос «Нужен ли вам такой сервис?».

Человек либо начинает использовать новый способ работы, либо нет.

После этого можно проверять готовность платить.

Не вопросом:

«Сколько вы готовы платить за ИИ?»

А реальным выбором:

Период тестирования заканчивается. Готовы ли вы платить, чтобы продолжить пользоваться этим способом?

Если возникает повторяемое использование и оплата, появляется основание переходить к разработке.

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

Что это исследование поменяло для меня

Раньше логика могла выглядеть так:

есть новая техническая возможность -> можно собрать продукт -> нужно придумать удобную интеграцию.

Сейчас я стараюсь двигаться в другом порядке.

Сначала найти повторяющуюся работу.

Понять текущий способ её выполнения.

Определить, где именно возникает потеря.

Проверить изменение поведения самым дешёвым способом.

Получить доказательство повторяемости и оплаты.

И только после этого строить архитектуру.

«Говори дело» для меня хороший пример того, почему это важно.

Сегодня я бы не стал заново делать ни отдельный транскрибатор, ни голосовой интерфейс для создания задач в Bitrix24.

Обе идеи слишком рано фиксируют форму решения.

Гораздо интереснее проверить более фундаментальную работу:

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

При этом исследование рынка добавило ещё одно условие.

Одного умения превращать голос в хороший текст уже недостаточно.

Эту функцию начинают закрывать встроенные и специализированные продукты.

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

Если такая точка существует, из неё можно строить продукт.

Если нет, лучше узнать это до разработки.

Для меня именно это и есть главный результат ретроспективы.

Не новая архитектура.

Не новая нейросеть.

И даже не сама идея «чистовика мысли».

Главный результат - понимание того, что именно ещё нужно доказать до разработки.