Product Discovery: From Assumptions to Validated Hypothesis

Спасибо. Все, можем начинать. Сегодня тема, в принципе, достаточно понятная из названия, но немножечко раскрою подробности про бизнес-анализ и про продукт-менеджмент. И в частности... Вот мой шифт из бизнес-аналитиков в продакт-менеджеры и какие скиллы, какие техники на пути продакт-менеджмента я нашел, которые могут быть полезны, во-первых, для всех начинающих продакт-менеджеров и не только начинающих, но и также для бизнес-аналитиков, и которых мне, в частности, очень не хватало, и я очень жалею, что не знал об этих стволах раньше, когда вот работал бизнес-аналитиком. Поэтому коротко начну о себе. В принципе, стартанул как разработчик в 2010 году. Тогда я познакомился с нашим хостом, работали вместе в одной компании. Работал как программист около пяти лет, может, даже шесть. Потом перешел в бизнес-анализ, стало немножко не хватать бизнес-контекста, домена. Познакомившись с бизнес-анализом в Беларуси, переехал в Черногорию. Там стал работать уже в продуктовой компании, занимался в основном финтехом и приобрел первые такие навыки продукт-менеджмента. А потом уже сел в Бельгия, где стал заниматься разными вещами, но все с продукт-менеджментом связано. Первое это было стартап. в котором, в принципе, был единственным продукт-менеджером, поэтому такое оверси на все возможные продукты, все возможные сервисы. Но в этом есть и плюсы, и минусы. Плюсы, потому что узнаешь очень много бизнеса, минусы, потому что тяжело фокусироваться. И где я сейчас? Сейчас работаю в оттехе, занимаюсь, в принципе, разработкой продуктов для паблишеров. Это вот такие. Digital Publisher, то есть новостные сайты, либо социальные сети, которые показывают рекламу, которые на этом пытаются зарабатывать, либо зарабатывают. Ну и в общем мы предлагаем для них платформы, решения, продукты, которые помогают их контент монетизировать. Ну плюс держать юзеров, так сказать, в хорошем настроении, не отвлекать их рекламой, показывать нужную рекламу и так далее. Поэтому мой фокус на B2B системы. Очень сложные, громоздкие. И большая часть моих discovery происходит с техническими стакхолдерами, но также есть и с бизнес-частью. Это коротко о себе. А что сегодня получите вы и о чем мы будем говорить? Первое просто внедрение. Introduction-то совсем уже русский путается. Обзор Product Management, скиллов для бизнес-аналитиков, которые могут быть полезны. Потом рассмотрим Use Case, Case Study, который произошел со мной, как я общался с одним из наших клиентов, какие вопросы задавал, какие не задавал, какие стоило бы задать. Это потом уже ретроспективно поняли, изучили. И сегодня хочу с вами поделиться. Ну и последняя, самая, наверное, интересная часть, это где мы посмотрим, как из assumptions, предположений, мы можем сформулировать гипотезы, когда стоит формулировать гипотезы, когда не стоит формулировать гипотезы, ну и, соответственно, как их протестить, провалидировать assumptions, либо протестить гипотезы, и какую пользу это дает. В принципе, это все насчет введения, и можем начинать. Первая часть, что есть Discovery, зачем оно нужно и вообще действительно ли оно важно. Discovery очень важно. Это сразу ответ на все вопросы. Почему? Потому что Discovery помогает понять, в принципе, стандартный подход с этим Why Questions. когда мы задаем клиенту, либо стейк-колдеру, либо юзеру, зачем тебе это надо, зачем тебе это надо, зачем тебе это надо, повторяю, но тоже несколько раз, но углубляюсь каждый раз все больше и больше в problematic space, чтобы понять, в чем же pain point нашего клиента, либо юзера. У бизнес-аналитиков есть большое преимущество в этом плане, потому что чаще всего вы ближе всего находитесь к стейк-колдерам, к данным, к требованиям. То есть вы можете задать эти вопросы, и можно, конечно, рассчитывать, что их задаст project manager, что их зададут технические специалисты, девелоперы, либо QA, но на самом деле самое выгодное время и место задавать их, будучи бизнес-аналитиком, на этапе сбора требований, на этапе изучения проекта. И у Тереза Торас есть такое понятие, как continuous discovery. Это то, в принципе, к чему я сейчас пришел, что discovery, оно не заканчивается. То есть это не как в waterfall или в любом другом подходе, что сначала мы что-то discover, потом мы отдаем в разработку, потом мы получаем фидбэк, как оно работает или нет. Discovery происходит бесконечно. То есть мы каждый день что-то узнаем. Это не обязательно большое discovery. сильные ресерчи, но каждый день мы пытаемся узнать что-то новое у клиентов, каждый день пытаемся узнать что-то новое о нашем бизнесе, и каждый день идет фидбэк в разработку, идет фидбэк в заказчиков, идет эволюция продукта. Поэтому продукт-менеджеры часто основывают свое мышление на гипотезах, которые помогают драйвить это discovery. Дальше мы посмотрим, как формировать GIF-от, что это такое. Но в целом понятно, что мы вместе строим и пытаемся понять, что же надо, а не то, что просят. И первый assumption, который, собственно, хотелось сюда добавить, и который будет потом у нас красной нитью еще появляться. Stakeholder. Да, короче, заказчик знает, или клиент, с кем мы общаемся, знает, что он хочет. И знает все. На самом деле то, что происходит в маленьких стартапах, это одна история. Если вы работаете в них, возможно, вам повезло, и вы действительно знаете все, либо ваш клиент знает все. Когда же мы говорим про крупные комплексные системы, тут такое возникает, что любая крупная компания имеет кучу департаментов, филиалов, подразделений, продуктов. Очень редко находится человек, который знает все и понимает бизнес-составляющую. Даже человек, который пришел к вам, покупает ваш продукт, либо ваш сервис, возможно, он не совсем понимает или не совсем знает все аспекты. И тут помогает Continuous Discovery тем, что с продуктовым мышлением можно себя ставить на место заказчика, можно пытаться понять, в чем бизнес-идея, в чем выгода. Как можно помочь клиентам? Чтобы закрепить вот это все, теорию и слова, я хочу поделиться вот кейс-стадий, который произошел со мной и с одним из наших клиентов. Это как раз онлайн кинотеатр. Я не знаю, насколько аудитория знакома с оттехом, но, в принципе, прояснить достаточно понятно, думаю, будет. Есть онлайн кинотеатр, который приходит к нам и говорит, ваш продукт умеет считать показы рекламы, и мы хотим себе дашборд, который будет показывать, как много рекламы было показано перед фильмом, либо во время фильма, либо после фильма. То есть есть CTV device, вот это connected television, в нем показываются фильмы. Онлайн кинотеатр просто хочет знать, как много рекламы было показано. Достаточно понятное требование, ничего сверхъестественного, потому что, скорее всего, они получают деньги за показ рекламы, плюс могут мониторить, сколько юзеров было, и в целом это их бизнес-модель. Но, как говорится, очень важно в этот момент остановиться и подумать над тем, что мы сейчас делаем очень много предположений за клиента, за конечного юзера. То есть к нам пришли задачи. Мы хотим дашборд, как много рекламы. И мы можем, в принципе, прыгнуть сразу в вопросы. Как часто вам надо эти данные? То есть мы же уже умеем считать рекламу. Вам надо это каждый день? Real-time, не real-time? А какие видеоплееры используете? А как вы будете использовать данные? Будете ли вы их экспортить в какие-то там CSV-форматы, что-то свое добавлять, либо просто будете юзать наш дашборд? Также какие-то UI-ные вопросы можно спрашивать, какие системы они используют для анализа этих данных. Но в чем каверность этих вопросов? В том, что это все находится в solution space, в плоскости работы с решением. То есть мы уже решили, что мы действительно верим тому, что им действительно надо дашборд. который будет показывать рекламу, и мы уже работаем над решением. Мы можем спросить про фреймворки, про SDK разные, про разные системы, которые они используют, но покуда мы находимся в плоскости обсуждения решения, это блокирует и продукт-менеджеров, и бизнес-аналитиков. В принципе, я считаю, что бизнес-аналитики как раз-таки те люди, которые должны говорить stop solution space. Давайте назад вернемся или там на один уровень выше и поговорим про Problem Space. Не все клиенты захотят это делать, не все клиенты к этому всегда расположены. Но как только вы покажете value в этих вопросах, почему это надо знать, всем станет все понятно. И я, если честно, никогда не встречал какого-то пушбека сильного, поэтому мне будет интересно потом с вами поговорить, услышать ваш опыт. Что такое Problem Space? Это когда мы ставим под сомнение самое-самое первоначальное требование. То есть клиент пришел к нам и говорит, мы хотим дашборд, который будет показывать, сколько рекламы. А мы спрашиваем, зачем ты пришел их? Ну, понятно, наша мотивация, он пришел, чтобы использовать наш продукт, чтобы заплатить нам деньги, чтобы заработать деньги. Поэтому мы спрашиваем, в чем мотивация, а как ты будешь использовать эти данные? А насколько они важны для вас? Важны ли они вообще для вас, вот как для клиента? Может быть, этот онлайн кинотеатр пришел и просит у нас эти данные, потому что рекламодатели его заставили, потому что рекламодатели сказали, что нам нужны какие-то данные. А может быть, он в процессе какой-то сертификации, которую хочет... лейблочку себя повесить, и ему надо именно наши данные, а не свои. Может быть, его готовится поглотить, одна компания другую, либо замерчить, и им необходимо сейчас показать value. Какие решения будут приниматься на основе этих данных? То есть, чтобы понять, будет ли клиент и его тиммейты смотреть на этот дашборд каждый день, либо они будут использовать это, например, в сел спич то есть там когда нового рекламодателя хотят заонбордить они будут показывать что вот смотри как красиво может быть дэйли операция то есть каждый день будут принимать решения на основе наших данных следующий вопрос был там что нужно рекламодателям из вашей данной какие проблемы мы решаем и поднявшись вот на этот уровень мы получим совершенно Другие ответы, которые не касаются нашего решения с дашбордом, но которые помогут нам выстроить лучшее решение, лучший продукт для нашего клиента, ну и в целом для нас самих, чтобы продукт развивался. Поэтому если есть желание и возможность написать чат, было бы интересно послушать, какие типы вопросов вы задаете чаще всего. Есть ли у вас возможность вообще, так сказать, подняться на уровень discovery questions? То есть, чтобы оценить проблему Space, а не только solution. И если вот вы пробовали, какой был фидбэк, получалось ли или там получали сильный пушбэк от доказчиков. Я заодно пока воды попью. Да, напишите, пожалуйста, в чат, когда вы посмотрели на эти вопросы, какие вам стали больше знакомы, первые, высшие или вторые. Пока вы пишете, расскажу свой опыт. Когда я увидела этот слайд, я вспомнила сразу, что при попытке, например, в аутсорсе, когда работала, клиент приходит и говорит, мне нужно вот это посчитать, сколько стоит и за какое время вы это сможете заделиверить. И когда задаешь вопрос, а зачем, как вам эта идея пришла, там еще что-то, Это вызывало удивление. Типа, вы посчитайте мне, сколько это будет стоить. Я не хочу говорить, как я к этому пришел. Но когда они делились, это было прям очень классно. Я помню проект с принтером. Это, то есть, IoT-проект. И они хотели одну фичу, и было совсем непонятно, зачем она. Потом оказалось, что... Это принтер компании Epson, а у конкурентов Samsung и HP эта фича есть, и она просто нужна Epson, чтобы быть такими же конкурентоспособными. То есть тут не про юзеров, а про конкурентоспособность. Это было очень важно узнать. Так, у нас в чате появились ответы. Да, в основном, у нас все редко отвечают на Discovery вопросы, особенно в больших заказчиках. Это факт. Очень печальный факт. Но я могу сейчас сказать, что я уже работаю в продуктовых компаниях в последнее время. И мы тоже пользуемся услугами аутсорса, разными другими командами и моделями. И в целом всегда только рады. когда задают такие вопросы и готовы делиться этим. Естественно, это зависит от заказчика, но идея в чем, что надо показать value для заказчика, почему этим важно делиться. Это точно так же, как любой разработчик, если вы ему напишите задачу, перетащи кнопку слева направо, поменяй флоу для регистрации, и он сделает это без вопросов, ну как бы... Время разработчиков достаточно дорогое, поэтому намного выгоднее, если они спросят, а зачем мы это делаем, и потом окажется, что у них есть идея лучше. Я в целом всегда считаю, что у всех вокруг есть идея лучше, чем у меня, поэтому это... Как раз-таки очень больно для начинающих продукт-менеджеров, что приходят с желанием, что вот у меня есть идея, она самая лучшая, она должна быть реализована, потому что я продукт-менеджер, у меня должна быть идея. Ну, как раз-таки, к сожалению, нет. Зачастую вокруг нас намного больше умных людей, которые могут принять какие-то идеи и сгенерировать. Задача продукт-менеджера – выбрать эту идею, и потом, если она… как говорится, не выстрелит принять на себя ответственность, что решение-то было за мной. Но это... Да, я смотрю в чате. То есть я к чему веду, потому что если вы покажете, в чем ценность этих вопросов, и я на следующем слайде как раз покажу, в чем ценность, в чем разница первого подхода со вторым, в моем случае работа с кинотеатром. Может быть, получится и у вас убедить заказчиков, что ценность есть. Покажите два слайда, все, заказчиков всем поделится. Но тут проблема в том, что иногда бывает, что заказчик и сам не знает этого контекста. И если вы спросите определенный point of contact, который является представителем заказчика, а в чем бизнес-модель, зачем мы строим нужные дашборды, репорты, Возможно, он просто не в курсе, не знает, либо знает что-то другое, и ему тяжело из-за этого объяснить. Поэтому тут желательно просто мягко показать, в чем ценность. Надеяться, что он придет с ответами. В аутсорсе редко отвечают на discovery вопросы, особенно в больших заказчиках. Все тот же вопрос. Заказчик должен увидеть value. в том, что он тратит время на объяснение этих вопросов. Но в целом value практически всегда есть, потому что любой бизнес-аналитик, в принципе, по названию должности, должен анализировать бизнес и понимать, в чем модель бизнеса. Потому что если просто реализовывать то, что заказчик просит, может получиться следующее, что вы сделаете то, что заказчик вас попросил или убедил, или не предоставил контекст. Через месяц заказчик придет и скажет, все, мы поменяли идею, надо вернуть как было. Вот что-то у меня подсказывает, что такое в аутсорсе бывало, и у меня у самого такое бывало. Но самое печальное в этот момент в том, что заказчик в итоге будет считать, что это хоть и его ошибка, что он там одно попросил, потом второе, но все-таки вы согласились, вы сделали, время потратилось. Деньги потратились, а назад тоже время не вернусь. Поэтому лучше пару раз сделать неприятно, задать эти вопросы через какой-то там пушбэк с клиентов, но потом показать Велу. Первая секция вопросов работы. В чате много сообщений. Спасибо, что делитесь. Я думаю, мы, наверное, все не успеем. Буквально еще пару минуточек, может, одну-две и переключимся. Потом, если что, если останется время в конце, можно вернуться и посмотреть. Да, вот клиент приходит с просьбой доработать какой-то существующий продукт, и чаще всего реакция скептическая. А тут тоже можно показать, что... А как мы можем что-то доработать, если мы не понимаем, зачем оно работает? То есть мы, конечно, можем сделать то, что вы сказали, но это риск для заказчика, потому что он полностью полагается на свое мнение. Вы можете показать, что у вас есть экспертиза, что вы можете принести value не только реализовать задачу, но еще и зачелнчить ее. К сожалению, от заказчика к заказчику действительно разные истории. Кто-то с этим больше знаком, кто-то меньше знаком. Но, в частности, что получилось в моем случае и с кейсом онлайн-синема, в том, что во время разговора с кинотеатром они сказали, что да, как бы изначально мы хотели всего лишь дашборд, который показывает количество рекламы. Но зачем нам это надо? Потому что мы хотим... чтобы у нас сервис оставался бесплатным. То есть они на рекламе не только зарабатывают, они там покрывают свои расходы на инфраструктуру и все остальное. То есть таким образом мы узнали, что у клиента есть премиум клиенты, премиум юзеры, которые платят каждый месяц за онлайн кинотеатр, а есть фри юзеры, которые, в принципе, смотрят рекламу и таким образом генерируют value для клиента. Но в то же время, Они хотят держать сервис бесплатный, но в то же время они не хотят терять юзеров, вьюверов, то есть те, кто пришли смотреть кино. Из-за длинных прероллов, прероллы – реклама перед видео. То есть если там одна реклама показывается, две рекламы показываются, три рекламы показываются, естественно, нашему онлайн кинотеатру выгодно показывать миллион рекламы. до фильма, потому что больше выгоды, но, к сожалению или к счастью, как пользователь, так к счастью, так не работает, потому что начиная со второй, третьей рекламы, обычно юзеры отваливаются и идут искать другой кинотеатр, либо Netflix и так далее, любую другую подписку, где можно не заниматься. Просмотрим рекламу, где можно действительно потреблять контент, за которым ты пришел. То есть клиент раскрыл моменты того, что они хотят Держать сервис бесплатным и удержать юзеров. То есть мы уже говорим не только про количество рекламы, мы уже говорим, например, про соотношение, сколько рекламы было показано одному юзеру, с тем, отвалился он или нет. Или же, например, мы говорим, что сейчас ценно знать... длину каждой рекламы. То есть если реклама идет на 5 секунд, это одна история, если реклама идет 15 секунд, это другая история. И видеть эти данные для клиента будет очень важно. Помимо этого они сказали, что зачем им это надо, зачем рекламодателям это надо, потому что рекламодатели хотят доказательства, цифр, то есть они платят за рекламу. И что происходит? Если рекламодатель заказал 1 миллион показов в кинотеатре, и потом кинотеатр через месяц к нему приходит и говорит, мы миллион раз вас показали. Но тут возникает вопрос, а как мы можем это проверить? И любой кинотеатр, любой паблишер, издатель, у него есть система, которая это считает, и он может показать. Но тут такой момент, что... Источником этих знаний служит сам кинотеатр. И поэтому рекламодатель говорит, так, мы у вас миллион рекламы заказали, вы же нам посчитали, вы же нам сказали, что действительно миллион. А можно как-то более увесисто получить какое-то подтверждение этих цифр и расчетов. С какой-нибудь short party, либо с какой-нибудь сертифицированного провайдера, который занимается расчетами и так далее. Поэтому... Оказывается, что клиенту уже надо не просто эти цифры, ему надо эти цифры, потому что он хочет показывать их своим клиентам, получается, своим рекламодателям. И это уже немножко меняет историю, потому что если мы хотим показывать цифры, нужна специальная сертификация, то есть какое-то признание бренда в индустрии и так далее. И самое последнее интересное, что клиент раскрыл во время этого discovery question, что... Они не хотят испортить отношения с рекламодателями, потому что что происходит иногда, ну не иногда, к сожалению, происходит чаще, чем хотелось бы, реклама может показаться не в том контексте, либо не тем людям, и тогда это производит к потере репутации. Человек пришел в этот онлайн кинотеатр, хочет посмотреть фильм про автомобильную аварию. Какой-нибудь фильм, пункт назначения, что-нибудь в таком роде, где все разбиваются, где все ужасно, кровь и так далее. И перед этим фильмом, либо во время просмотра этого фильма, начинает показываться реклама условного BMW, Мерседеса, либо Volvo. Я не думаю, что Volvo, Mercedes и BMW будут сильно рады тому, что они показаны в контексте насилия, либо в контексте автомобильных аварий, потому что их как раз таки бренд про безопасность, про остальное. То же самое происходит с заказчиками, которые ориентируются на детскую или семейную аудиторию, когда они хотят прорекламировать условный Disneyland, либо парк какой-нибудь, либо семейный отпуск. Естественно, они не хотят быть в фильмах-ужастиках и показаны в таком environment. Это открыло для нас дополнительный момент, что этому клиенту важно не только считать, ему важно еще знать, в каком контексте он находится, и показать рекламодателям, что их реклама не была показана в плохом контексте. То есть им надо уже заниматься репутацией своего бренда. Бренд безопасности. То есть все эти вопросы помогли изначально требованию, что мы хотим дашборд углубить в понятие зачем, почему это вообще делается, зачем вы пришли к нам, почему именно наш продукт, почему именно наш сервис, что вам интересно, что неинтересно, какие у вас есть бизнес-проблемы и потребности. и предоставить решение хорошее. Но сегодня мы говорим про Assumption, поэтому, в принципе, тут можно посмотреть на вот этот первый Assumption, который... Assumption — это требование, которое пришло к нам, что мы хотим Dashboard, и увидеть, что тут есть несколько предположений, которые нам следует изучить. То есть первое предположение — это что AdCounts, количество показов рекламы само по себе ценное зачем-то она несет какую-то ценность также что все мы говорим про одно и то же от плейд например мы хотим смотреть сколько было реклама показано во время проигрывания фильма во время проигрывания До проигрывания, после проигрывания – это уже технический момент. Но что такое показанная реклама? Это тоже на самом деле интересный вопрос, потому что все могут понимать по-разному. Кто-то говорит, просто загрузили, кто-то говорит, загрузили, реклама должна быть показана юзеру. Кто-то говорит, он должен на нее кликнуть и так далее. Поэтому уже есть еще одно предположение. И финальное предположение, которое сюда можно засунуть, что наш Point of Contact. то есть человек, с кем мы общаемся из кинотеатра, он понимает бизнес рекламодателей и как рекламодатели оценивают этот онлайн кинотеатр. Потому что когда к нам пришел человек с онлайн кинотеатра, он в принципе больше был сосредоточен на том, чтобы интегрироваться с нашей системой, чтобы мы предоставили цифры, но он был меньше вовлечен в контекст именно всей бизнес-цепочки. Как все-таки рекламодатели это оценивают? Хоть и формально наш клиент онлайн кинотеатр, но его клиент это рекламодатель, поэтому стоит оценивать и тех клиентов, и тех, то есть финальных юзеров. Что сделал я? Я переформулировал этот весь набор ассампшенов и требований в более такое понятное для себя. И в целом мы договорились с кинотеатром, что это имеет больше смысла. Что если мы покажем им данные про рекламу, их адвертайзеры, их рекламодатели будут им больше доверять. Это, в принципе, покрывает большую часть того, что они хотели. Ну и на фоне этого потом была сформирована гипотеза. Ближе к концу сессии мы получимся вместе формулировать гипотезы и превращать ассампшен в них. Но гипотеза это уже что-то измеримое, что мы верим, мы считаем, мы предполагаем, что если мы покажем ad engagement, то есть сколько юзеров посмотрели, как долго смотрели, кто там промотал, кто кликнул, плюс демографию юзеров, с какой страны смотрели и так далее, плюс movie категория, то есть horror. Funny, Entertainment и так далее. Это все увеличит ретеншн адвортайзеров на 10%. То есть нашему онлайн кинотеатру будет легче удержать своих адвортайзеров, если будут все эти данные. Это, в принципе, уже можно хоть как-то протестировать и посмотреть, что наш продукт действительно приносит им выгоду. И они не просто платят за какие-то цифры, а они... увеличив retention на 10, на 5, на 8%, мы можем даже посчитать, в чем их прибыль от использования нашего продукта. Ну и нам это позволяет более уверенно подходить в работу с этим клиентом, потому что мы не просто полагаемся на то, что вот покажем цифры, а дальше клиент сам разберется. Мы действительно считаем, что наша ценность, наша цель – это улучшить их бизнес. То есть помочь им заработать. Если они зарабатывают, мы тоже зарабатываем win-win. В чем риск ассамшенов и всех этих предположений? В принципе, я вот кейсы в чате смотрю. Как раз таки в этом риск всех этих вопросов про solution space и всех предположений, которые мы не проверили, в том, что, во-первых, это ведет к потере времени. То есть мы предположили, что дашборд будет ценен, мы построили. Мы предположили, что только accounts matter, мы посчитали. И что происходит, что через месяц, через два клиент говорит, а знаете, у меня все мои адвартайзеры все равно от меня уходят, ретеншена как не было, так и нет, я не вижу смысла в вашем продукте. Но мы сделали то, что он хотел, мы сделали то, что мы умеем, но получилось, что не работает это для клиента. И, соответственно, он расстроен и теряет деньги. Плюс все эти ассумшены ведут к holds confidence, к тому, что мы все предполагаем, что это общеизвестный факт, мы все уверены в том, что это действительно ценно, важно, мы все это делаем. Или тот же разработчик, например, может принять на веру... ваши слова или интерпретацию jira ticket, интерпретацию любого тикета и начать его строить, начать его делать с уверенностью, что за него кто-то уже подумал о том, что это имеет смысл. Бизнес-аналитик либо project-менеджер может подписать проект точно так же с уверенностью того, что заказчик на самом деле понимает. А заказчик в свое время, либо там продуктовая компания, что происходит, что есть идея, есть бюджет. хотим инвестировать в определенный продукт, но мы уже думаем, что за нас маркетинг, либо sales, отдел уже все посчитал и знают, что действительно в этом есть выгода и в этом есть смысл. Может оказаться, что никто этого не сделал, вопрос просто был пропущен, но каждый сделал свою работу, а, как говорится, к успеху не пришли, потому что базовые вещи пропущены. И, соответственно, такие ассамшены очень тяжело. заметить, если они не проговариваются. Поэтому лучше лишний раз повторить банальный вопрос, зачем мы это делаем, почему мы это делаем, чтобы понять, а действительно ли мы понимаем и где-то это хотя бы прописано или нет. Потому что может потеряться время исполнения. Ну и, соответственно, это приводит к замедлению разработки, тестирования. Ассамшинов на самом деле очень много. В принципе, любое требование мы можем миллион ассамшинов сделать. У нас было предположение, что вы сегодня подключитесь к Zoom конференции. Было предположение, что Zoom сможет шарить экран. Предположение, что вы меня будете слышать и понимать. И предположение, что все получат то, что хотели от этой встречи. Какие-то предположения? окажутся верными, какие-то окажутся неверными, но в целом вряд ли мне стоило и нашему хосту сильно думать над предположениями в этом плане, потому что уже есть confidence того, что есть аудитория, есть люди, которым это интересно, плюс какие-то отзывы заранее получили, поэтому какие-то assumptions валидируются, какие-то нет, и сейчас я покажу, какие на примере вот этого онлайн кинотеатра. были типы assumptions, какие стоило вы лидерать, а какие нет. То есть как их найти, поднять и вычленить предположения из обычных требований, из обычных полетов мыслей, либо дискуссий с клиентами. То есть, например, у нас есть первый наш большой assumption, Advertiser Will Trust Cinema. То есть они будут доверять, Advertiser будут доверять онлайн кинотеатру, если увидят. Данные про рекламу. Deserability Assumption, тип Assumption, который говорит про то, надо ли это пользователям, конечным пользователям. Поэтому мы говорим здесь не про онлайн-кинотеатр, мы говорим про рекламодателей, а действительно ли они волнуются, действительно ли им важны вот эти данные про рекламу. Это первое предположение, которое мы делаем. Второе предположение, которое мы делаем на счет вебилити, как это коррелирует с бизнес-ценностью, насколько это помогает нам или нашему клиенту зарабатывать. И здесь у нас есть предположение, что действительно показ этих данных увеличит ревеню нашего онлайн кинотеатра. Визобилити, в принципе, самое относительно понятное, это на счет технического. исполнения, сможем ли мы действительно синтегрироваться с онлайн-кинотеатром. То есть для успеха нашего продукта у нас есть набор assumptions, что Advertiser это важно, что это увеличит прибыль кинотеатра и что кинотеатр сможет с нами интегрироваться. Usability Assumption, в принципе, тоже достаточно понятное по слову. Это про UI UX в том плане, что клиент... Конечный пользователь, тот, кто будет потреблять эти цифры, он поймет, что это такое, он знает, как с ними работать, он знает, как это оценивать и так далее. Ну, естественно, это зависит уже от UI, который будет предложен и так далее. Самый последний и интересный тип ассамшенов, который чаще всего забывают, к сожалению, но он в последнее время очень важен, это этические ассамшены. Это тип предположений, которые... могут принести нам большой вред, если окажутся ложными положениями. И здесь у нас в случае с онлайн-кинотеатром и нашим решением было предположение, что показ демографических данных, либо сбор демографических данных не нарушает никакой южеправиси. Что же делать дальше, когда у нас есть набор ассампшенов? Потому что вряд ли мы физически сможем все ассампшены проверить и про все заботиться. Точно так же, как я сказал, что у нас с хостом было много ассампшенов по поводу сессии. Я думаю, у вас есть много в вашей жизни ежедневной. Но если мы начнем проверять и беспокоиться про каждое предположение, которое мы делаем... Мы, в принципе, потратим все время только на то, чтобы проверять Assumption, проверять предположения и все время спрашивать, а действительно мы делаем то, что надо или нет. Поэтому в целях экономии времени есть такой метод, как приоритизация Assumption, в принципе, от самых важных для успеха, менее важных. По вертикали и по горизонтали, strong evidence, weak evidence, когда у нас мало доказательств, много доказательств, чтобы понять, какие assumptions мы считаем важными для того, чтобы их тестировать, какие мы считаем, что в принципе даже если мы ошиблись, ничего страшного не будет. То есть, например, первый assumption, advertiser care about raw data, это важно. На мой взгляд, это важно для успеха продукта, поэтому я в своем случае поместил это вверх, диаграммы, и слева, потому что на самом деле у нас есть очень много доказательств, что адвартайзеры действительно волнуются про эти данные, у них действительно очень много репортов на основе. количество рекламы, у них происходит оплата между рекламодателем и площадкой, которая показывает рекламу, именно на основе этих данных. Плюс это Industry Standard. Мы достаточно уверены в том, что Advertiser действительно care. Опять же, можете поспорить, если вы не знаете, например, домена, либо это новый тип проектов для вас, смело точно так же... Да, это важно, но weak evidence мы еще не знаем, например. Насчет второго. Насколько поможет это увеличить revenue? Тут вопрос. Когда я оценивал, я посчитал, что это менее важно, чем про адвортайзеров, потому что в целом, если это не увеличит доход кинотеатра через retention, то есть, например, Допустим, это неправда, и все равно как отваливались адвардайзеры, так они и будут отваливаться дальше, несмотря на то, что мы предоставим решение. Это плохо, но это на самом деле может не так важно, потому что кинотеатр, может быть, найдет новых рекламодателей с помощью наших цифр, которые мы посчитаем, с помощью наших данных. Поэтому тут чуть-чуть менее важно. И чуть-чуть меньше у нас доказательств, потому что здесь как раз-таки я на тот момент не был уверен, насколько это повлияет на наш продукт. И насколько это правда, что именно нужные цифры являются показателем того, что клиенты отваливаются. Следующий ассампшн технически про feasibility, что онлайн-синема может синтегрироваться с нами. Это очень важно для успеха продукта. Естественно, если онлайн-синема не может синтегрироваться, тут не о чем говорить, ничего не взлетит, и мы не сможем помочь нашему клиенту. Потому что на момент начала проекта, когда мы это обсуждали, у нас не было технического раунда с клиентом, и ни я, ни кто из компаний еще не знали. о том, смогут ли они с нами интегрироваться, есть ли у них необходимые SDK, или есть ли у них необходимые даже команды разработки. Может, у них есть команда разработки, только backlog на год, на полтора вперед забит. Поэтому пока что weak evidence. Возможно, после нескольких технических раундов с заказчиком мы сможем доказать обратно. Assumption по поводу usability. менее важен для проекта и для продукта, если окажется, что клиенты не понимают, как эти данные интерпретировать. Возможно, они все равно научатся через документацию, через какие-то гайды. То есть их придется поучить, придется больше потратить силы, времени на то, чтобы показать ценность этих данных. Но в целых ценность данных есть. Вик-эвиденс, потому что мы еще не общались с конечными пользователями, мы не знаем, насколько они смогут понимать эти данные, либо нет. И последнее, демографическое данное. В тот момент считалось важным. В целом, я бы мог сказать, что это менее важная задача, но так как по ходу общения с онлайн-кинотеатром... Эта тема поднималась несколько раз, плюс был очень сильный акцент на то, что Advertiser'ам нужны эти данные, что они хотят. Например, если мы возьмем бренд какой-нибудь, который рекламируется и производится только, например, продается только в США, то ему, естественно, не интересно, что у него были показы рекламы во Франции. Потому что все равно люди из Франции не могут купить этот товар. Поэтому, естественно, они хотят бренд американский, хочет показываться в Америке, бренд французский во Франции. Интернациональные бренды тоже зависят от типа продукта и рекламы. Для них это было важно, и это влияло на успех продукта. Big Evidence, потому что еще на тот момент я не имел возможности поговорить с legal командой, чтобы понять, насколько вообще сбор таких данных рискован и не рискован. Но идея в чем, что если окажется, что это условно незаконно, либо мы не имеем права, либо нам надо проходить кучу сертификаций для того, чтобы начать собирать эти данные, либо там user consent должен, это все сильно усложнит и проект станет крупным. Поэтому эти ассамшены очень рискованные. Собственно, когда мы их все замапили на таблицу, нам надо определить, с чем мы будем работать. И чаще всего мы работаем с прыжком веры. с правым верхним углом, то есть то, что самое важное, и то, про что мы меньше всего знаем. То есть мы меньше всего знаем про техническую сторону продукта, мы меньше всего знаем сейчас про Legal и User Privacy Chart, поэтому мы не можем просто так изменить важность этих вещей, они все равно остаются важными, даже когда мы узнаем, что мы технически можем синтегрироваться, но мы можем... собрать больше доказательств провести небольшой discovery исследование или research чтобы понять сможем ли мы с интегрироваться и чтобы понять не нарушаем ли мы каких-нибудь законов насчет правильности поэтому чаще всего после мэппинга то по сам шины и начинаем их проверять Проверка Assumption может быть разными способами. В принципе, это мы сейчас затрагивать не будем, но если коротко, Assumption можно проверить очень быстро, очень медленно. Это не должно занимать весь лайф-цикл продукта. Нам достаточно за несколько дней узнать хотя бы, провести один звонок с кинотеатром, с клиентом, спросить про техническую интеграцию. Понять просто на верхнем уровне, что да, это возможно. Возможно, мы не знаем всех деталей на данный момент, поэтому мы не ставим прям strong evidence где-то в серединку, но уже как минимум меньше беспокоимся про это. То же самое с демографической данными. Встретили с legal отделом, они проверили GDPR, проверили, где это решение будет применяться, и сразу выдали ответ. И после этого у нас достаточно доказательств, чтобы уже не беспокоиться об этих assumption. Но тогда другие ассамшены становятся более важными, и их можно тестировать, можно уже сказать, что это не повлияет на успех. То есть даже если окажется, что юзеры не понимают, что за цифры, рекламодатели не возвращаются, и еще что-то произошло, в целом все равно мы будем успешны с данным продуктом. Капитальная разница от Assumption, мы все время сегодня много про Assumption говорил, и гипотезы тем, что Assumption это такое натуральное, то, что у нас у всех есть, и то, что всегда происходит в любой дневной работе. То есть мы предполагаем, что никто после 6 часов вечера условно рабочих working hour не будет нам писать. Мы предполагаем, что... система будет работать ночью, что никаких инцидентов не произойдет, либо мы предполагаем, что человек, которому мы попросили написать письмо, напишет его. Ну и в целом много таких предположений. То есть это то, во что мы верим, оно может быть правдой, может быть неправдой, но в целом предположение может быть просто рискованное, не рискованное, но оно есть и есть. Гипотезы — то, с чем можно работать более плотно. Гипотезы — это уже сформулированное предположение, которое может быть на основе Assumption, и которое включает в себя несколько переменок. То есть если мы посмотрим на примеры, то пример предположения, кто-то пришел, говорит, давайте построим фичу X, давайте сделаем новую веселую кнопку, которая будет Magic Button. показывать какие-то полезные данные клиенту. Мы делаем предположение, что юзерам это будет интересно, полезно, и они какую-то выгоду в этом найдут. Но если мы говорим про гипотезу, которую чаще всего продакт-менеджер может взять в работу, это уже формулировка в стиле, что если мы добавим вот эту фичу X, волшебную кнопку, либо еще что-то, тогда условный юзер-энгейджмент повысится на 5%. Или же retention, или же conversion rate. То есть, например, если мы изменим дизайн нашего приложения, наши клиенты будут проводить на условно 50% больше времени в приложении. Или, например, если мы будем показывать... правильную рекламу, тогда у нас в два раза упадет процент отваливающихся клиентов во время показа рекламы. То есть, возможно, если человек интересуется условной рыбалкой, и ему показать про рыбалку, шанс меньше того, что он отвалится. Опять же, предположение, но сформулированное в виде гипотезы, которую можно запустить в работу, которую можно протестировать уже на основе данных полноценного АБ-теста. либо другими методами. В этом основная разница и, собственно, разница в глубине и в деталях, потому что, например, если ассамшены, то, что мы говорили изначально, как я сказал, это что-то быстрое, то есть мы предполагаем, что это будет интересно, что это будет выгодно, что это будет понятно, и мы также их валидируем очень быстро, в течение дня, 2-3-5 ассамшенов можно проверить, небольшой макап накидали. Картинку показали, клиент сказал, а, ну да, понятно, что это такое, все. А если мы говорим про гипотезу, гипотеза это более увесистая, то когда мы, например, хотим быть более уверенными, хотим действительно иметь какие-то доказательства того, что есть смысл инвестировать в эту фичу, есть смысл инвестировать в этот продукт дальше. То есть чаще всего это про итеративную разработку, что у нас уже есть продукт, мы хотим сделать какие-то глобальные изменения. И чтобы не тратить много денег на глобальные изменения, мы проверяем гипотезой, на что опирается продукт, когда выделяю гипотезу из примеров. Это очень хороший вопрос. По-хорошему продукты должны опираться на первый опыт. То есть, к сожалению, тут нет silver bullet какой-то, что посмотрели, и после этого у нас есть формула, что мы можем... Добавив фичу X, увеличить там engagement на 5. Но у нас есть опыт, мы знаем, как добавление прошлых фичей было. Если у нас построена система сбора метрик и поведения пользователя, мы можем запустить симуляцию, предположить, почему мы вообще строим, то есть на основе данных. Success rate, его гипотез, 50%, это уже очень-очень хороший продукт менеджер, который очень хорошо понимает бизнес-домен. Чаще всего гипотезы проваливаются, и это, в принципе, неплохо, потому что гипотеза, если она провалилась, ее можно перевернуть, тогда она будет успешна. То есть сначала делается гипотеза, что вот если мы уменьшим, например, количество шагов в регистрации, то клиенты будут лучше ее проходить. То есть тут чаще всего просто логично какое-то измышление, то есть на основе логики, предположений, а потом все зависит от того, есть ли у вас доступ к данным, либо нет. То есть, например, с онлайн-кинотеатрами у меня был доступ к данным, к нашим, и в принципе можно было посчитать, сколько адвардайзеров отваливается из-за того, что нет определенных данных. Потому что, например, когда Advertiser уходил от кинотеатра, он указывал причину, почему. И одна из причин была, что вы не предоставляете транспаренции, он задает понятных... Вы не предоставляете прозрачности на то, как вы считаете вот эти данные. Поэтому мы от вас уходим. Но опять же, это... Тоже предположение. Возможно, у этого адвардайзера было еще куча других причин, которые он не захотел называть. Но мы предполагаем на основе этих данных, что это правда и берем это за основу. Так что тут от случая к случаю, но чаще всего данные, опыт и доменные знания. То есть если мы знаем, что... У всех, ну там многие конкуренты уже запустили какую-то фичу. Скорее всего, в этом есть какой-то смысл. Поэтому тут уже начинаем предполагать на этом основе. И с гипотезами что происходит? Гипотезы часто эволюционируют. То есть, например, мы сказали, что добавив фичу X, engagement вырастет. Но что может произойти, что мы добавили фичу X и engagement упал? И как раз таки гипотеза полностью перевернулась. И тогда мы можем сказать, ага, фича X, она оказывается вредная. И из нее мы можем сделать вывод, что, например, мы добавили какую-то кнопку, которая, что может делать, меняет цвет интерфейса со светлого на темную, dark mode. Но мы думали, что это повысит, так сказать. хэппинес наших клиентов, что они будут больше времени проводить в системе, но мы увидели, что когда мы это добавили, клиенты стали чаще отваливаться. Поэтому тут что можно сделать, это небольшой ресерч с клиентами, понять, почему они стали отваливаться, что им не нравится и так далее. А во-вторых, из-за того, что мы по данным видим, что эта фича вредна, мы ее закрываем, либо наоборот, Мы полностью убираем из системы и делаем вывод о том, что как раз-таки наша одна тема, наша одна визуальная тема намного выгоднее и спокойнее для клиентов, что как раз-таки простой интерфейс их удовлетворяет полностью. И не надо переключаться на разные. Мы пришли к одному из завершающих слайдов с... Да, пожалуйста, Анжелика. Собственно, мы пришли к одному из завершающих слайдов, где можем попробовать вместе с вами превратить Assumption в гипотезы. Не все Assumption надо проверять, как мы уже смотрели. То есть если нам ценно просто провалидировать Assumption, мы его провалидировали и можем уже работать с этим. Если мы хотим все-таки капитальный продукт, например, вот в этих случаях, то есть, например, мы хотим поднять стоимость на наши услуги, внести новую версию, например, премиум-версию нашего продукта. Ну и мы предполагаем, что клиенты захотят платить больше. То есть это пока Assumption. Поэтому если у вас есть второе, например, упростить процесс онбординга, третье, кто-то приходит с идеей и говорит, а давайте... 24 на 7 предоставлять поддержку нашим клиентам. Их удовлетворенность, что клиенты будут довольны нашим продуктом из-за этого. И в нашем случае, что если мы будем показывать AdPlay Data, наши рекламодатели будут больше доверять. На самом деле может произойти такое, что наши данные покажут, что реклама показывается не в тех местах, и как раз-таки доверие упадет. Поэтому можно сформулировать из всех этих ассамшенов гипотезы, которые запустить в проверку. И, в принципе, если у нас есть минут 5, мы как раз можем сделать небольшую паузу и в чат написать варианты. И как вы думаете? Стоит сформулировать эти гипотезы, а я потом покажу. Правильный ответ. На самом деле правильных ответов нет, потому что как в чате было правильно, на чём основа, это основа просто на опыте и на каких-то данных. Кому-то надо бежать уже, вы можете в записи потом досмотреть, а кто ещё может остаться, то предлагаю попробовать получить этот навык прямо сейчас. Вот сверху есть шаблон. We believe if we then will know we are right if. Евгения просит ссылку на LinkedIn. Она была в анонсе, и она будет также в записи видео. И как раз на последнем слайде там все будет. На последнем слайде будет тоже супер. Аудитория пишет, просто расскажу, в чем как раз интерес. продукт менеджмент в продуктовой работе в том, что все эти assumptions как раз таки даже не в продукт работе. Какие ожидания, например, у меня от бизнес-аналитиков, с которыми я работаю, с контракторами или как авторс-компаниями, в том, что бизнес-аналитик может задать эти вопросы за меня. То есть я понимаю, это часть моей работы, но очень приятно, когда бизнес-аналитик пытается не просто перевести мои слова в команду, а в принципе быть действительно представителем заказчика на стороне аутсорс-компании. То есть это, да, действительно требует больших усилий изначально. То есть мы с нашим бизнес-аналитиком провели очень много времени. общаясь, споря, объясняя, в чем вообще ценность рекламы, как работает бизнес рекламный и так далее. Потому что для многих команд это темный лес, совсем все новое и непонятное. Особенно, в чем, наверное, основной недостаток, это особенность аутсорса, что, меняя проекты, меняется очень сильно бизнес-домен. И это не есть хорошо для накапливания какой-то бизнес-экспертизы, потому что если сегодня вы занимаетесь там медицинским оборудованием, завтра рекламы, а послезавтра машины продаете, ну как бы окей, часть пересекается, но, к сожалению, бизнес-ценность теряется, потому что приходится переключать фокус, и новые термины, новые виды заработка стоят. Вот то, что мы нашли, то, что я вижу сейчас очень ценно, когда у вас очень долго одна и та же команда, очень долго один и тот же бизнес-аналитик, который полностью погружен в проект, который полностью понимает ценность бизнес-структуры и вообще зачем наш продукт существует. И тем самым бизнес-аналитик, вот вначале позадавав эти все вопросы, вначале пытаясь понять, бизнес-домены, в итоге сейчас тоже читая и смотря те же самые курсы, которые мы смотрим как заказчики, то есть мы изучаем от тех, точно так же наши бизнес-аналитики изучают от тех. Это помогает мне расслабиться и больше доверять команде, потому что я знаю, что они сами знают, что делать в тот момент, когда заказчик там недоступен, либо занят другими вещами. Потому что что происходит с другими командами, когда у них заканчивается работа, начинается вечно, а что нам делать дальше? Как бы просто раздувать бэклог какими-то улучшениями неинтересно и не сильно хочется. А когда команда сама к тебе приходит и говорит, там, Кирилл, Максим, Артем, нам надо сделать вот это, и с точки зрения технической команда часто приходит, нам надо там обновить инфраструктуру, техдолг, вот это все знаете, что команды часто с этим приходят. Но команда может прийти с этим. А от бизнес-аналитика точно так же ожидается, что бизнес-аналитик придет и говорит, у вас тут плохой процесс, у вас тут что-то чуть-чуть недорабатываете в плане юзабилити, или давайте попробуем вот эту фичу сделать, давайте проведем вот такой небольшой эксперимент с вашими клиентами. И тогда становится, окей, этот человек понимает бизнес, ему можно доверить, ему можно... дать больше ответственности и получить больше выгоды в итоге. Но тут время, наверное, это самый главный фактор, чтобы установить доверительные отношения между заказчиком и исполнителем. Ну и в принципе, да. Поэтому если есть желание попробовать себя в роли заказчика, то вот такое упражнение было бы неплохо. Но я смотрю, пока ответов нет. Видимо. Задачка со звездочкой, но ничего. Мы можем, наверное, показать варианты, а потом попрактикуете еще, если надо будет. Но как минимум, опять же, это все с опытом приходит. И главное иметь шаблон, понимать, в чем ценность. Дальше будет понятно. Вот первый вопрос, например, про поднятие стоимости продукта. Мы можем сформулировать гипотезу, что если мы предложим премиум-версию, например, не просто премиум-версию, а уже говорим, что премиум-версию, которая будет на 20% дороже, чем текущую, то есть раньше было там условно 1000 долларов, сейчас 1200, тогда как минимум 15% наших клиентов заапгрейдятся в течение двух месяцев. То есть мы сделали гипотезу, которую можно идти к сеньор-менеджменту, можно идти к инвесторам. Можно самому попробовать реализовать и показать, что вот, мы верим в том, что так будет. Запускаем, проводим АБ-тест, либо проводим опрос среди клиентов, показываем, кто готов переключиться, кто нет, и можем уже сделать выводы на основе этого. Потому что очень важно выбрать правильное время, правильную аудиторию, на ком мы будем это тестировать, эту гипотезу. Что может произойти, что у вас хорошая идея, действительно, поднятие цены на 20%, все будет прекрасно, клиенты заапгрейдятся, но вы выбрали время для этой гипотезы летом, а большинство клиентов в вашем случае имеют годовой контракт и будут только в январе-феврале подписывать новое соглашение. И, собственно, с этой гипотезой, даже если вы докажете, что она... Имеет место, и она правильная. Скорее всего, никто не заонбордится, никто не переключится, и окажется, что идея правильная, а время неправильное. С упрощением анбординга тоже есть свои подмодные камни, но можно формулировать в таком виде, что, допустим, у нас во время анбординга есть 5 шагов регистрации, имя, фамилия, email и так далее. Если мы уменьшим количество шагов с 5 до 3, тогда мы... Предполагаем, что это уменьшит на 25% количество дроп клиентов, которые установили приложение, попользовались и сразу ушли. Могу рассказать примерно о своем опыте. Это было с регистрацией. Гипотеза, кстати, провалилась. Упрощение регистрации не сделало жизнь лучше. Почему? Потому что, опять же, тут есть свои плюсы и минусы. Потому что длинная регистрация оставляла только мотивированных клиентов, которые понимали, зачем они пришли в этот продукт и заполняли все формы и так далее. Когда регистрация была упрощена, мы получили очень много клиентов, которые успешно заполнили всю регистрационную форму. Три кнопки нажали, и они уже в системе. Но они стали, естественно, чаще отваливаться, потому что это не то, что они хотят. То есть, с одной стороны, у нас показатель упал. Именно по Drop of O. Но количество клиентов, которые остались в системе, выросло. То есть, несмотря на то, что гипотеза провалилась и действительно там rate стал уже не уменьшился на 25, а наоборот он вырос, оказалось, что больше клиентов все равно установили приложение, больше клиентов все равно зарегистрировались и больше клиентов пользуются приложением в итоге. Поэтому, несмотря на то, что гипотеза провалилась, Реализация была правильная. И тут уже вопрос качества гипотезы стоит, а правильно ли сформулировали, и что мы из этого можем понять? Мы можем понять, что на самом деле не drop-off rate важен, а важно количество клиентов, которые пользуются нашим приложением. То есть упростив регистрацию, мы увеличили количество клиентов в этом ценности, а не в том, что мы оставляем только мотивированных клиентов. С поддержкой на 24 на 7 тоже интересный момент, что мы можем сформулировать, если мы предложим Customer Support 24 на 7, тогда Satisfaction Score увеличится на 10%. Звучит логично, можно проверять, можно запускать в разработку. Но опять же, даже с гипотезой, с такой гипотезой надо очень критично подходить к этому, потому что что может оказаться? Что возможно параллельно нашему тесту, какая-то другая команда, либо там дебартмент, улучшили анбординг процесс, и теперь у нас клиентов будет в два раза больше. Например, они увеличили, какой-то новый рынок нашли. И таким образом у нас предоставление кастомер-поддержки 24 на 7 выльется в то, что у нас просто больше запросов, больше тикетов от новых. клиентов, которых мы до этого не ожидали. Из-за этого их удовлетворенность упадет, потому что раньше мы предоставляли поддержку, условно, только в рабочее время, зато мы были всегда доступны, квалифицированно предоставляли и так далее. Сейчас предоставляем вечером, но там, условно, отписки, которые подождите утро и так далее. Клиенты стали менее довольны, хорошо или плохо, это уже можно оценивать по другим показателям, но в целом со всеми гипотезами надо быть. аккуратными и даже самим себе не доверять. Ну и последняя гипотеза касательно нашего кинотеатра, что мы верим, что то, что показывают данные про SkipRate, очень увеличит retention. Ну и дальше можем это проверять. В принципе, техник для валидации гипотез много. В принципе, в целях экономии времени, наверное, не будем останавливаться на них, особо не планировал, но... Это можно потом почитать по названию техники. В принципе, это не секретное знание, это достаточно такой подход просто в индустрии. Но самое популярное, которое используется, это A-B-тест. Когда у нас есть данные, мы можем запустить, проверить на одной группе пользователей, на второй. Опросники, user journey, то, что мы можем быстренько нарисовать, показать клиентам и спросить. В принципе, то и то. что хотела сегодня рассказать, рассмотреть. Есть ли какие-то вопросы у аудитории? Собственно, вот и ссылка на Винкеры. Немножко подождем вопросы. Я сейчас добавлю ссылку в чат на наш опросник обратной связи. Пожалуйста, сохраните ссылку, потом можно заполнить. Это очень важно для нашего чаттера, собирать ваш фидбэк и улучшаться. Пока ждём вопросы. Кирилл, большое спасибо. Очень точно стало понятно разница между самшинами и гипотезами. Я думаю, что кто будет смотреть записи, сможет даже какие-то скриншоты себе полезные сделать, таблица, где ты сравнивал, что такое самшин, что такое гипотеза. Потому что иногда это употребляется, как будто это равнозначные понятия. На самом деле более грамотно будет мыслить гипотезами. Да, две вещи разные. На самом деле они действительно путаются, потому что очень похожи. Но стоит понимать, что Assumption — это то, что может быть правдой, может быть неправдой. Это просто любое предположение касательно нашего продукта. Любая верхнеуровневая идея. Рынок готов, не готов. Это предположение. Но если мы сформулируем, что... Если мы выйдем на этот рынок, то как минимум через месяц у нас будет 10 тысяч пользователей. Ну вот это уже гипотеза, которую мы строим и проверяем более основательно. Да, да, спасибо. Вопросы уже, я смотрю, есть. Есть. Извини, можешь читать вопрос и потом ответ. На всякий случай так попрошу, чтобы потом тоже в записи осталось все и вопрос-ответ. Первый вопрос. Что нужно опытному бизнес-аналитику, чтобы свечнуться в продукты? Первое. Я был неопытным, когда свечнулся в продукты, поэтому опытному, может, не сильно подскажу, но в целом, да, надо смотреть варианты, есть ли у вас возможность внутри вашей компании выполнять роль продукт-менеджера, есть ли вообще такая роль. Потому что что за чертой происходит, например, в аутсорсингах компаниях есть роль бизнес-аналитика, системного аналитика, project manager, но product manager роли просто нет, потому что, чтобы менеджить какой-то продукт, продукт должен быть чаще всего ваш, вашей компании. Поэтому тут такой момент. Но это уже конкретно по роли, должности и так далее. священца в продукт, чего обычно не хватает, не хватает каких-то бизнес-знаний. И это, наверное, сейчас основной момент, который, ну, в принципе, с тем, что EIA сейчас делает умение шаблоны или там анализировать большие объемы информации, выбирать summary, это все очень хорошо автоматизируется и уже не является таким челленджем, как было раньше, хотя все еще остается. А вот бизнес знаний продукт-менеджерам не хватает зачастую. То есть, например, когда мы говорим про доменные знания, например, от тех, либо медицинское оборудование, либо торговля машинами, либо трейдинг, что в принципе человек, который понимает, как на этом зарабатываются деньги, какую ценность и какое влияние продукт оказывает на клиентов, Такой человек ценен, потому что он может сказать, вот да, действительно, нам надо этот продукт, не надо продукт. Но что делает продукт-менеджер? Вот, наверное, кардинальная разница. В принципе, очень много обязанностей продукт-менеджера и бизнес-аналитика пересекаются. Наверное, самое важное, это самое важное отличие в том, что продукт-менеджер говорит, что делать сейчас, что делать завтра, а что вообще пока не делать. То есть вопрос приоритизации. Но чтобы хорошо приоритизировать и правильно приоритизировать именно бизнес-ценность, надо эту бизнес-ценность понимать. И вот как раз-таки отсутствие бизнес-знаний может быть таким фактором, который будет мешать переключиться. Но как только появится возможность, в принципе, если честно, из того, что я видел, бизнес-аналитики, опытные бизнес-аналитики достаточно легко переключаются в Adobe Management. То есть это очень схожая область, но понять бизнес-домен, не работая в этом домене, очень сложно и почти невозможно. Поэтому тут на основе текущих проектов, где вы работаете, то есть, например, если вы занимаетесь финтехом, оттехом, либо еще чем-то, вы можете как раз-таки попытаться приобрести эти бизнес-знания, задавая правильные вопросы, пытаясь заменить условно заказчика, то есть поставить себя на его место. подумать, а как, почему заказчик принял это решение, почему он пришел к вам с этой задачей, почему он считает, что это выгодно делать прямо сейчас, может быть, это выгодно завтра делать. Начинаю задавать такие вопросы и в целом пытаюсь самому ответить на них. Думаю, это должно помочь свечнуться. Следующий вопрос. Какие курсы? Порекомендуйте, чтобы перейти из BA в продукты. Хороший вопрос, который, если честно, я обычно очень вредный человек в этом плане, когда меня спрашивают, про какие курсы, я никакие не порекомендую, потому что курсы, чаще всего курсы, которые находятся онлайн, это курсы высокого уровня, то есть вам сделают overview product management, в принципе, это неплохо, и для начала это хорошо, но... Проблема в следующем в том, что такое overview поможет на начальном этапе узнать, что такое product management. Например, есть очень хорошие книги тоже Тереза Торос, Continued Discovery Habits. В принципе, могу и ссылку кинуть на Amazon, она продается, которая рассказывает, что такое product discovery, что такое product mindset, вообще в чем заключается работа. Очень хорошая книга, четко все по полочкам расписывает. Но она не поможет вам перейти. Это книга, которая вам расскажет про такую работу, как Product Management. Но чтобы перейти в Product Management, курсов будет мало, придется понимать бизнес-знания. В принципе, если вы нацелены в Product Management и нашли какую-то компанию, куда хотите, то есть, например, хотите GameDev заниматься. Тогда выгодно будет посмотреть курсы про геймдев, про индустрию игровую. Если от тех, тогда выгодно будет посмотреть курсы про бизнес от тех, как рекламодатели зарабатывают, как паблишеры зарабатывают. Если это медицинское оборудование, тогда будет выгодно посмотреть курсы врачебные, как медицинское оборудование используется. как его там доставляют, перевозят и так далее. То есть я бы советовал курсы, не направленные именно на продукт менеджмент, а курсы, направленные на бизнес. И когда вот будет бизнес-доменное знание, и когда вы придете на собеседование и вам скажут, что ретеншин наших адвартайзеров упал, у вас не будет... Сюрпризы вы понимаете, что такое ретеншин, вы понимаете, что такое адвертайзеры, вы понимаете, в чем состоит взаимоотношение между, например, рекламодателем и паблишером, и как они между собой общаются. Ну, в такой момент, есть фундаментальные книги по продукт-менеджменту, но в целом бизнес-знание это самое ценное, что может быть. Сейчас. И как только Product Manager показывает бизнес-знание, то есть, в принципе, на наших интервью, когда мы проводим, если Product Manager знает домен, то есть знает тот же от тех, это не просто плюс, это как бы основной решающий фактор, потому что техникам формулирования гипотез можно, в принципе, научиться. А доменные знания, к сожалению, очень медленно нарабатываются. И если человек уже пришел с ними, это, конечно, выгодно. Екатерина пишет спасибо. Спасибо всем, кто задал вопросы, комментировал. Спасибо, что пришли. Еще минутку подождем. Я еще, может быть, пять копеек от себя хотела бы добавить. Такого немножко практического, кто сейчас из бизнес-аналитика ищет вакансии и продакт-менеджера смотрит, то иногда бывает, я открываю вакансию продакт-менеджера в Европе и вижу, что... Все навыки как у бизнес-аналитика, вот как Кирилл уже упомянул. И вы, в принципе, если видите, что эта компания такая продуктовая, они могут не понять, кто такой бизнес-аналитик. Вы можете в резюме... как минимум, в LinkedIn оставить как есть, а в резюме написать Product Manager или Product Owner. Да, конечно, ваш тайтл в текущей компании был бизнес-аналитик, но просто чтобы вот этот прескрин себе не сбивать, у вас все навыки есть, можно сделать так. У меня так знакомые проходили интервью, меняя свой тайтл с бизнес-аналитика на Product Owner в резюме, потому что навыки были, просто чтобы не сбивать работодателя своим... названием «бизнес-аналитик». Это, кстати, хорошее замечание, потому что, когда я здесь работал в стартапе, в целом на европейском рынке, бизнес-аналитик — это чуть-чуть другое понимание, чем в аутсорсе, чем в наших бывших реалиях. Получается, что когда я говорил людям, что я работал бизнес-аналитиком, у них всегда было мнение, что я где-то там между SEO и CFO сидел и оптимизировал им бизнес-процессы на уровне топ-менеджмента. Хотя на самом деле, если сказать систем-аналитик, уже проще понимают, что это такое. Но бизнес-аналитик действительно немножечко может... Уводить в сторону. Но формально бизнес-аналитики, которые были в аутсорсии, которыми я был, 99% это technical product manager. Можно смело писать technical product manager. Если вы уже меньше technical и больше действительно поработали с разными бизнесами, product manager ставить можно смело. Да, да. И еще я замечала, что бывает то, там, работа с бэклогом, выяснение требований и так далее, все это очень похоже. Например, есть что-то, допустим, продуктовая стратегия. Это то, чем обычно в аутсорсе бизнес-эклэтик не занимался. И вот на эту тему, как мои знакомые поступали, проходили даже на LinkedIn, есть хорошие курсы на эту тему, или просто в YouTube смотрели какую-то информацию. открывали какие-то шаблоны продуктовой стратегии, смотрели, что там есть, понимали, что, может быть, это где-то там vision and scope или что-то еще. Хотя бы с теоретическими знаниями уже приходили. То есть бывает, что вакансии, в принципе, можно увидеть, чего не хватает. И эту теорию, знаете, не так глобально учиться-учиться и потом только смотреть вакансии, а идти вот от вакансии, что там нужно подкачать, точечно это делать и уже пробовать. Потому что я согласна с Кириллом, те курсы, которые я проходила по проект-менеджменту, были high-level, очень так описывающие, просто типичные какие-то штуки, а не скиллы, с которыми в идеале прийти на собеседование. Да, потому что даже сегодня показал вам варианты формулировать гипотезы. И в принципе можно прийти на собеседование, сказать, что я умею формулировать гипотезы, но первый же вопрос подсветит опыт, например. А почему 20%, а не 15%? А что если в итоге у нас меньше клиентов заапградилось? И вот то, что мы немножко рассуждали на тему, что может время неправильное подобрали, может юзеров не тех тестировали. Вот эти уже ответы действительно ждут от продукт-менеджера, чтобы он действительно... Потому что тогда видно, что вы с этими гипотезами не просто умеете формулировать и почитали курс, вы с ними работали, вы понимаете, что произойдет, если они провалятся. В чем прелесть сейчас всяких чатов GPT и остальных генератив AI? В том, что эти гипотезы можно туда закинуть и можно спросить, а что мне как продукт-менеджеру делать, если гипотеза провалилась или не провалилась? Сформулируй мне, пожалуйста, несколько челленджей, каких-то ситуаций вот этих гипотез, я попробую там. придумать свое решение скажет что он упал на пять процентов то изменилось что вы будете делать таким образом можно тренироваться и когда вот не просто вот к нам приходит тоже на собеседование не просто быть я умею писать в иблиф ив на то же самое что айвон ты был самсинг соузет и тому подобное но как бы Мы все это умеем писать. Вопрос понимает ли человек, что он пишет, и может ли он в случае, если это все пойдет не совсем по плану, сориентироваться. Практика. Да. Хорошо. Я думаю, что все вопросы отвечены. Мы можем завершать. У нас есть участники, кто все послушал. Спасибо вам за терпение, что остались до конца. Всем хорошего вечера. Кирилл, еще раз огромное спасибо. Спасибо. Когда запись будет готова, выложим в наши соцсети, что запись уже можно смотреть на YouTube, если захотите пересмотреть. Все, всем хорошего вечера. До свидания.

В основе выступления лежит как личный опыт спикера Kiryl Horhulev, так и подход Continuous Discovery, разработанный Teresa Torres.

Во время просмотра вы:
1️⃣ Узнаете, как продакт-менеджеры определяют и приоретезирует предположения (assumptions) на этапе product discovery.
2️⃣ Попрактикуетесь в формулировке гипотез, которые можно тестировать и подтверждать.
3️⃣ Изучите инструменты и методы, вдохновленные подходом Терезы Торрес.
4️⃣ Узнаете реальные B2B-кейсы для применения этих навыков на практике.
5️⃣ Поймете, как техники Continuous Discovery могут дополнить работу бизнес-аналитика.

Спикер - Kiryl Horhulev / https://www.linkedin.com/in/kiryl-horhulev-ba07a650/
Хост - Наталья Дедяева   / https://www.linkedin.com/in/ndedyaeva/

Для углубления в тему прочтите статью "Assumption Testing: Everything You Need to Know to Get Started" by Teresa Torres: 
https://www.producttalk.org/2023/10/assumption-testing/?srsltid=AfmBOopv2dTjGnPaWlSweFnwyTm2eE47zM59GvMx6GgGHCcCG6m2gJ1n