Руслан Хуснетдинов — Продуктовые навыки для технических специалистов

Угу. Всё, Руслан, передаю тебе слово. Микрофон. А, Руслан, у тебя микрофон?

>> Сейчас, простите, я этот справлюсь. Извините, пожать микрофон. Ага.

>> Да, я тут пытаюсь разными кнопками справиться с зумом и с как бы с кийноутом. Так, вот так попробую. Ладно, давайте так начнём. Аа, всем привет. Меня зовут Руслан. А я сегодня расскажу про продуктовые навыки для технических специалистов. А для начала обо мне, как бы я уже 10 лет в IT. Э сейчас я являюсь менеджером продукта сервисов ценообразования в Яндекс-Лвке. До этого работал в Яндекспоиске Уч.ру. Вот. А перешёл из фнтент разработчиков продукты, отучился в Яндекспрактикумеш Goact. Вот. И также я менторю разных IT-специалистов и веду Telegram-канал Technopкт. А здесь есть QR-код, можно перейти и посмотреть. Вот. А по забавно стечения обстоятельств до этого год назад я читал симметричный доклад про технические навыки для продуктов. Там рассказывал про то, а что я считаю важным как бы в разработке, чем должны обладать продукты. Вот, советую тоже посмотреть. Можно найти по названию как бы на Ютубе. Вот.

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

Итак, про предметную область. Здесь я хочу поговорить и определить три термина, которые связаны с продуктом. Собственно, первое - это продукт. Есть много разных определений, но мне ближе всего то, где определение через ценность. Собственно, продукт - это результат труда, который представляет ценность для потребителей бизнеса. Вот. И это как бы всё. Ну, то есть мы часто с вами взаимодействуем с продуктами. То есть это мог быть продукт питания. и как бы какие-то услуги и какие-то цифровые продукты как бы или финансовые, всё, что угодно.

А, собственно, кто такой менеджер продукта? Как бы есть в IT какое-то представление, общепризнанно какоя-то картинка, что менеджер продукта находится на стыке трёх областей. Это, собственно, пользователи, команда разработки и бизнес. И вот он является таким медиатором, переводчиком с одного языка на другой и адвокатом, аэ, как бы той или иной страны защищает их интересы и потребности. А-а, но как бы мне бы хотелось перейти к истокам, собственно, откуда появлялась эта профессия. Есть такой человек, как Нил Маклрой. Он его называют продавцом мыла. Он прошёл, пришёл, собственно, продавцом мыла в компанию Pro Gamble и стал её её SEO, а генеральным директором. И вот он придумал концепцию ещё в 1931 году, который назвал Брендмен. Концепция вся расписана на там буквально трёх листочках. Вот они перед вами. Вся идея ключевая была в том, что как бы появляется профессия какая-то роль в компании, которая собирает вокруг как бы людей и всю работу вокруг определённого бренда или продукта. А-а, как бы и вот несколько выжимок, которые переведены на современный язык. Как бы вот первый тезис - это что важно в этой роли- это общаться с клиентами и выявлять их проблемы. Второе - это разработь продукт, который решает какую-то из этих проблем. Третье, создать стратегию канала сбыта рекламныматериала для продажи продукта. И четвёртое важное, а-а, как бы отслеживать правильные метрики и совершенствовать на основе их, а, продукт, а, и повышать его прибыльность. Вот это принципы, которые были заложены в основе этой профессии. Потом перети продукт-менеджменту. Собственно, Нил дальше он был знаком с многими людьми в тех годах. И, собственно, он эту концепцию привёл в цифровой мир через компанию Hit Паckрт. Были вот такие ребята Билл и Дэвид, которые организовали эту компанию и там продвигали вот эту вот роль и этот подход, который потом в уже как-то выкристализовался в продуктовое мышление.

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

