Текст книги "Карьера продакт-менеджера. Все что нужно знать для успешной работы в технологической компании"

Глава 11
Определение объемов и пошаговая разработка

Когда я только стала PM, мне хотелось, чтобы мои продукты были идеальными. Я изучила проблемы клиентов и составила длинный подробный список функций, которые покрывали бы все потребности. Мой идеализм очень быстро разбился о реальность, когда я узнала, что на разработку у меня есть только 40 дней. А для того, чтобы выполнить все пункты моего списка, потребовалось бы как минимум 100!

Так я столкнулась с вопросом определения объемов работ: мне предстояло научиться аккуратно выбирать, что включать в список задач, а что нет. Сказать «да» одной функции означало сказать «нет» другой. Стоит ли поработать над тем, чтобы показать количество комментариев к каждому сообщению в блоге, или лучше потратить это время на упрощение загрузки изображений? Сделать ли вики-страницы настраиваемыми или полезнее вместо этого сократить время загрузки страниц?

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

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

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

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

Это вовсе не значит, что наш подход – установить дату и выбрать продукт для запуска – подходит для других сценариев. Когда я пришла в Asana, разработка велась в течение нескольких лет, но публичного запуска пока не было. Произвести его немедленно было бы ошибкой, так как хороший запуск должен вызвать резкое увеличение спроса, по крайней мере, это предполагается. Для нас было важно представить продукт высокого качества, даже если бы это было на месяц или два позже.

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

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

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

ПОШАГОВАЯ РАЗРАБОТКА

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

Одним из самых известных примеров, иллюстрирующих такой подход, является метафора Хенрика Книберга (Henrik Kniberg) о скейтборде[61]61
  Подробнее об этом Хенрик Книберг рассказывает в своем блоге: https://blog.crisp.se/2016/01/25/henrikkniberg/making-sense-of-mvp.


[Закрыть]:

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

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

Многие продуктовые идеи не несут никакой пользы клиенту или бизнесу в первом своем воплощении. Как сказал Марти Каган в своей книге «Inspired»: «Половина наших идей просто не сработает». Даже у лучших PM есть много идей, которые в конечном итоге не оказывают ожидаемого воздействия. Разница в том, что хорошие PM оценивают свои идеи на раннем этапе, чтобы быстро отбросить неудачные варианты и потратить больше времени на создание продукта, который действительно будет работать.

МИНИМАЛЬНО ЖИЗНЕСПОСОБНЫЙ ПРОДУКТ (MVP)

Определение минимально жизнеспособного продукта (minimum viable product, MVP) из книги Эрика Риса (Eric Ries) «The Lean Startup»[62]62
  Рис Э. «Бизнес с нуля. Метод Lean Startup для быстрого тестирования идей и выбора бизнес-модели».


[Закрыть] звучит так: «Это версия нового продукта, позволяющая команде собрать максимальное количество проверенных сведений о клиентах с минимальными усилиями»[63]63
  Подробнее о MVP читайте на сайте http://www.startuplessonslearned.com/2009/08/minimum-viable-product-guide.html.


[Закрыть].

В качестве MVP может выступать ранний рабочий прототип, но это необязательно. Чтобы измерить интерес пользователей, можно запустить кампанию AdWords. Или добавить кнопку, при нажатии на которую появляется сообщение: «Скоро в продаже». Можно сымитировать работу бэкенда, выполняя операции вручную.

Распространенные ошибки при работе с MVP

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

Низкокачественные эксперименты: MVP «Горелая пицца»

Дес Трейнор (Des Traynor), соучредитель Intercom, поделился мысленным экспериментом. Одна команда попыталась выяснить, существует ли рынок сбыта пиццы. В целях экономии участники взяли второсортную печь. В итоге пицца каждый раз подгорала, и покупать ее никто не хотел. Но доказывает ли это, что рынка сбыта для пиццы не существует? Нет! Это лишь говорит о том, что нет рынка сбыта для горелой пиццы.

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

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

Недоработанный и неустойчивый продукт

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

