Почему кнопки сами по себе не создают управленческую ценность

После первых двух статей мне могут задать следующий вопрос.

Его вполне логично задают консультанты, наставники, продуктовые эксперты, акселераторы и инвесторы:

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

На первый взгляд, ответ очевиден.

Конечно, должен.

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

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

Но здесь есть важная подмена.

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

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

Техническая самостоятельность выглядит убедительно

Со стороны всё просто.

Пользователь сам вошёл в систему.

Сам выбрал период.

Сам открыл отчёт.

Сам поставил фильтр.

Сам посмотрел карточки.

Сам выгрузил данные.

Значит, продукт работает.

Для простого инструмента этого иногда достаточно.

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

Получилось или не получилось.

Но в нашем продукте кнопка не является конечным действием.

Кнопка лишь открывает доступ к следующему управленческому решению.

Отчёт сам по себе не меняет продажи.

Фильтр не обучает команду.

Карточка звонка не создаёт новый стандарт.

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

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

Более того, он может получить вредный результат.

Между интерфейсом и результатом находятся люди

Наш продукт работает не напрямую.

Он работает через руководителя.

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

Получается цепочка:

коммуникации -> данные -> гипотеза -> критерий -> интерпретация -> управленческое решение -> действия руководителя -> действия сотрудников -> реакция клиентов -> повторное измерение.

Технически корректный отчёт находится только в начале этой цепочки.

Ошибка может возникнуть на любом следующем шаге.

Руководитель может выбрать неправильный вопрос.

Может сформулировать критерий слишком широко или слишком узко.

Может принять совпадение за причину.

Может увидеть низкую цифру и сразу решить, что проблема в сотрудниках.

Может превратить временную гипотезу в постоянный KPI.

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

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

Может вообще ничего не сделать и больше не вернуться к отчёту.

Во всех этих случаях пользователь технически самостоятельный.

Но управленческой ценности не возникло.

Почему я не считаю нажатие кнопок главным доказательством

Я видел много сложных IT-продуктов, в которых формально есть всё.

Разделы.

Настройки.

Отчёты.

Инструкции.

Видео.

База знаний.

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

Но дальше происходит знакомая история.

Человек открывает несколько экранов.

Пробует что-то настроить.

Не до конца понимает, какой вопрос решает.

Не видит быстрого результата.

Откладывает продукт.

Через несколько дней или недель перестаёт возвращаться.

С технической точки зрения продукт был доступен.

С продуктовой точки зрения переход к ценности не состоялся.

Я не хочу повторить этот путь.

Для нас недостаточно создать продукт, в котором можно самостоятельно разобраться.

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

Это более сложная задача.

Простой интерфейс может автоматизировать неправильную логику

Есть опасное искушение.

Когда клиенту трудно пользоваться продуктом, кажется, что решение всегда одно:

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

Все эти решения могут быть правильными.

Но только после того, как мы поняли, какой путь нужно упрощать.

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

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

Можно дать ему готовый шаблон.

Он нажмёт одну кнопку.

Система посчитает показатель.

Интерфейс будет удобным.

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

Технически продукт сработал идеально.

Управленчески он начал вредить.

Поэтому сначала мы проверяем сам путь.

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

Три уровня самостоятельности

Для себя я разделяю самостоятельность пользователя на три уровня.

Первый уровень - технический

Пользователь понимает, куда нажать.

Он может:

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

Это обязательный уровень.

Без него продукт останется инструментом оператора.

Но этого недостаточно.

Второй уровень - аналитический

Пользователь понимает, что именно он видит.

Он способен:

• сформулировать проверяемый вопрос;
• отличить симптом от гипотезы;
• понять границы критерия;
• проверить спорные карточки;
• увидеть, где AI и человек расходятся;
• не принять одну цифру за окончательную истину;
• отделить закономерность от единичного примера.

Это уже существенно ближе к ценности.