А из-за этого родилась какая-то продуктовая команда. То есть, ну, команды и так были в прошлом, но вот продукто команда, как по моему мнению, кто давт и как бы чем она отличается от обычной. Вот. Ну, есть, да, появилась какая-то профессия менеджер продукта. А потом были какие-то аналитики, которые работали с данными, что-то смотрели, считали эксельки, и потом из них родился продуктовый аналитик, который уже думал не просто о данных, не просто о бизнесе, как бы, а думал о продукте и о пользователе. В у дизайна был прохожий путь. То есть на заре там какого-то интернета был как бы графический дизайнер, который рисовал кнопки. Потом появился UXUI дизайнер, который уже начал думать о пользовательском опыте боевого поведения. Вот. Ну и а после этого всего как трансформировалась продуктового дизайнера, который, собственно, думает уже о продукте и ещё как бы на стыке с аналитикой как бы и разработкой. Вот разработчиков в моём представлении тоже был похожий путь. То есть раньше, когда были какие-то пригородные задачи, решались какие-то вычисления, расчёты, строились программы, как бы ИВМ ещё не были так распространены, и для широкого потребителя это не было какой-то, аэ, как бы инструментом, который каждый день им пользуется. Ну вот были программисты, которые писали программы, ээ, как бы какие-то скрипты, решали задачи. Вот. Потом появились уже как бы, когда компьютер массово распространился, появились разработчики, которые, собственно, начали разрабатывать продукты цифровые для как бы пользователей. Вот. Ну и сейчас идёт тенденция к тому, что появляется продуктовый разработчик, который наравне с другими продуктовыми специальностями продуктовой команде думает о продукте и спорит с продуктами и с другими, защищает какие-то свои идеи, своё видение продукта, как бы. А, а если есть какая-то неопределённость, он может сам принять какие-то решения на основе там данных и либо допущений, либо какой-то веры. Вот. Ну и тестировщики у них тоже инженеры, у них была похожая история. То есть сначала это был какой-то тестировщик, который что-то руками проверял, тестировал, у него были какие-то сценарии. Потом они начали отвечать уже за качество всего продукта, а не просто как бы передавать, а двигать таски в в другие статусы. Вот. Ну и после того, как они начали отвечать за качество, они начали уже больше влиять на продукт. И появилась профессия продуктового тестировщика. Они на самых ранних этапах, но вот в моём опыте у нас есть встречи Тримига, где собирается продукт, разработка и тестирование. И мы обсуждаем в начале там разработки какого-то проекта или фичи какие-то нюансы, какие-то сценарии пользовательские. Вот. Ну и есть ещё подход, э, как бы, где вначале садится продукт и тестировщик, и они прописывают какие-то пользоские сценарии, из которых, э, потом уже вырастают тестовые сценарии для тестирования. Вот это в моём видении продува команда. Иногда она расширяется, там ещё есть ещё продукто маркетологи, как бы есть другие специальности, как бы смежные из бизнеса. Вот. Но это основной костяк.

Вот зачем всё это я рассказываю? Аэ, у меня есть несколько аргументов. Ну, то есть, во-первых, то, что я рассказываю, я в это верю. Это, собственно, мой путь, моя стратегия, которой я двигаюсь. Вот. Но давайте по порядку. Вообще мне снова хотелось бы пройтись в прошлое, рассказать про несколько личностей. Первый из них - это Алан Кей. Мало кто знает вот такого вот дядечку, как бы он там тоже в семидесятых годах был инженером, работал в компании XКС. И он был один из как бы инженеров, который придумал первый, а, персональный компьютер, который вошёл в массовое производство и стал доступен широкой аудитории. И как бы и по сути второй персональный компьютер, который вообще в принципе существовал. первый как бы не вышел на широкую аудиторию, а он придумал первый графический интерфейс. Вот у как бы это у компьютера XX был вот такой вот графический интерфейс. Здесь есть окна, как видите, всякие наши, а, файлы, директории, иконки. Вот это уже всё тогда было. А, и он также придумал идею, э, планшета, как бы, когда ещё даже как бы, э, тогда уже был Apple. как бы и они как-то Стив Джобс приходил к Серокс и общался с этими ребятами, а потом у Apple появился тоже компьютер персональный. Вот про это есть история в интернете, рекомендую почитать. Очень интересные истории. Аа как бы вот это пример инженера, программиста, который придумывал продукты, которые в том числе повлияли на нас и на наше будущее. Как мы вообще сейчас взаимодействуем с миром?

Вот второй человек, более молодой, но не менее вдохновляющий пример, это Арен Шварц. А в 13 лет он входил в, я думаю, известную вам, а организацию, которая называется В3Ц. Э как бы он состоял в рабочей группе, которая разработала, э, как бы первую спецификацию РСС. То есть раньше была такая технология, сейчас она уже, считаю, отмерла. Вот. Но я думаю, многие из вас знакомы с ней. Вот также он придумал э лицензию Creative Commonss для того, чтобы в интернете люди могли спокойно использовать чужие труды, как бы, в том числе в коммерческих целей. Вот. А и он был один из сооснователей компании Redit, а, первый такой как бы одной из первых социальных сетей, которые любой человек мог опубликовать какую-то информацию, поделиться и получить какие-то реакции. Вот он был, собственно, тоже программистом, э, активистом, математиком, который вот, э, придумывал, продвигал разные продукты в нашу жизнь.

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

А следующая тема, которую я хотел аргумент, которую я хотел озвучить - это три уровня понимания задачи, как я их вижу. Первый уровень бизнесовый, это как бы уровень зачем, собственно, вот как бы зачем нам там делать какой-то сервис, какой-то сайт, какое-то приложение, а, не знаю, делать какой-то маркетплейс, который продаёт товары. Вот как бы мы должны ответить себе на вопрос, прежде чем начать что-то делать. И когда мы продолжаем на этот вопрос, зачем? А второй уровень продуктовый, как бы, это, собственно, что, то есть это как бы мы делаем сайт, это мы делаем приложение или мы на каких-то эксельках или там по телефону обзваниваем людей как бы и предлагаем им наши услуги, как бы, собственно, а в чём, как бы, наше преимущество, что из себя представляет продукт, как он решает задачи пользователей, вот, и как он, зачем он нужен бизнесу? И третий уровень технический, как, а, собственно, как реализовать это всё, с помощью каких технологий, какие решения, как это будет точно всё храниться, как взаимодействовать, по каким алгоритмам, как бы уже более детально и глубоко. Вот. Аа как бы здесь основная идея в том, что на каждом из этих уровней, э, у тебя как бы должен быть ответ на вопрос уровня выше. То есть если ты что-то делаешь на техническом уровне, ты знаешь, как ты должен понимать, а что ты делаешь, как бы, и должен, по-хорошему понимать, зачем, как бы. А на продуктовом уровне ты тебе не обязательно знать, как, как бы, но ты должен понимать, зачем ты это делаешь. что и зачем. Вот. Ну и бизнесу уже там не так важно, что как бы делается конкретно, там важно зачем.