Например, пользователям понравился интерфейс Inbox (недолговечного почтового приложения от Google), но компании не удалось перевести корпоративных клиентов Gmail на новый продукт без воссоздания многих расширенных функций Gmail. В результате продукт был неустойчивым и продаваться не стал. Было принято решение отказаться от него и интегрировать отдельные элементы пользовательского интерфейса в Gmail, вместо того чтобы поддерживать две кодовые базы. Если бы команда с самого начала сосредоточилась на устойчивости продукта, ей, возможно, удалось бы найти подход, основанный на имеющейся функциональности Gmail.

ВРЕМЯ И ЦЕННОСТЬ

Улучшения продукта не несут никакой ценности, пока ими не начнут пользоваться.

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

Конечно, потраченное на доработку время сделает продукт лучше.

Чтобы выбрать время запуска, можно воспользоваться следующим графиком:

При выпуске релизов в контрольных точках 1 и 2 ценность продукта, полученная пользователями, равна зонам А и В. Если же первый запуск произошел лишь в точке 2, ценность соответствует только зоне В. Чем больше зона А, тем логичнее задуматься о более раннем запуске. Если продукт после первой контрольной точки уже приносит большую пользу или если до точки 2 должно пройти много времени, то лучше запустить продукт раньше и продолжить итерации.

РАЗБИВАТЬ ПРОЕКТ НА НЕСКОЛЬКО ЗАПУСКОВ И ПРОВОДИТЬ ПРОВЕРКУ НА РАННЕЙ СТАДИИ

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

Вот несколько советов о том, как можно разбить запуск продукта на несколько этапов:

• По допустимости риска и уровню дружелюбия: начните с релиза для пользователей, которые терпимо отнесутся к большинству багов, недостатку функциональности и проблемам с интерфейсом, чтобы получить обратную связь до того, как все эти моменты будут отточены. Можно разбить релиз так: сначала выпустить версию для тестирования в команде и внутри компании (догфудинг); далее – бета-версию для лояльных клиентов, затем сфокусироваться на новых пользователях, после – на всех остальных; и, наконец, осуществить полный запуск. Онбординг и продажу премиум-версии можно отложить до начала экспериментов с новыми пользователями.

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

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

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

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

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

Единственное, чего нельзя делать – это отказываться от шлифовки.

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

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

Следите, чтобы объем работ не был слишком маленьким

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

НЕПРАВИЛЬНОЕ ОПРЕДЕЛЕНИЕ ОБЪЕМА РАБОТ

Ноа Гано (Noa Ganot) поняла, во что может вылиться слишком маленький объем работ, выбирая, какие версии баз данных будет поддерживать продукт, который разрабатывала ее компания. Сначала предполагалось, что это будут только самые популярные версии, а новые всегда можно быстро добавить, если это потребуется клиенту.

К сожалению, при таком раскладе отделу продаж приходилось узнавать, какую конфигурацию использует каждый клиент, вместо того чтобы уверенно заявлять, что поддерживаются все версии. На раннем этапе это было приемлемо, но в какой-то момент стало проблемой. Некоторые клиенты даже не знали, какую версию базы данных они используют. Гано узнала об этой проблеме, поговорив с сотрудниками отдела продаж. Она поняла, что это тот случай, когда попытка не только удовлетворить срочные потребности клиентов, но и выполнить более масштабную работу (обеспечить поддержку всех версий баз данных, даже тех, которые пока не запрашивали) стоила вложений. Команда внесла изменения и в результате получила увеличенную конверсию продаж.

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

СОГЛАСОВЫВАТЬ ДЕЙСТВИЯ КОМАНДЫ ПО ПРИНЦИПУ БЕРЕЖЛИВОГО MVP

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

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

• Страх того, что код останется в незавершенном состоянии: найдите способы сделать так, чтобы код был дописан до конца. В зависимости от принятых в вашей компании процедур это могут быть четко обозначенные OKR, общее понимание того, что подразумевается под словом «готово», установленная для всех дата запуска или фиксированный процент пользователей будущего обновления. Список дополнительных работ, которые команда должна выполнить, прежде чем перейти к новой задаче, лучше начать составлять как можно раньше.

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

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

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

ВКЛАДЫВАТЬСЯ В СИСТЕМЫ, КОТОРЫЕ ПОДДЕРЖИВАЮТ ПОШАГОВУЮ РАЗРАБОТКУ

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