Но даже здесь цикл не завершён.

Третий уровень - управленческий

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

Он понимает:

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

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

Не способность нажать кнопку.

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

Почему это особенно важно для нашего рынка

Мы работаем с компаниями разного уровня зрелости.

У одного клиента есть сильный собственник и опытный РОП.

У другого руководитель перегружен операционкой.

У третьего критерии существуют только на словах.

У четвёртого собственник и сотрудники по-разному понимают, что такое хороший звонок.

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

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

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

Наша задача - не заменить руководителя.

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

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

Такие пользователи важны.

Но их недостаточно для большой компании.

Почему самостоятельный пользователь всё равно нужен

В предыдущей дискуссии внутри команды прозвучал важный сигнал.

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

Я с этим согласен.

Именно они показывают:

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

Такой пользователь является ценным партнёром по разработке.

Но я не считаю его единственным доказательством product-market fit.

Он может быть технически сильным.

Может искренне интересоваться продуктом.

Может построить отчёт.

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

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

Как я хочу наблюдать самостоятельную работу

Мне недостаточно видеть, что пользователь вошёл в систему.

Я хочу увидеть весь путь.

Например:

1. С какой задачей он пришёл.
2. Как сформулировал вопрос.
3. Что выбрал в интерфейсе.
4. Где сомневался.
5. Какие карточки проверил.
6. Как интерпретировал результат.
7. Какое решение принял.
8. Что сообщил команде.
9. Как изменилось поведение.
10. Вернулся ли он к повторному измерению.

В этот момент становится видно, где продукт действительно помогает, а где пользователь достраивает путь самостоятельно за счёт собственной компетенции.

Также становится видно, где сейчас нужен:

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

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

Что должно постепенно исчезать из моей работы

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

Наоборот.

Каждый повторяемый элемент моего участия должен получить следующий вопрос:

Почему это пока делаю я?

Возможны разные ответы.

Потому что интерфейс не позволяет

Тогда нужна продуктовая задача.

Потому что пользователь не понимает принцип

Тогда нужен onboarding, пример или обучение.

Потому что критерий неоднозначен

Тогда нужна механика калибровки.

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

Тогда нужна проверка, ограничение или обязательное подтверждение руководителя.

Потому что случай сложный и редкий

Тогда, возможно, человек должен остаться в процессе.

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

Тогда пора передавать.

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

Именно этого результата я ожидаю от текущей стадии.

Что мы должны встроить в продукт

Когда повторяемый путь становится понятен, его можно переносить в систему.

Не только отдельные функции, а последовательность.

Например:

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

В этот момент интерфейс начинает не просто отображать данные.

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

Именно такую самостоятельность я считаю целью.

Где проходит граница между помощью и зависимостью

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

Оно становится проблемой, если:

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

Это уже не исследование.

Это зависимость.

Поэтому я не защищаю ручную работу как постоянную модель.

Я защищаю последовательность.

Сначала понять, что создаёт ценность.

Потом описать путь.

Затем наблюдать пользователя на этом пути.

После этого встроить повторяемые опоры в продукт.

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

Как мы поймём, что продукт стал самостоятельным

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

В сложном продукте вопросы останутся.

Главный признак в другом.

Пользователь способен без моего постоянного участия:

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

Он может обращаться за помощью в сложных случаях.

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

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

Почему мы пока не перескакиваем к ней

Потому что нельзя встроить в интерфейс путь, который ещё не понятен.

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

Нельзя дать сотруднику внедрения критерии качества, которых ещё нет.

Нельзя автоматизировать безопасное решение, пока не известны его границы.

И нельзя объявить продукт самостоятельным только потому, что в нём появились кнопки.

Кнопки важны.

Интерфейс важен.

Простота важна.

Но они должны упрощать уже найденный механизм ценности.

А не маскировать его отсутствие.

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

После этого мы сможем честно перенести его в продукт.

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