У компании Facebook, которая принадлежит мете, признанная в России экстремистская организация изпрещена. Есть похожий фреймворк, который мне очень понравился. Там есть в конце будет рекомендации видео, там более наглядный пример про этот фреймворк рассказывается, но я его опишу, как я понимаю. Вот он называется identify execute. Тут тоже есть три уровня, они похожи. Первый уровень - это глубокое изучение пользователя продукта и рынка. А второй уровень identify, генерация решений, каких-то идей, которые потом оценивается и приоритизируется. Ну и третий уровень execute - это, собственно, разработка этого решения. И тут основная идея этого фреймворка в том, что как бы каждый из этих уровней имеет свою цену ошибки. Если ты ошибся ещё в самом начале на уровне, на самом высоком уровне Understand и начал делать что-то, что вообще в принципе как бы не нужно пользователям, как бы не там, э, не пользуется каким-то спросом, как бы, то мы можем потратить там годы разработки каких-то исследований, тестов и в итоге потом как бы закрыть компанию и выкинуть это, э, как бы или положить куда-то в шкаф. Вот. А на уровне identifй как бы у тебя уже как бы стоимость ошибки чуть ниже, но тоже достаточно высокая. Там ты можешь потратить какой-то квартал и придумывать какое-то решение, которое как бы решает проблему, важную проблему, но на самом деле она решает не так, как нужно пользователю. Аэ, он заинтересуется, но как бы ему будет неудобно. Вот. И третий уровень, собственно, разработка. Здесь стоимость ошибки, ну, зависит от, э, всё-таки от уровня принятия решений. То есть, если это разработка какой-то фичи, то речь идёт там о нескольких неделях, э, том, что мы можем что-то ошибиться, быстро найти баги, поправить их, как бы переделать на какое-то другое решение, типа, о'кей, если это какие-то архитектурные решения, то там это уже как бы другая область. Там тоже стоимость ошибки высокая.

А ещё важная тема для меня, собственно, вот она больше про мой опыт, про карьерный трек технического специалиста. Аа как бы каждый из нас когда-то, ну, большинство приходит в какую-то компанию, свою первую работу, и они приходят каким-нибудь стажёром. Ну, лично я так приходил. Потом стажёр вырастает в младшего специалиста, начинают брать какие-то задачи на себя, уже появляется какая-то самостоятельность, потом они вырастают в медла, как бы, и потом выгорают.Бо шучу, не выгорают, у них появляется выбор. По крайней мере, у меня такой выбор появился. А они могут продолжить развиваться в экспертную ветку, становиться, повышать свою экспертизу, становиться сеньором, как бы, и дорасти там до принципа, либо, э, они могут пойти в менеджерскую ветку управленческую, э, могут стать лидом, начать управлять людьми, э, брать больше на себя ответственности, нанимать людей, управлять какими-то рисками, а-э, как бы отвечать за рост. людей, за удержание их компании, как бы, и потом стать уже выше на уровень какого-то там руководителя службы и так дорасти до сети. Вот. И здесь на каждом из этих уровней а всё больше требуется знания и понимания продукта и бизнеса. То есть CTO он общается напрямую с сил-левелом, со всеми, и с финансами, и с SEO, как бы, и с там с маркетингом, и там с с аналитиками, как бы, и с продуктом. Он должен понимать, как работает бизнес и как его отдел технически решает э как бы потребности бизнеса. Вот. Но есть и третья ветка, которой пошёл я. Собственно, можно перейти в продукты либо там в технические продукт-менеджеры. Сейчас это набирает обороты. аа становится популярно. Уже все компании большие какие-то, которые обладают большими ресурсами, поняли, что во внутренних технических сложных продуктах тоже важен продуктовый подход, и они учат либо нанимают технических продукт-менеджеров. Вот. Аэ можно стать лидом продукт-менеджеров, тоже начать нанимать людей, вот дорасти как бы до си- лелевела, стать CPO какого-то там домина и либо направления, либо всей компании. Вот. Но здесь также можно, э, пойти, сделать ход конём и вернуться и стать отсюда же сети, потому что у вас уже будет знания о том, как бы как, э, работать технологии, и будет какая-то экспертиза, и вы уже обладаете менеджерскими навыками и очень хорошо понимаете продукты, бизнес. Вот.