Если самым уязвимым местом является дизайн, направьте основные силы и средства на развитие системы проектирования и создание повторно используемых компонентов. С точки зрения процессов, можно установить правила «кратчайшего пути». Например, можно ввести правило, по которому любые А/В-тесты с использованием имеющихся компонентов будут проводиться без дизайн-ревью или согласований на высшем уровне.

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

ПРИЗНАЙТЕ, ЧТО ВЫ НЕ ЗНАЕТЕ ТОЧНО, КАКИМ ДОЛЖЕН БЫТЬ ПРОДУКТ

Велосипедные шлемы – хорошая штука, не так ли? Они снижают риск летального исхода от удара головой при падении минимум на 50 %. Как шлем вообще может навредить? Ну, разве что испортить прическу?

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

Кто-то не хочет таскать с собой шлем и предпочитает доехать на встречу на машине – поэтому трафик на дорогах усиливается, количество велосипедов снижается, загрязнение растет, люди меньше двигаются, перестают понимать, как обращаться с велосипедом на дороге, и т. д. В Австралии после введения закона об обязательном ношении шлемов был отмечен резкий спад использования велосипедов[64]64
  Из книги Джона Адамса (John Adams) «Risk», 1995 год.


[Закрыть]. Вот так.

ТО ЕСТЬ ШЛЕМЫ – ЭТО ПЛОХО?!?

Нет! Мы не выступаем против шлемов. Нисколько. Именно шлем спас моему мужу жизнь, ну или по крайней мере функционирующий мозг, несколько лет назад[65]65
  С другой стороны, если бы мой муж ездил без шлема, возможно, он не стал бы так лихо входить в повороты и его кости и шлем были бы целы.


[Закрыть].

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

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

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

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

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

ПЛАНИРУЯ ОПТИМИЗАЦИЮ, УЧИТЫВАЙТЕ СРОКИ

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

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

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

• Стоимость работы с точки зрения дополнительного времени на решение этих вопросов: сколько процентов от общего времени оно составляет и как повлияет на распределение контрольных точек. Если затраты невысоки и вы можете уложиться в срок, то можно рассмотреть добавление задачи в общий перечень работ.

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

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

• Сроки оптимизации (шесть месяцев или год). Будет рискованно тормозить работу ради выгоды, которая не окупится и через полтора года.

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

УТОЧНЯЙТЕ И УПРОЩАЙТЕ ГИПОТЕЗЫ

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

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

УТОЧНЕНИЕ ГИПОТЕЗЫ

Когда Сэм Гертлер (Sam Goertler) работала PM в Asana, ей поручили разобраться с тем, что продукт казался клиентам слишком сложным в использовании. Вместе с командой она превратила эту неоднозначную и трудноразрешимую проблему в такую гипотезу: если добиться максимальной ясности для данного сценария управления проектом, количество новых пользователей увеличится. Затем она сократила ее до фразы «максимальная ясность», чтобы всем было проще эту идею запоминать, применять и передавать.

Это уточнение помогло команде разрешить такие сложные задачи, как изменение дизайна, направленное на оптимизацию всех других сценариев управления проектами. Вскоре все члены команды на любой вопрос отвечали: «Какой вариант обеспечит максимальную ясность?»

ПООЩРЯЙТЕ ПРИМЕНЕНИЕ КОНЦЕПЦИИ MVP И ПРОТИВОДЕЙСТВУЙТЕ ПЕРФЕКЦИОНИЗМУ В СВОЕЙ ОРГАНИЗАЦИИ

Для многих людей перфекционизм не представляет собой ничего ужасного – когда кто-то говорит, что это его самая слабая сторона, многие воспринимают это как шутку.

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

Чрезмерная трата времени на выполнение какой-то задачи приводит ко многим проблемам:

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

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

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

Вы, как руководитель, должны сделать так, чтобы ошибаться было безопасно. Если команда извлекла урок из какой-то ситуации – отпразднуйте это. Удалось четко определить объем работ – похвалите. Не позволяйте людям подтрунивать друг над другом за неправильный выбор. Проследите, чтобы время итераций после запуска MVP не сокращалось, – у команды должно быть время на применение полученных знаний. Убедитесь, что цели команды или OKR не противоречат принципам пошаговой разработки. Укажите людям, на какие задачи они могут тратить меньше времени.