🔬Про Product Discovery.
В этом году я запускала proof-of-concept нескольких продуктовых решений. В процессе узнала интересное о Product Discovery & Product Delivery, о чём расскажу сегодня. Возможно, для кого-то часть моих наблюдений покажется очевидной, но не для меня :)
Раньше я работала, преимущественно, над улучшением и развитием существующих решений в продукте, поэтому запускать решения с нуля оказалось интересной задачей. В процессе работы, через получение опыта, я осмысляла происходящее с помощью книг, общения с людьми, анализа своего опыта
Рекомендую почитать про Product Discovery, если вы задаете себе любой из вопросов:
- "какие фичи сейчас лучше делать?"
- "как строить продукты от 0->1?"
- "как понять проблемы людей и какие фичи пилить?"
- "как интервью и кастдев встраиваются в продуктовый цикл?"
Задача, которую мы решали с командой, заключалась в нахождении социальных механик, вокруг которых мы можем объединить наших пользователей для их удержания в продукте (вводные про предпосылки, запрос бизнеса и метрики осознанно упускаю)
Начиная работу совсем с нуля, мне оказалось сложным понять в какую сторону лучше всего копать, из-за большого количества неизвестных. В первых итерациях работы мы начали с формулировки проблем, анализа конкурентов, отрисовки прототипов и сбора на них фидбека
За все время работы над проектом, мы проверили больше десятка разных прототипов, собрав на них фидбек от пользователей, лернинги и понимание куда не стоит двигаться. До создания proof-of-concept (разработки) дошло только два
На тот момент, я ещё не дочитала главу Product Discovery в книге Inspired и ещё не осознавала, сколько времени и денег мы сохранили, проверяя часть гипотез и зарубая решения, на этапе прототипирования
В определенный момент, в бэклоге было много разных идей решений для запуска и проверки. Приоритезировать их помогло следующее:
- провести глубинные интервью
- составить список jobs/pains/gains
- выделить ключевые jobs для аудитории
- сформулировать для jobs продуктовые решения
Очевидная вещь, которая упрощает жизнь всем:
jobs -> product solution
problem -> product solution
Без абстрактных идей, не привязанных ни к чему
Что нам дал запуск proof-of-concept:
- собрать первые метрики и воронку
- собрать фидбек на решение у потенциальных пользователей
- получить тонну лернингов и вопросов, о которых раньше не думали
- задуматься про масштабирование- понять что мы не будем делать
Позже, я узнала, что создание proof-of-concept, это часть процесса Product Discovery. К нему прибегают, когда необходимо проверить продуктовое решение на живом прототипе и понять на сколько product solution решает выявленные users problem
Пока писала сегодняшние треды, поняла что мне крайне сложно передать уровень "интеллектуальной боли", которую испытывают люди, находящиеся в ситуации высокой неопределенности и с необходимостью валидировать решения на данных. Удивительно, но на такое ещё можно подъесть :)
В исследованиях легко закопаться и важно определить для себя, в какой точке остановиться в Discovery и перейти в Delivery. Сделала вывод, что оптимальнее работать циклами по 4-8 недель, в которых часть времени уходит на Discovery, а другая часть - на Delivery
В чем я увидела бонусы запуска proof-of-concepts и валидации продуктовых решений на прототипах, в ситуациях когда непонятно какое продуктовое решение должно быть: у команды есть провалидированное видение о том какие дальше можно запускать эксперименты, MVP, до огромной разработки
Во время проведения любого вида пользовательских исследований, важны короткие циклы получения новых данных об изначально поставленных гипотезах. Сделали исследование, показали прототип и спрашиваем себя: "а чего нового узнали? чему научились? какую гипотезу проверили?"
Истина, о которой многие забывают — исследования должны отвечать на конкретные вопросы продакта, помогать сокращать уровень неопределенности и повышать качество принимаемых решений. Исследования ради исследований нет смысла делать
В чем мне помогают исследования?
- сформулировать продуктовую гипотезу
- проверить продуктовое решение
- получить асап обратную связь
- принять решение в отстутсвии необходимого количества информации
- проверить свои галлюцинации
Так вот, если соединить деятельность по исследованиям, выявлению проблем пользователей, прототипированию, валидации решений, то это получается чистой воды Product Discovery. Сначала ищем проблемы аудитории, валидируем решения и дальше уже делаем полноценное Product Delivery
Капнув чуть больше, я сделала для себя вывод, что продукты, созданные от 0 -> 1 запускаются через прохождение шага Product Discovery. Особое искусство — быстро находить продуктовое решение конкретной проблемы и раскатывать его на аудиторию
При любых исследованиях, важно чётко сформулировать и записать бизнесовые и продуктовые метрики, на которые хотите повлиять новым продуктовым решением, а так же быть уверенными на 100%, что вы не можете на них повлиять, не сделав что-то новое. Иначе можно легко уйти не туда
Чем закончилась моя история? После запуска proof-of-concept, мы сформулировали будущие эксперименты, сделали их оценку по разным критериям, поняли что пока не готовы вкладываться в разработку, зафиксировали чему научились и заморозили проект
В книге Inspired есть основные принципы Product Discovery, по которым оценивается продуктовое решение. Для наглядности, вынесла их картинкой
При работе над новым продуктовым решениям, мы с командой попробовали разные фреймворки и способы проверки решений, двигаясь на ощупь. Прочитав книгу Inspired у меня сложилась целостная картинка между Discovery и Delivery, что позволяет сейчас увереннее принимать решения
В книге Inspired рассказывается про процесс создания продуктов, состоящий из двух этапов:Discovery — найти проблему сегмента пользователей и оптимальное продуктовое решение
Delivery — доставить это решение до пользователей и замерить результат
Что я для себя поняла, про создание новых продуктовых решений?
Формулирование целей, продуктовых и бизнесовых метрик
Глубинные интервью и jobs/pains/gains
Брейшнторм jobs -> product solutions
Цикл валидации product solutions
Жестко себя ограничивать во времени
Недавно открыла для себя один из крутых фреймворков для Product Discovery — дизайн спринт (thesprintbook.com/the-design-spr…). На прошлой неделе за три дня придумали с командой решение, проверили его на пользователях и на днях должны будем выкатить на проверку в прод, на часть аудитории
Мой главный инсайт этого года про Product Discovery — на одну человеческую проблему может быть миллион продуктовых решений и искусство заключается в нахождении самого удачного решения (хорошо масштабируется, покрывает кучу кейсов, люди готовы платить и сочетается со стратегией)
Пройденная опытом мудрость: генерация идей, фичей, решений должны быть крепко связаны с проблемами пользователей, а в идеале — начинать генерироваться исходя из проблем пользователей.
Пишу и думаю: "ха-ха, как очевидно, спасибо кэп"
Параллельно: "ага, попробуй так жить"
Пока изучала вопрос, нашла несколько примеров компаний, DNA которых состоит из исследований и инноваций — Spotify, Airbnb, Netflix, Tier, Facebook. Самый простой способ понять, на сколько компания заинтересована в инновациях — чекнуть вакансии и найти Product Manager Innovation
Напоследок поделюсь книжечками и блогом, прочтение которых дало мне щепотку продуктовой уверенности.
- Inspired, Marty Cagan
- Блог svpg.com/insights/produ…
- От 0->1, Питер Тиль
- Менеджмент в 21 веке, Питер Друкер
Спасибо, что читаете и делитесь в телеге своими впечатлениями💜 Я немного переживаю, что некоторые мысли могла раскрыть коряво. Пишите в телегу, если захотите любой из вопросов обсудить подробнее tg:@ochkina.
В программе на завтра — инсайты про community based продукты
Кристина Очкина