Ну и здесь сейчас я сделаю глоток воды. Ну и здесь, э, как бы также хочется поговорить про будущее. То есть меня лично волнует эта тема и всех у всех на слуку это как бы мир очень быстро меняется. Мы куда-то идём, в том числе благодаря нам. А, и тут, если раньше вот в том докладе, который я упоминал, я там приводил примеры вот тишеп специалистах, как бы, зачем нужны знания там в других областях. Вот концепция заключается в том, что а тешеспециалисты сейчас становятся востребованными, а и ты должен обладать какими-нибудь минимальными знаниями в других областях, смежных доменах и какой-то вот веткой, а вертикальной линии. Это как бы глубокая экспертиза в твоей, собственно, а области, как бы. А как бы горизонтальная линия помогает тебе взаимодействовать лучше с командой и находить синергию. Но как бы мир быстро меняется. И теперь начинают все говорить про специалистов. Это уже такие мультипотенциалы специалистов, которые обладают экспертизой не в одной как бы области, а в нескольких, как бы. И это, в том числе, становится возможным благодаря технологиям, а, извините, которые сейчас на слуху. А, собственно, AI coding Sprene Shipment, всё вот это вот как бы очень как бы меняет мир, меняет наши работы и взаимодействие и сейчас позволяет там как бы набраться экспертизы либо восполнить её через ээ как бы искусственный интеллект, через каких-то агентов. Вот. и помогает, э, как бы становиться такими специалистами и решать уже брать на себя больше ответственности и и решать более сложные кросс доменные задачи. Вот.

И, ну, и также как бы у нас есть история какая-то развития технологического прогресса. Вот есть мы сейчас находимся в четвёртой промышленной революции. До этого там в конце XV века произошёл какой-то рывоок, люди придумали механизмы правовые двигатели. Вот это дало какой-то вот первый уровень автоматизации. Потом уже в конце X века появились заводы, фабрики, массовое производство какая-то, появилось электричество, электрификация. Вот. А появилось всё больше автоматизации. Вот, например, исчезли такие профессии, как а фонарщики, которые каждый там вечер ездили по дорогам и зажигали свечи. Теперь это делают как бы электричество всё автоматически. Вот. Ну и где-то вот как раз в семидесятых годах появились первые, компьютеры, канетизация, электроника, микрочипы. И это позволило, а, программировать какие-то действия и автоматизировать вычисления, в том числе, а, как бы в ракетостроении. А это позволило ускорить как бы и делать более сложные математические расчёты благодаря программированию ЕВМ. И тогда исчезли, а, точнее, они переквалифицировались целые профессии, которые занимались там математическими расчётами. Вот. А теперь они стали, как бы целый отдел заменила одна машина, один человек. Вот. Ну и сегодня мы находимся, а в эпоху интернета, интернет-вещей и циферовизации физического мира. А всё больше автоматизации в наш мир приходит. Вот мы там можем за 15 минут получить какие-то продукты, просто нажав в приложение кнопочки. Вот нам приедет специальный человек и доставит их. о будущем, возможно, там это уже будет не человек. Вот. И здесь, ээ, как бы искусственный интеллект, в том числе, ээ, решает более сложные задачи, которые раньше, э, не представлялось возможным автоматизировать уже более творческие задачи, как бы, вот, и это всё подходит тоже к нам, как бы, к IT-профессиям, и мы в том числе это двигаем. Вот.

Аэ, ну и чтобы закрепить вот предыдущую какую-то мотивацию в том, что продуктовые навыки всё-таки нужны, и мы постепенно превращаемся в каких-то вот мини-предпринимателей. Аэ есть конференция Prodctц, которая регулярно проводит опросы и исследования среди продуктов в моей отрасли. Вот за 2025 год они просили 1200 человек и спросили как бы что будет с продум мышлением как навыком в 2027 году. И вот 500 человек ответило, что это превратится в метанавык, который будет полезен любому общатиспециалисту. А как бы четверть людей сказала, что он вообще будет обязательным навыком для всех руководителей и этих лидов, и дизайнеров, и аналитиков, и так далее. Как бы, ну, собственно, я эту идею поддерживаю и пытался донести её в предыдущих слайдах. Вот сейчас я выпью воды про продуктовые навыки.

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

