Product Management без ошибок. Гид по созданию, управлению и успешному запуску продукта

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

С момента опубликования «Бережливого стартапа» компании начали применять методы экспериментов, однако многие из них делают это по неправильным причинам. Все они пытаются создать идеальный минимально жизнеспособный продукт (MVP) – концепцию экспериментов, представленную в книге. Я спросила своих подписчиков в Twitter, как они определяют MVP в своей компании. Мне ответили многие, но один из подписчиков хорошо подытожил: «Два разных клиента сказали мне, что все, что мы создаем в первом релизе, является MVP».

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

Самая важная часть MVP – это обучение, поэтому мое определение всегда звучало как «минимальное количество усилий для обучения». Получается, мы ориентируемся на показатели, а не на результат.

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

Product Kata – отличный инструмент для того, чтобы заложить основу для обучения. Она всегда задает вопрос: «Какой будет следующий шаг?» Такой метод удерживает команду на верном пути и настраивает ее на создание правильного типа экспериментов.

Существует множество способов экспериментов. Concierge («Консьерж»), Wizard of Oz («Волшебник страны Оз»), тестирование концепции – вот три примера экспериментов, о каждом из которых я расскажу вкратце.

Поскольку экспериментальные решения не предназначены для длительного использования, вы ограничиваете воздействие на клиентов. При любом эксперименте важно продумать, как вы его завершите, чтобы «замкнуть цикл». Установление ожиданий – это ключ к тому, чтобы клиенты остались довольны и снизили риск неудачного эксперимента. Объясните им, почему вы проводите тестирование, когда и как закончится эксперимент, и что вы планируете делать дальше. Коммуникация – это главный инструмент.

Консьерж

Эксперимент, который компания Marquetly

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

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

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