• Операционные расходы (хранение, хостинг).
• Затраты, связанные с выходом на рынок (логистические затраты, себестоимость продаж, маркетинговые программы).
• Структура поведения (индекс потребительской лояльности [Net Promoter Score, NPS], уровень удовлетворенности потребителей, опросы).
Надеюсь, теперь вы видите, какую огромную роль играет аналитика в успехе продуктовых команд. Однако, как бы ни были важны и полезны эти данные, важно помнить, что они проливают свет на происходящее, но не объясняют причин. Для интерпретации количественных результатов нам необходимы качественные методики.
(Обратите внимание: аналитические данные часто используются для отслеживания ключевых показателей эффективности [key performance indicators, KPI]).
Работа вслепую
Как ни удивительно, я и сегодня сталкиваюсь с продуктовыми командами, которые либо не используют свой продукт для сбора аналитических данных, либо так мало занимаются этим, что все равно не знают, использовался ли их продукт, и если да, то как.
Мои команды — и каждая команда, которую я могу вспомнить из тех, с какими когда-либо работал, — делают это так давно, что нам даже трудно представить, как можно работать без этой ценной информации. Я даже не могу вспомнить, каково это — не иметь ни малейшего представления о том, как использовался тот или иной продукт, какие фичи помогают пользователю решить его проблемы и те ли это фичи, которые, на наш взгляд, необходимо предложить, чтобы продукт охотно покупали.
Проще всего это делать с помощью «облачных» продуктов и сервисов, и большинство из нас используют веб-аналитику, но иногда мы выбираем для этого собственные инструменты.
Как я уже говорил, хорошие продуктовые команды занимаются сбором аналитики о своих продуктах не один год. И не только с помощью «облачных» сайтов, но и с использованием установленных мобильных приложений или приложений для ПК — локального софта, оборудования и устройств, которые периодически проводят проверку и отправляют командам данные о фактическом использовании их продуктов. Нужно сказать, очень немногие компании сегодня настолько консервативны, чтобы запрашивать разрешение перед отправкой этих данных; в основном все проходит, так сказать, без лишних слов.
Безусловно, надо анонимизировать данные и агрегировать их так, чтобы в них не было никаких сведений, по которым можно установить личность их автора. И все же время от времени в новостях рассказывают о компаниях, которые нажили большие проблемы из-за того, что в своем стремлении выйти на рынок рассылали «сырые» данные. Создается впечатление, что, по мнению журналистов, мы отслеживаем их ради корыстных, гнусных целей, но все компании, с которыми я знаком, просто стараются выпускать лучшие продукты — более ценные, удобные и полезные для людей. А сбор аналитических данных уже давно стал в этом одним из важнейших инструментов.
В общем все происходит так: сначала мы задаем себе вопрос, что нам нужно знать об использовании наших продуктов, затем дополняем продукт возможностями для сбора этой информации (выбор методик зависит от используемого инструмента и от того, какие данные нам нужны). И в конце генерируем онлайн-отчеты в различных формах для анализа собранных данных и их интерпретации.
Мы стремимся располагать инструментами для оценки всего нового, что добавляется в продукт, чтобы незамедлительно узнавать, работает ли он так, как мы ожидаем, и не возникло ли не предусмотренных нами последствий. Честно говоря, без этого инструментария я не стал бы выводить на рынок ни одну новую фичу. Откуда нам знать, как она в действительности работает?
Большинство успешных менеджеров продукта первым делом утром проверяют аналитику, чтобы узнать, что произошло за предыдущую ночь. Они постоянно проводят тестирование в той или иной форме, и им, разумеется, очень интересно, что эти тесты показывают.
Конечно, существуют экстремальные среды, где все происходящее защищено надежнейшими брандмауэрами, но даже в этом случае продакты могут генерировать периодические отчеты об их использовании; эти отчеты анализируются и после получения разрешения направляются продуктовым командам (при необходимости в виде электронных или печатных документов).
Я большой энтузиаст радикального упрощения продуктов путем удаления из них всех функций и опций, которые не способны нести даже свой вес. Но если не знаешь, что и как используется, это становится весьма мучительным, ведь неизвестно, что происходит на самом деле. В этом случае у нас нет данных, которые подтверждали бы наши теории или решения, и наш менеджмент (с полным на то правом) артачится, не желая их принимать.
На мой взгляд, вам стоит начать с признания того, что наличие аналитических данных о продукте обязательно, и стартовать отсюда в обратном направлении, чтобы найти лучший способ их получения.
Глава 55. Тестирование реализуемости
Для того чтобы подтвердить наличие технических возможностей идеи, инженеры-программисты стараются ответить на ряд вопросов по существу дела:
• Знаем ли мы, как это создать?
• Обладает ли наша команда необходимыми для этого навыками?
• Достаточно ли у нас времени для создания продукта?
• Потребуются ли какие-либо изменения архитектуры?
• В наличии ли все необходимые компоненты?
• Понимаем ли мы, какие взаимосвязи и зависимости предполагает реализация идеи?
• Будет ли приемлемой производительность полученного результата?
• Будет ли полученный результат масштабироваться до необходимого уровня?
• Имеется ли у нас инфраструктура для его тестирования и запуска?
• Можем ли мы позволить себе все связанные с этим расходы?
Я не намерен вас пугать. В большинстве случаев ваши разработчики, оценивая идеи новых продуктов на этапе исследования, быстро рассмотрят все эти пункты и ответят, что проблем нет. По большому счету задачи не такие уж и новые, и разработчики уже много раза делали что-то подобное.
Тем не менее к некоторым идеям это не относится, и тогда ответить на эти или даже на многие из перечисленных вопросов бывает очень трудно.
Приведу весьма распространенный пример: сегодня многие команды оценивают технологию машинного обучения, обдумывают решения типа «создавать или покупать» и прикидывают, подходит ли она для выполняемой ими задачи — и, если говорить шире, пытаются оценить ее потенциал.
С удовольствием дам вам несколько важных практических советов на этот счет. Проведение еженедельных планерок, на которых менеджер продукта, предлагая инженерам-программистам готовый список идей, требует дать их оценку с точки зрения затрат времени, насчитать баллы за пользовательскую историю или оценить в других единицах усилий, которые понадобятся для ее реализации, — это верный рецепт краха. Если вы припрете разработчика к стене, не дав ему времени расследовать и обдумать идею, то, скорее всего, получите от него консервативный ответ, нацеленный отчасти на то, чтобы его оставили в покое. Если же ваши инженеры-программисты вместе с другими членами команды тестировали идеи на потребителях (с применением прототипов) и своими глазами видели их проблемы и то, как они отнеслись к этим идеям, значит, у них, по всей вероятности, уже было некоторое время на их обдумывание. Короче говоря, если вы считаете идею стоящей, дайте специалистам возможность изучить и проанализировать ее.