А первое, понимание пользователя. Вообще хорошо бы понимать, если бы делать какое-то приложение, продукт, как бы, кто наш пользователь. Есть разные методы. Вот есть один из там старых методов, метод перперсон. А я не буду сейчас подробно рассказывать про них, просто в интернете посмотрите, а что из себя это представляет. Но он как раз помогает ответить на вопрос, кто наш пользователь, какие там бывают типы пользователей, как они выглядят, какие задачи у них. В общем, и второй важный вопрос, какие задачи у этого пользователя? Есть такая методология jobs to be done. Основная мысль её в том, что наш пользователь нанимает наш продукт на то, чтобы решить какую-то задачу. То есть, если мы делаем приложение по доставке еды, то наш пользователь нанимает нас на задачу как бы поесть. Как бы раньше бы ему пришлось самому её выполнять, сходить в магазин или в ресторан или приготовить еду. Теперь он может заказать еду, как бы мы выполним для неё эту задачу. А важно понимать, как, собственно, пользователь использует наш продукт. Для этого проводятся различные исследования. Вот. А, ну, и, собственно, все методы на этом слайде, они тоже в себе как бы содержат ответы на эти все вопросы просто в разном фреймворке, разные фокусы на разные вопросы. Вот. И какие боли у пользователя какие потребности есть CGM есть OSM аа customer journey map и User Story Map - это два инструмента они очень похожи, но немного про разные. А Customer Jor Map - это скорее про путь э нашего покупателя, который может происходить ещё за рамками нашего какого-то приложения. А, например, как бы нам показывали CGM, огромнейший CGM, компания AVIASALES, где там прописано вообще каждый этап от там поиска билетов до а как бы прибытия в аэропорт, посадки в самолёт, как бы и там получение багажа и как бы дальнейшего э пути там до места назначения. Вот они это всё прописывают, и они на каждом шаге пытаются какую-то свой сервис и услугу как бы продать. Не только через сайт, где там заказываются билеты и не только там в самолёте. Вот. А USM - это больше про а уже пользователей приложения. То есть там описывается, собственно, как в самом приложении, какие у пользователи есть, э, истории. То есть они скорее звучат так. То есть там разбивается на эпике и мелкие стори. А-э, где вот вы заходите на какое-то, э, приложение в какое-то, видите каталог, и там есть поиск. И вот я, как пользователь хочу в поиске видеть фильтры для того, чтобы лучше и точно находить аэ то, что я ищу. Вот. И подобное как бы нам помогает лучше понимать задачи и боли на каждом шаге использовать наши продукты. Вот. Ну и мне очень понравилась картинка. Я нашёл в интернете. Тут вот есть ссылка, можно подробнее вот у Дмитрия Блинова на сайте посмотреть. Вот это вот последнее, то, что касается наших сервисо приложения карты. Как бы это начинается всего с карты опыта, потом CGM, потом есть такой ещё а инструмент, как сервис Blueprint. Там уже описывается, как у нас взаимодействует аа вообще все системы как бы на всём пути нашего пользователя. То есть это не только где у тебя пользователи на фронте как бы, но и как у нас тамнд работает, как там саппорт работает, какие отделы как бы бизнеса, какие системы какие-то бэкфисные, возможно. А вот, ну и User Story Map- это уже в каждом конкретном приложении типа что происходит со своим. Вот понимание продукта, второй навык. А какие здесь вопросы? Типа, собственно, их несколько. Собственно, это касается нашего продукта. Какую задачу он решает,

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

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

И отсюда может быть какой-то product и стратегия. А как бы долгосрочное видение картинки, куда мы идём и, собственно, для кого мы решаем эту задачу, кто у наши пользователя, почему именно мы решаем задачу. То есть там будет какой-то конкурентный анализ, как бы, и наши анализ наших преимуществ и недостатков. А какое целевое видение продукта, собственно, где мы хотим оказаться. И вообще мы строим это приложение. Мы строим приложение э на маленьком рынке. в России или это вообще мы хотим захватить глобальный рынок и у нас там своя уникальная бизнес-модель. И, собственно, как мы туда попадём? Должен быть какой-то план или roadmap верхнего уровня на год, э, как бы в первом приближении, как мы достигнем, э, этого видения. Вот.

Ну и, э, также есть такое понятие, как жизненный цикл продукта. Аа как бы есть, ну, как бы все продукты и сервисы начинаются с какого-то там рождения и заканчивается либо тем, что они превращаются в монополисты, вот, или корпорацию, либо умирает. Вот. А и вот здесь на каждом шаге, то есть вот здесь есть какой-то MVP запуск, есть там проверка productркетфита, как бы, есть какой-то дальнейший рост и улучшение. И здесь на каждом этапе продакты отвечает с бизнесом как бы и разработкой на следующий вопрос. Они как бы на этапе ещё до запуска пытаются проверить гипотезы спроса, собственно, вот этот уровень underстн, как бы проверить, а вообще это нужно пользователем или нет. это сделать через исследование либо через какие-то рад э способы, когда можно сделать какой-нибудь лендинг, ээ где как бы узнать спрос или какие-то фандрайзинговые платформы, где можно попробовать собрать деньги под этот продукт, как бы и узнать вообще нужно он людям или нет.

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

И тут проверяется следующее гипотеза. Гипотеза роста это, собственно как бы, о'кей, мы проверили, что там наш продукт пользуется спросом, он решает хорошо задачу, эффективно для наших пользователей, но возможно, что тех пользователей, которым привлекли, их очень мало и они какую-то маленькую долю рынка как бы занимают, и мы там не вырастем, и у нас экономика не сходится, и нам придётся закрыть. Вот. а-а, возможно, что мы решили какую-то узкую проблему, а дальше как бы, ну, вот как бы у других людей совершенно другая проблема, и они там не готовы прощаться со своими, а, текущими инструментами. В общем, здесь проходится гипотеза роста, где активно набирается какая-то аудитория, захватывается доли рынка. Вот, и дальше уже компания выходит на какую-то там положительную ебеду. Э-э, это может происходить на протяжении нескольких лет, как бы и, э-э, как бы сходится unitэкономиic, либо как бы продукт умирает, как бы, и закрывается.

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

Ну и потом вот эти вот собранные команды родились в такое понятие, как прокл команда, Producctam либо Vтиam. Вот иногда бывает ещё, что команда собирается там под определённую фичу, как бы фичить им. Вот. А, но я никогда не имел с ними дело, как бы у меня мало опыта с этим. Вот я больше с витимами работал. Вот. И это всё помогает как раз-таки взаимодействовать с другими функциями, в том числе как бы набираться экспертизы и в продукте, а как бы и взаимодействовать с каждой функцией, которая тоже имеет какую-то продуктовую экспертизу.

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

Вот в продукте как бы если как бы историческую хронологию провести, то вот а изначально был такой вот цикл деминга, а как бы который начинается там план do check. То есть сначала запланируй, сделай, проверь, как бы и и что-то ещё. Если честно, я забыл. Э, ну, в общем, это простой, как бы всем понятный, известный а алгоритм каких-то действий. Вот. Потом он в вырос уже в бизнесе в такой фреймворк, как э первая этап как бы define. Нужно определить, собственно, проблему, которую мы собираемся решать. Второй этап measure - это как бы оценить как бы масштаб этой проблемы и какие эффекты она даст. Потом проанализировать вообще а какие там провести какие-то исследования, а посмотреть причины этой проблемы, потом придумать, э, какое-то решение и улучшить что-то. Вот и проверить, как работает решение. Ну и последнее, проконтролировать, что как бы, собственно, это решение работает, и дальше его как-то масштабировать. Ну и как бы по кругу цикл. В общем, это, я думаю, очень похоже всем, кто в сфровых продуктах работает. Мне кажется, все компании по такому принципу работают. Вот.

Но в э в IT-компаниях любят придумывать и улучшать свои решения. И вот придумали такой вот фреймворк Double Diamond. Он состоит из двух частей. По-хорошему они называются там discovery и delivery. Я думаю, вы это все слышали. И даже есть отдельные профессии как бы discovery менеджеров и delivery менеджеров. Есть исследователи, есть как бы э менеджеры, которые отвечают за доставку каких-то решений. Вот. А здесь на самом деле четыре части, то есть каждая из них делится. То есть вначале мы, э, пытаемся как бы понять как бы проблему и понять, э, как бы какие есть вообще проблемы. Собственно, вот это вот расширение идёт как бы в первой оси. Аа как бы, собственно, понять, какой спектр проблем, потом уже выбрать из них какую-то одну. То есть вот, э, в серёдке точка, а problem definition. Это как раз из всех проблем выбирается та, которую нам нужно именно решать. То есть почему определить, почему именно мы должны решать, почему важно решать в первую очередь, а остальные проблемы позже решать. Вот. И потом уже дальше происходит похожая история, но с решениями. Определяются какие-то возможные решения и потом начинается оценка, а какая из этих решений наиболее оптимальная. Вот. выбирается одно решение и оно уже как-то реализовывается. Вот.

Ну и потом, э, как бы это всё трансформировалось в triple Diamond. Здесь на самом деле вот эта вот вторая часть delivве разбивается просто на две. Вот. То есть у тебя есть по-прежнему этап с Discoverovery с определением проблемы. Вот есть этап Discoverovery с определением а решения и какого-то концепта. И он валидируется ещё до полномасштабного решения. То есть это какие-то там прототипы UX исследования. Проверяется, что вот точно это решение э как бы сработает, ну или с какой-то долей, э веры и вероятности. Вот. Ну и дальше начинается как бы более подробный дизайн, разработка, а запуск на каких-то первых тестирование на каких-то доле пользователей, проверка и раскатка уже масштабирования на всех с какой-то, э, коммерческой составляющей. Вот.

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

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

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

А, ну и, собственно, здесь принять решение на основе данных. Есть разные подходы, а, data driving development или data inspired development. А разные компании на разных этапах обладают разным количеством объёмом данных. Не всегда получается точно получить там значимость, но нужно принимать решения. И здесь скорее данные помогают как бы вдохновляться, вдохновляют на какие-то решения, но всегда важно как бы все исследователи, исследования и аналитика нам нужны э как бы для того, чтобы принимать решение, что мы что-то делаем или не делаем, переходим мы на следующий этап или не переходим. Да.

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

Вот. аа тестироть самостоятельно. То есть вообще не всегда есть тестировщики у некоторых компаний. Вот мне вот личного сильно не хватает в моих внутренних продуктах. Аэ как бы тестировщикам важно проверять самостоятельный код для того, чтобы донести ценность, потому что если она не будет работать, ценности никакой не будет. Вот. Аа, и также помогает в формулировании задач как бы в снижении уровня неопределённости такое как бы подход как definition of, то есть чётко описать какие-то критерии, которые должны выполниться для того, чтобы считать, что как бы задача выполнилась и ценность доставлена до пользователя. Вот. То есть там может быть прописано, что нужно раскатить там на там 10% пользователя под таким-то флагом. А или же есть вот уже из agile и там лин подходов такой как бы подход как филид. А вообще во всей протовой команде может выбраться какой-то человек, не обязательно продукт, который вот предложит идею какой-то фичилит её. И как бы продукт ему поможет её проработать, там подскажет какие исследования провести и посмотреть. Вот. и он может её реализовать и потом положить себе на review какие-то дополнительные плюсы. Вот.

А ну и ещё один принцип you build it, you run it. То есть, если ты что-то делаешь, то ты это запускаешь. Не везде применяется, не всегда. Вот у нас нет такого принципа. У нас всё-таки всё проходит через аэ какое-то ревью, тестирование и всё-таки насрочная раскатка в во внутренних продуктах. Вот также важно, что когда нашёл проблему сообщи, ээ важно не замалчивать. Я вот ожидаю от своих ребят, что мы все там тратим какие-то годы своей жизни, и как бы мне важно приносить какую-то ценность. возможно, как бы не бизнесу, но пользователем. Мне хочется делать классные продукты, которым пользуются люди довольны. Бы если он как бы в команде как бы другое как бы у людей другой подход, им там что-то не интересно. Вот. Ну как бы разные ситуации бывают, разные периоды. Я сам тоже проходил через разные периоды в в своей карьере. Вот. Но всё-таки важен принцип: нашёл проблему, сообщи. Вот.

А в этом может помочь удобный процесс багрепортов. У нас во внутренних продуктах есть такой как бы жучок, который любой пользователь может нажать, завести тикет на бак. И у нас есть там какие-то процессы дежурства, у нас есть мониторинги, где это можно всё как бы разобрать, посмотреть. Вот. А, ну и как бы важный инцидентный процесс. Если на что-то падает, у нас есть понятный алгоритм, кто за это отвечает, что он делает, как бы куда сходить. Заводится инцидентный тикет, как бы, и потом ещё проводится ЛСР, где мы разбираем как бы как, насколько критичен был, как этого избежать э в будущем. Вот. Ну и есть подходы по метрикам. NBP ZBP это типа no баp посе и zero бак посе, где, собственно оцениваются вот эти вот баги, насколько они критичны и какой у них объём. И есть какой-то трешхолд, как бы выше которого мы не должны как бы подниматься для того, чтобы обеспечить определённый SLA, как бы уровень сервиса. Вот.

И здесь также важно, что как бы есть фраза, э, и мемы про то, что у меня всё работает. Как бы здесь всё-таки важно переходить к поддержке пользователей, не считать их глупыми, пытаться разобраться в проблеме. А в в моей практике последней трансформировалась фразу то, что система работает э ожидаемым образом. Как бы я долго как бы убеждал своих разработчиков в том, что как бы если мы неправильно написали алгоритм и что-то не до исследовали, не дополучили, как бы даже если вот попробовать самим попользоваться, как бы это не значит, что мы должны навязывать своё видение, решение задачи нашим пользователям. как бы всё-таки нужно к ним прислушиваться и и как бы решать. Вот здесь поможет процесс дежурства. А нужно в каждом каком-то тикете в в поддержке разбираться в проблеме, эта быстро найти решение. Ну здесь как раз вот работает принцип problemм solвиing. Вот. А нужно определить критичность проблемы. Не всегда стоит тратить кучу времени, даже если там пользо очень громко кричит. Как бы если у очень редко проблема, она в принципе не блокирует работу. то как бы, а мы не можем её как-то решить сейчас быстро, то можно положить её как-то в бэклок, как бы, ну, сообщить, что мы это увидели, мы это зафиксировали и там когда-то до этого дойдём. Вот.

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

Аа здесь есть другие вопросы, как бы, собственно, важный вопрос, типа, всегда вот, когда мы делаем какие-то продукты, мы или фичи должны задать вопрос: "А как мы вообще, в принципе, зарабатываем деньги? Как бы где они здесь для бизнеса? Возможно, там нет денег и нам не стоит это делать, э, даже если очень хочется, как бы, аа здесь помогает бизнес-модель и модель монетизации. Там есть вот несколько фреймворков, можно погуглить, там есть бизнес model, как бы вот там описываются, собственно, все контрагенты, как бы какие-то процессы, схемы, как взаимодействуют, какие метрики, за счёт чего получается прибыль, где какие затраты. Вот это можно посмотреть, какую долю рынка мы занимаем. Вот хорошо понимать. То есть вы работаете в маленькой компании вообще или вы работаете в корпорации или вы работаете в каком-то небольшом бизнес-юните внутри корпорации, который пытается захватить рынок, но всё ещё маленький. Здесь хорошо бы проанализировать рынок. А бывает такое, что мы делаем какую-то фичу и вот у нас есть конкуренты, э, и мы там они что-то запустили и нам нужно и у нас наши пользователи оттеклик конкуренту и нам нужно срочно как-то это компенсировать. Вот это здесь тоже важно. А, ну и, собственно, кто наши конкуренты? какой-то анализ э конкурентов, что они себе представляют, как они решают задачи, чем они, чем мы от них отличаемся, какие отзывы у пользователей на них, а и насколько эффективно работает наш продукт. Это больше вот про продуктовые метрики и маркетинговые. Там считается юнит экономика. По сути, юнитэкономика, а там как бы два принципа. Первое - это там считается ро эффективность возврата инвестиции. Это как бы а в общем ценность LTV метрика минус затраты на пользователя на каждого делённая на как бы собственно эти затраты. То есть насколько вообще вот как бы чистая прибыль делённа на затраты, насколько вообще мы в плюсе или в минусе. Вот. А, и там она считается на какой-то большой горизонт, и можно сказать, что там через год, набрав вот такое вот количество пользователей, они будут у нас оставаться в продукте, и мы выйдем там в плюс. Вот.

Аа, ну и второй принцип здесь то, что это там считается покагор, там смотрится на новичков, каждый месяц какая-то доля людей приходит, они там по-разному взаимодействуют с продуктом, как бы старички уже к одному опыту привыкли, новички к другому. Вот. И там они приходят из разных каналов. Юнит экономика ещё и для как бы разных каналов привлечения э строится. Вот. И там тоже высчитывается какоя-то эффективность этих каналов и эффективность нашего продукта. То есть в конверсия в какую-то там продажу или там покупку вот или просмотры. Если мы там видеосервис какой-то. А, ну и, собственно, какой вклад в бизнес приносит наш продукт или там фича. какая-то часть. Есть такой финансовый документ, как PNL, Profit and loss. Это такой просто список метрик, который отражает текущую ситуацию. Там ещё есть три других финансовых документа. А, но вот это вот туда больше всего смотрят продукты. Там есть наверху строчки, собственно, откуда мы получаем какой профит, а внизу строчки - это наши затраты как бы, э, сколько мы тратимся. И там где-то получается ебеда, как бы то, что важно инвесторам. Аэ, как бы и здесь вот как раз наши метрики может могут давать какой-то вклад в какую-то строчку пиннеля. И мы можем говорить, что вот наша фича там мы запустили, она дала там прибыли 81 млн, э, как бы рублей как бы за какой-то период. Вот. И это там классно. Вот.

Ну и подхожу к концу. Мои рекомендации вот как бы шмя школа менеджеров Яндекса есть в открытом доступе видеолекции с разных годов. Я учился там в двадцать четвёртом году, но как бы я каждый год ещё работая разработчиком, смотрел эти лекции. Больше всего мне понравился двадца второй год. Вот здесь есть как раз вот а важные для этих навыков лекции, где, на мой взгляд, лучше всего спикеры доносят мысль. Вот первое - это что такое продукт, э второе как бы стратегия для разных жизненных задач и стадии продукта. В том числе в этом, э-э, на этом видео как раз Аня рассказывает про подход как бы understanding identification execute, э, с примерами, э, там, охоты и рыбалки. Вот, чтобы это лучше понятно было и как это вкладывается в наша стратегия. Вот про продуктовое мышление команд разработки. Вот очень прикладной для нашего вопроса сегодняшнего доклад. Там хорошо рассказывает как раз про продуктовые команды и как могут взаимодействовать. Вот. Ну и обтесты как способ развития продукта. Э Роман Халкечев. Я видел несколько его лекций вживую. Он был руководителем аналитики в еде и по Новопоиске. Причём мне очень нравится, как он объясняет очень сложные темы и концепции с живыми примерами, как бы вот всем советы. Вот.

Ну и статьи из Goраce, где я отучился, а есть базовая статья про навыки продукт-менеджера, а которая, собственно, для понимания этого роли, если вы с ней взаимодействуете. И как бы навыки там тоже вот эти вот есть. Вот. и о продуктовой культуре. А там тоже есть вот в текстовом виде про этот фнвор, адинг и так далее. Вот там подробнее описано вот. А советую с этим ознакомиться. Вот.

Ну и всем спасибо. Ээ как бы если что, можете написать мне в личку в Телеграме. Вот здесь мой никнейм Super Adventure R. Либо, ну как бы не либо, а подписывайтесь на мой Telegram-канал. Технопродукт, э, я там не так часто пишу, в основном какие-то мои, э, личные мысли, идеи, какие-то планы, и я рассказываю про свой путь и успехи моих менти. Вот делюсь этим. Подписывайтесь. Вот. И как бы есть чат, э, как бы метапа комент, добавляйтесь в него. Вот. Всем спасибо большое.

Всё, спасибо тебе большое за доклад. Ребята, у кого какие есть вопросы? Угу. Так, я не вижу сейчас у тех, кто в зуме, и у меня есть ощущение, что все разбежались. Нене, не, всё. Больше половины осталось. На пике было 34. Часов начали уходить, да? Просто в 6:00часов многие начали уходить. Ну, человек 10, наверное, уж. Да? Звон. Ну, рабочий день закончился, да? Пора, давай.