-
https://tobeproduct.ru
В продолжение и поддержку прошлого поста.
12 сентября в 19:00 msk я проведу эфир с подписчиками и всеми желающими пообщаться.
Тема эфира: ценностное предложение, как важная часть CX стратегии.
Обсудим вопросы:
🟢Ценностное предложение – это продукт или что-то большее/меньшее?
🟢Управлять продуктом — это пилить фичи, смотреть метрики или есть какой-то еще объект управления?
🟢Как понять на каких фичах делать акцент при продаже? Или не на фичах? И вообще как ценностное предложение помогает продавать?
Я покажу какие инструменты я сам использую для управления ценностью. Прям разберем по косточкам некоторые примеры из новых продуктов Бюро. А еще поделюсь шаблоном в Notion для организации ценностного предложения и связывания его с JTBD.
Ссылка на эфир появится в канале. Если вы хотите, чтобы мы вам прислали ссылку в личку, чтобы точно не забыть — поставьте под этим постом плюсик в комментариях.
Если у вас есть вопрос, связанный с ценностным предложением, напишите его в комментариях.
А также я буду рад если вы поделитесь этим постом с теми, кому это интересно. Этого контента вы точно нигде больше не найдете.
Цель работы менеджера — повышение ценности продукта.
Содержание — множество различный практик, от формулирования стратегии и проведения исследований, через дизайн и воплощение, к доставке и монетизации (если у вас такой продукт).
Знания — основа всего. Менеджер продукта получает знания о реальности и использует их для того достигать поставленных целей в рамках выбранного набора практик.
Знание — основа каждого этапа и любой практики.
Мы получаем знания в процессе исследований. Мы воплощаем полученные знания и «прикладываем сверху» уже имеющиеся в процессе дизайна. Мы передаём знание командам, которые используют их чтобы разработать и доставить продукт. Мы используем знание, чтобы выбрать модель монетизации и узнаем много нового входе первых продаж. Мы получаем новое знание, с каждым новым запуском продукта или его части и используем все имеющиеся у нас знания чтобы принимать стратегические решения.
Все что мы делаем каждый день это получаем, передаём и используем знания.
С праздником всех нас.
P.S. Стоимость знаний — одна из важнейших ментальных моделей для менеджера продуктов. За некоторое знание, действительно, приходиться платить неадекватно высокую цену. Раз уж эта цена (зачастую невольно) уже была заплачена, остаётся только сделать так, чтобы полученное знание не пропало и было использовано по назначению.
#fundamentals
#growth #global_market
Хочется не забывать, что это канал не только про коммуникации, но и про продукты. Поэтому вот вам интересного: немного экспериментов по цене от Жени Лисовского.
Фаундер maps.me сейчас создает приложение ai coach для баскетбола и делится тем, как проходят эксперименты над retention и ростом CAC/LTV.
Фокусом тестирования были paywall и длительность триала. В работе было 3 гипотезы:
1️⃣ Hard paywall может увеличить конверсию в триал х2, а доход х1,5.
2️⃣ 7-дневный пробный период увеличит конверсию в CR на 20%.
3️⃣ Более низкие цены могут увеличить конверсию как в пробный период, так и из пробного в платный. 💰💰
Тестирование гипотезы 1️⃣
Hard paywall не оправдал ожидания: произошло снижение числа органических пользователей в 2 раза 🙈. Благо, команде удалось отключить paywall удаленно без выпуска обновления приложения.
Стало понятно, что необходимо дать возможность даже неплатящим пользователям использовать бесплатные функции приложения и приглашать своих друзей — это крайне важно для создания сообщества.
Тестирование гипотезы 2️⃣
7-дневный пробный период выправил ситуацию и сработал как часы: рост конверсии в trial на уровне 20-40%.
Однако между Android и iOS была существенная разница.
Тут Женя дает немного предыстории: оказывается, еще в сентябре 2022 команда установила цены для Android в 2 раза ниже iOS. Тогда к компании начал появляться значительный доход от Android, и сегодня это 45% всех доходов при доле Android 73% от пользователей.
В результате эксперимента доля органического роста на Android выросла до 80%, а на iOS составила 60%. Появилась мысль проверить эффективность более низкой подписной цены для пользователей iOS.
Тестирование гипотезы 3️⃣
Итак, команда приняла решение повысить цены для Android и снизить цены для iOS. Результаты:
💡 Снижение цены на iOS ($9.99 > $4.99) не оказало значительного влияния на конверсию от установки до пробного периода 👀.
💡 Умеренное повышение цены ($4.99 > $5.99) на Android привело к снижению конверсии из пробного периода в платного пользователя на 50-100% 📉.
💡 Единая ценовая политика без учета ВВП страны и покупательской способности, оказалась неблагоприятной для общего дохода 💸.
💡 Несмотря на наблюдаемый рост органического роста на iOS примерно на 10%, этого было недостаточно, чтобы компенсировать убыток в размере 30% от месячного дохода 💔.
💡 После повышения цены Android ($0.99 > $5.99) В странах типа США органический рост Android остался неизменным. Но в Филлипинах и тп появился негативный эффект 🌍.
💡 Почти во всех случаях конверсия Android из пробного периода в платного пользователя уменьшилась на 50% 🚨.
💡 Эксперимент был прекращен неделю назад. Скорее всего, потребуется две недели, чтобы доходы и конверсии восстановились. Всего эксперимент обошелся команде в 30% от месячного дохода 💰.
Вот такие вот неожиданные результаты экспериментов. Обожаю, когда честно делятся, что получилось, а что нет.
Источник (linkedin, нужен vpn):
Начало
Продолжение
Окончание
Поворчу немного, пока восстанавливаюсь от простуды полученной в 35-градусную жару.
Как кандидат, я всецело приветствую fast track / hiring day.
Как ментор/карьерный консультант — всем советую в них участвовать (но не обязательно принимать оффер).
Как наниматель — отношусь с большой осторожностью.
Как внешний наблюдатель, для меня это признак серьезных проблем в компании-работодателе.
Как представитель профессии, считаю что «оффер продакту за один день» признак фундаментальных проблем в нашей отрасли.
В следующий раз, когда будете смотреть на воронку активации в продукте (от визита на сайт, через регистрацию и т.д.) — задайте себе вопрос с голосования выше.
Если ваша продуктовая аналитика связывает гугл id (присвоенный GA) с внутренним юзер id. Если вы пользуетесь Amplitude. Если вы при этом GDPR compliant и если вы правильно настроили баннер про куки, то все треккинговые системы относятся к non-essential, а значит все пользователи, которые отказываются от ваших cookies (или игнорируют баннер, что по закону должно быть эквивалентно отказу), не будут учитываться в fronted generated статистике.
Итого, если у вас 60% посетителей сайта отказываются от cookies, значит вы не видите 60% visitors id или пользователей в Amplitude, а значит ваша воронка представляет только ограниченную выборку...
Для кого-то это может быть уже бородатым анекдотом.
Кто-то может включить треккинговые системы в обязательные cookies (по GDPR так делать нельзя, завидую если вы можете себе это позволить).
Кто-то может узнать об этом из этого поста (прошу прощения за плохие новости).
В любом случае, знать сколько людей остаются относительными невидимками для вашей воронки — должно быть полезно.
(Тем кто давно перестал доверять внешним системам статистики и научился считать эффективность маркетинговых кампаний без них большой привет и просьба поделиться опытом в комментариях!)
Кейс принятия решения.
(давно хотел вынести что-нибудь из практики, наконец-то нашел подходящий достаточно простой и при этом актуальный кейс)
Ситуация: в мобильном приложении MindMeister есть два редактора — легаси и новый.
Глобальная задача закрыть легаси как можно скорее. Новый уже дефолтный для новых пользователей.
Конкретная задача.
Приложение имеет интересную фичу: попробовать возможности, не создавая аккаунта.
Проблема в том, что такой тестовый доступ реализован только в легаси-редакторе, но еще не реализован в новом.
Данные:
— среди пользователей тестдрайва: 32% регистрируют новый аккаунт, 6,4% из них оформляют платную подписку.
— среди «обычных» пользователей регистрируют аккаунт 27%, оформляют подписку 6,2%.
Голосование: добавляем «тестдрайв» в новый редактор?
👍 — да 👎— нет
🤔 — есть вопрос (жду в комментариях).
Ок, байесовский подход к рациональности подразумевает, что мы должны быть способны изменить любое убеждение под давлением достаточного количества свидетельств.
Но как быть, если даже авторитетные источники ошибаются? Если даже тому что написано в Harvard Business (fucking) School нельзя верить!?
«As one example, consider a company that wishes to launch a new marketing campaign to revitalize sales during a slow period. Doing so could be an incredibly expensive endeavor, depending on the campaign’s size and complexity. The company, therefore, may wish to test the campaign on a smaller scale to understand how it will perform.
In this example, the hypothesis that’s being tested would fall along the lines of: “If the company launches a new marketing campaign, then it will translate into an increase in sales.” It may even be possible to quantify how much of a lift in sales the company expects to see from the effort. Pending the results of the pilot campaign, the business would then know whether it makes sense to roll it out more broadly.»
Ну то есть как, верить то можно. Главный западный источник курсов PM — Reforge — ссылается именно на этот обзор.
Но если мы с вами понимаем, что есть практический смысл в том, чтобы различать идеи и гипотезы, то приходится признать эти уважаемые источники (как минимум в данном случае) поставщиками слабых или вовсе плохих свидетельств, которые рациональный байесианец не станет использовать чтобы изменить свои убеждения.
А ведь так хорошо все начиналось: «A hypothesis or hypothesis statement seeks to explain why something has happened...»...
Зарплата сотрудника никогда не отражает его настоящую ценность для компании
Простое наблюдение: как бы нам не хотелось — достичь справедливой оплаты труда никогда не получится. (Если вы не работаете за прямой процент.)
После переговоров про оффер и выхода на работу — мы/нам платят больше чем мы приносим пользы.
Онбоардинг, первые проекты и изменения, которые идут на пользу компании — требуют времени. Все это время компания работнику «переплачивает».
А дальше, если вы/мы хорошо работаем, то довольно быстро переходим «точку равновесия» и начинаем приносить компании намного больше пользы, чем она на то рассчитывала. Компания начинает работнику «недоплачивать».
Продуктивность и приносимая ценность может колебаться, но у хороших сотрудников она всегда выше чем тот уровень, которой отражен цифрой в офере.
Если у вас в данный момент ниже — это повод задуматься о том что не так с вами или с компанией, которая не может получить от вас адекватную пользу.
Если выше — конечно, повод начать обсуждать это с руководителем. Только не рассчитывайте, что тот сможет адекватно оценить это соотношение (и вообще выразить его в деньгах). Это сложно.
Факт остается — если сотрудник может приносить вариативную пользу (не работает на нормированном производстве), то недо- или переплачивает компания сотруднику всегда.
Интересно, что какие результаты будут у такого NPS )
Читать полностью…
К отличному кейсу для проверки зрелости дизайнеров добавляется прекрасная статья бывшего CPO Duolingo.
Теперь, если вы хотите, понять уровень своего или чужого продуктового мышления — у вас есть для этого прекрасная возможность / кейс стади для обсуждения.
Про разницу идей и гипотез. Пример.
Коллега-продакт поделился вопросом с интервью:
«Наверняка ты видел на картах Apple фичу, когда сильно приближаешь дом и он отрисовывается как 3d модель.
У нас в курилке возникла идея таким образом визуализировать новостройки, которые продаются на ранней стадии. Чтобы люди на карте могли изучить район, двор, понять куда окна выходят у квартир, померять расстояние до метро ну и так далее.
Как бы ты проработал эту гипотезу, чтобы принять решение о её судьбе, не привлекая разработку?»
Если вы смотрели мою предыдущую попытку объяснить, что не так с применением этого понятия в русскоязычном менеджменте продуктов, то, наверняка, заметили, что в последнем предложении выделенный термин применен неверно.
Более того, даже в самом вопросе интервьюер использует два термина взаимозаменяемо. Почему же это так плохо?
На мой взгляд, постановка вопроса «как бы ты проверил эту гипотезу?» (при неправильном понимании этого термина) — очень легко приводит к тому, что продакты идут и начинают думать: «А, действительно, как нам понять, стоит ли что-то здесь делать, не привлекая разработчиков?»
Грубо говоря, «если гипотеза есть, то как мы ее воплотим в жизнь, потратив минимальное количество денег?» или «как нам проверить, что на этом можно заработать?».
Отсюда появляются коридорки мокапов, MPV из разных подручных субстанций, fake door тесты и прочие техники сэкономить время и получить какие-то свидетельства в пользу этой идеи. Что, само по себе, я очень и очень приветствую! Но, только если у этой идеи есть основания.
И здесь как раз помогает правильное использование понятия гипотеза.
Гипотеза это предложенное объяснение наблюдаемого феномена.
В данном (и любом другом) кейсе даже если мы начинаем с идеи — никогда не поздно сделать шаг назад и попытаться понять:
— есть ли какой-то феномен, можем ли мы его обнаружить, показать в виде данных, записей пользовательских сессий, ответов респондентов?
— как мы его объясняем?
— как мы можем это объяснение использовать чтобы получить новое знание?
— какие идеи мы можем на основе этого знания сгенирировать?
и только после этого
— как эти идеи можно максимально экономно проверить?
Раскручиваем кейс в обратном порядке:
Идея: давайте визуализируем новостройки, чтобы люди могли изучать их окрестности?!
Гипотеза: люди хотят узнать что-то о потенциальном месте жительства.
Феномен: люди ищут на карте места новостроек и проводят какое-то время исследуя объекты поблизости.
Можем ли мы этот феномен увидеть, пронаблюдать, зафиксировать? Обнаружить в базе данных запросы к пока еще несуществующим адресам? Посмотреть на эти адреса, понять что там сейчас идет строительство?
Найти сесии, в которых пользователи кружат по карте вокруг пустого места (строящегося дома) и буквально демонстрируют описанное в вопросе поведение?
Если да, то это уже хорошее начало!
Если мы найдем значительно количество таких людей, это поможет сформировать гипотезу: «люди используют карты, чтобы исследовать районы вокруг новостроек».
Эту гипотезу можно быстро проверить поговорив с людьми, которые это уже делают — и заодно узнать много нового полезного об их потребностях, задачах, текущих решениях... (чувствуете запах JTBD?)
Если нет, если пока такой феномен не наблюдается, это тоже отлично! Это еще не повод списывать идею со счетов, но повод все проблематизировать.
Изучают ли люди вообще будущий район? Как они это делают сейчас? Может быть они это делают только для уже построенных домов? (И т.д. и т.п.)
Заметьте, мы еще даже не начинали думать, как проверить эту идею, не написав ни строчки кода.
Но мы уже начали работать с ценностью, пытаться разобраться, если она. И, я уверен, даже в таком виртуальном обсуждении уже получили кучу идей как ее наличие проверить.
Закругляясь, последний тезис: с генерацией идей у нас почти никогда нет проблем.
С гипотезами, на самом деле, тоже. Просто их нужно уметь а) рефлексировать (ретроспективно обнаруживать), б) проблематизировать (задавать вопрос о феномене, на котором они основаны) и в) проверять.
🧐🔬💡
«Давненько не брал я в руки шашек!» ©
Главное, что мне помогало готовиться к ответам на разные типы вопросов — попытка понять, для чего hr или нанимающий менежджер их задают.
Забавно, что в моем опыте на один и тот же вопрос, представители разных компаний, кажется, хотели услышать немного разные вещи.
Например, при решении одного кейса собеседник очень интересовался тем как я буду что-то считать, проверять, какие данные буду использовать.
А другой потенциальный руководитель был очень внимателен к общей, методологической рамке — какие шаги, в целом, я буду делать и почему именно их.
Поэтому первый практический совет: прежде чем выбирать подход к ответу на вопрос, еще до собеседования, стоит попробовать сопоставить, что написано в описании должности, чем занимается компания и в чем особенности продукта — чтобы заранее представлять, что конкретно может больше всего интересовать автора вопросов.
Если в кейсе нет информации о пользователях, конкретных данных и описания бизнес-специфики — скорее всего в нем пытаются проверить вашего понимание методологии.
Ок. Значит можно начинать буквально с нее. Например буквально обозначить верхнеуровневые задачи из Inspired: de-risk product value, usability, feasibility and business viability и… на этом замолчать!
Второй практический совет: кроме уточняющих вопросов на старте — не стесняться останавливаться после каждого логичного куска ответа и спрашивать: «Хотите на чем-нибудь подробнее остановиться?». Это даст интервьюеру возможность не вежливо слушать 15-минут монолога, а, опять же, сразу задать вопросы, которые его по-настоящему интересуют.
Если конкретного направления разговора дальше не задано, ок — можно остаться на уровне методологии и просто перечислить основные подходы/инструменты для каждого этапа.
«Здесь я сделаю это чтобы получить то-то, этот результат я использую чтобы дальше сделать так-то и т.д.»
Возможно, в моем случае это работало, потому что я собеседовался на позиции от Senior и выше, но small и midsize в компании
Product Gym и прочие карьерные консультанты обычно рекомендуют готовые шаблоны. Говорят, что в FANG даже ожидают от кандидатов конкретную структуру ответов на конкретные вопросы… Для меня это выглядит немного странным, и, кажется, что «хакнуть» такое интервью проще, чем вдумчимо поговорить с нанимателем о том, что его действительно интересует (третий раз к этому возвращаюсь, видимо, потому что сам нанимал продактов).
А еще я слышал, что хорошо помогают мок-интервью ))
Предложение AMA действует всю неделю!
Пока было три вопроса (и один в личку). Мне отвечать очень понравилось — почувствовал, что приношу пользу.
(Спойлер: у этого эксперимента два исхода)
Начну с шутки )
Несколько лет назад появился отличный мем о том что «попугая научили задавать вопрос „Чтобы что?“ и повысили до Product Lead».
В том смысле, даже текущий уровень GTP3.5 позволяет предпринимателю прошедшему «курс написания запросов» отложить найм первого продакта и потратить спустить деньги на «проверку» сгенирированых LLM «гипотез» самому.
Так что да, жду мемов о том, как ChatGTP устроился работать Middle PM.
Ироня тут в том, что и «попугай и AI» могут легко заменить людей, которые практикуют карго-культ — выполнение ритуалов процесса без понимания их реальной сути. Но их вообщем-то и не жалко.
Ну, и, да, сократить и без того маленький рынок джунов-продактов.
А в дальней перспективе все зависит о того, насколько быстро придет AGI и насколько aligned он будет… ((
В качестве практической ремарки замечу две вещи.
По моей оценке:
— быстрее и сильнее чем продактам AI угрожает дата-аналитикам. Находить неочевидные, но полезные инсайты машине сейчас намного проще чем людям. Осталось только данные подключить к правильным интерфейсам.
— самое важное применение AI в ближайшем будущем — Microsoft Copilot (и его аналог в Google Docs, Sheets, etc). От того насколько они упростят работу с офисным пакетом будет зависить а) судьба многих непрямых конкурентов б) перспективы внедерия настолько же полезных AI-фич в других инструментах. И вот это может сильно проблематизировать роль продактов во многих компаниях. Если ценность продукта для конкретного пользователя начинает зависеть от AI — не так много места остается настоящей работы для нас с вами.
Барьеры выявлял через серию немодерируемых юзабилити-тестов.
Все по полному циклу:
— сначала метрики подсветили возможную проблему;
—затем наблюдение позволило подтвердить трудности и сформировать три гипотезы (возможные причины наблюдаемых проблем)
— первая серия юзабилити-тестов помогла валидировать гипотезы (да, да, нет)
— потом последовали изменения в продукте, чтобы адресовать подтвержденные проблемы
— и вторая серия тестов, чтобы удостовериться что изменения сработали
— и дальше продолжили наблюдать за метриками.
В итоге мы значительно улучшили продукт, но исходная метрика почти не сдвинулась с места )
Это позволило выдвинуть и начать проверять уже следующий набор гипотез, про качество маркетинга и про изменившиеся паттерны поведения в продукте.
Думаю на это еще полгода уйдет )
За прошедший год я узнал о своем продукте:
— в чем ключевая ценность техники майндмэппинга и насколько наш продукт ее уже обеспечивает;
— какие барьеры в активации мы все ещё не устранили на пути наших новых пользователей (а какие устранили);
— что работает, а что не работает в качестве триггера для конверсии в платную подписку;
— чего на самом деле пользователи ждут от AI-фич;
— каково наше реальное положение на рынке и где еще можно расти...
И, конечно, много всего про команду, коллег и компанию.
Пишите в комментариях о своих новоприбретенных знаниях или спрашивайте о подробностях, если вас что-то заинтересовало.
С праздником, с днём знаний всех нас.
P.S. К сожалению, за этот год мы все так и не получили ответа на главный вопрос... Надеюсь, следующий день знаний мы будем встречать, в этом смысле, в совершенно другом состоянии.
https://www.lennysnewsletter.com/p/the-ultimate-guide-to-jtbd-bob-moesta – 🔥
Читать полностью…
В догонку мой комментарий из внутреннго чата. Take it with a grain of salt, а еще лучше расскажите мне в чем я не прав.
My two cents on the cookie banner/frontend tracking situation:
– in the long run, frontend tracking will experience constant pressure from browser tech and legislators (and user habits)
– we need to come to terms with the fact that frontend events will produce only partial data, it was actually so for a long time, we just preferred not to notice it (safari users, ad block users, people who were rejecting our previous coockies – they all been there for years. That’s one of the reasons why Amplitude data was never consitent with Metabase charts based on backend events)
– we need to develop ways to determine how representative partial data we still have is (in a way, it is like sampling, we just don’t control who is included in the sample).
– in the long run, we need to understand how to not rely on frontend tracking. How to track users and their behaviour with backend events.
– we need to be able to calculate particular KPIs with an explicit confidence level (or error margin). This would require a huge mental shift because revenue will become one of the very few things that will be still precise.
– and this is also a good chance to get to the cohorts’ way of thinking. If we can’t track individual site visitors becoming particular product users, we still can track backend user IDs and create cohorts of them based on signup date, feature exposure, self-reported onboarding survey data, etc.
Непопулярное мнение.
Лучшее что вы можете сделать для продукта — оградить команду разработки от чтения и реагирования на входящие тикеты.
Завести правильный процесс обработки и классификации обращений, определить критерии эскалации, организовать bug smashing week once in a while.
Инженеры будут сконцентрированы на приоритетных вещах и благодарны за хорошую организацию работы. Продуктивность и скорость доставки важных изменений продолжат расти.
НО.
Лучшее что вы можете сделать для продукта — найти (или воспитать, что гораздо труднее) разработчиков, которые будут хотеть чувствовать боль клиентов, видеть тикеты и реагировать на них как можно оперативнее.
Такие инжерены будут лучше понимать смысл и пользу продукта и будут приносить не абстрактную, гипотетическую пользу в будущем, а реальные улучшения клиентского опыта сейчас.
А еще будут писать код с меньшим количеством багов, угу.
Конечно, в реальности это должен быть careful balancing act.
Проблема в том, что первый подход — закрыться в башне из слоновой кости — социально приемлимый способ организации продуктовой работы, поощрямый культурой «хороших процессов».
Второй — возможность вернуть «дух стартапа» и сделать продукт лучше прямо сейчас. Но, увы, это непопулярное мнение.
Исследовать или тестировать?
🧪 Тестировать!
1. Наблюдаем феномен: подписчики очень редко делятся постами.
2. Выдвигаем гипотезы (да, сразу целый набор). Одна из них — «люди реже делают то, о чем их явно не просят».
3. Тестируем гипотезу: готовим пост, в котором просим подписчиков им поделиться. (Как выяснится потом, тут уже «могут быть нюансы»).
4. Наблюдаем результат — ровно столько же расшариваний, как и обычно.
5. Делаем выводы…
Затраты на тестирование — 30 минут.
Полученная информация — 0 единиц новой информации.
Что пошло не так? Много чего, но узнали мы об этом? Нет.
🔎 Исследовать!
1. Наблюдаем феномен: подписчики очень редко делятся постами.
2. Выдвигаем гипотезы, целый набор.
3. Проводим исследование — буквально спрашиваем подпичисков, почему они не делятся постами.
4. Получаем, загибайте пальцы:
а) Новое знание о части аудитории (не пересекаются ЦА).
б) Знание о том, что «маркетинговые посты» не хочется шарить (можно было без этого обойтись, но так как время на него уже потрачено, грех не спросить).
в) знание о том, кто-то не будет шарить посты ни при каких обстоятельствах (Леша, привет! Надо быть эту установку раскопать, да?)
г) знанием о том, что никто из принявших участие в опросе не считает контент канала негодным для шэринга. (Честно говоря, были у меня и такие подозрения).
Затраты на исследование — 15 минут.
Полученных знаний — как минимум три единицы.
———
Итого, что лучше: проверять гипотезы через реализацию идей или через предварительное исследование. Ответ, как всегда, it depends.
Но, если по-честному посчитать impact to effort, то окажется, что в одном случае за 3 единицы затрат я получил 0 единиц знаний, а в другом за 1,5 — 3 или даже 4.
Будет ли таким соотношение всегда? Вряд ли.
Но если у вас есть настоящая гипотеза (предположение о том, почему что-то происходит) и вы можете проверить ее анализом данных, опросом, юзабилити-тестированием или несколькими интервью — скорее всего такое исследование будет стоить дешевле и принесет больше инсайтов.
Реализация идеи, кроме бо́льших трудозатрат, часто еще и несет трудности установления причинно-следственных связей. Вдруг вы начнете шарить посты просто потому примете участие в каком-нибудь челлендже.. Мне об этом никак не удастся догадаться )
В следующий раз, когда вам предложат протестировать гипотезу, вспомните этот пост (или даже расшарьте его коллеге).
@tobeproduct
#гипотезы
Привет!
Автор канала «Быть продактом!» попросил своих подписчиков переслать это сообщение тем, кому канал может быть потенциально полезен — поэтому шлю это тебе )
Антон — ex-CPO Selectel, сейчас работает в Вене и руководит международным продуктом для создания интеллект-карт с многомиллионной аудиторей. Кроме того он создал и поддерживает базу знаний tobeproduct.ru – набор скиллов и инструментов, книжек и курсов, каналов получения информации для менеджеров продуктов.
У себя в канале Антон пишет о знакомых любому продакту темах с собственным авторским подходом к ним, вот примеры:
— что не так с пониманием и применением «гипотез» (пример про разницу с идеями)
— в чем опасность freemium модели монетизации (в том числе о проблеме реализации этой модели в Телеграме)
— как проверить дизайнера на наличие продуктового мышления
— и, конечно, как быстро LLM заменят менеджеров продуктов и есть ли риски для действительно крутых специалистов (спойлер: заменят только и так редких джунов)
Бонусом два выпуска «подкаста» (про нынешнее состояние нашей профессии и про пользу и границы применимости любых фреймворков) и возможность задать автору вопрос и получить ответ.
В общем, 🔥 , подписывайся: /channel/tobeproduct
Про страх
Уже больше года, я активно практикую baby steps в преодолении страха во многих сферах жизни. То есть, целенаправленно делаю то, что мне страшно, и этот год оказался одним из самых продуктивных за последние 4 года с точки зрения достижений в карьере, знакомств с интересными людьми, а также общего ощущения счастья.
Вот простое упражнение по факторизации страха:
☑️Найдите тетрадь или блокнот, а также ручку или карандаш.
☑️Напишите свой страх в центре страницы одним словом или фразой. Например, "выступление", "новые люди", "потеря работы" и т.д.
☑️Теперь разбейте свой страх на факторы, которые вызывают у вас беспокойство или тревогу относительно этой ситуации.
☑️Запишите каждый фактор в виде ветвей, выходящих из центрального слова. Например, если ваш страх - "выступление", факторы могут быть: "страх перед публичным выступлением", "боязнь забыть текст", "страх оценки окружающих" и т.д.
☑️После того, как вы разбили страх на факторы, продолжайте факторизацию каждого фактора. Например, если один из факторов - "страх перед публичным выступлением", разбейте его на еще более конкретные факторы, такие как "трясущиеся руки", "потливость", "кардиобитье" и т.д.
☑️Продолжайте разбивать страх на все более мелкие и конкретные факторы, пока не дойдете до самых базовых и основных составляющих вашего страха.
☑️Теперь, когда вы разложили свой страх на факторы, возьмите каждый фактор по отдельности и постарайтесь рационально оценить его. Задайте себе вопросы: "На сколько реальны эти факторы?", "Каковы шансы на то, что это действительно произойдет?", "Что я могу сделать, чтобы справиться с этим?"
Вхождение в страх растворяет страх, не надо его бояться. Страх расширяет, когда ты его не избегаешь, а принимаешь, что он есть, и проживаешь его.
Написано под Shortparis «Страшно»
Обнял✌🏻
Поделился с коллегами в рабочем чате, поделюсь и с вами )
I have a saying that “Everyone is a designer”.
AirBnB co-founder, a professional designer by origin, tells the story of how they pivoted their company to be design-oriented (basically, following Apple’s footsteps).
And about the true meaning of design (and simplicity!).
Two parts especially resonated with me: the amalgamation of product and marketing and the passing mention of the true meaning of hypotheses.
I bet that designers will find it interesting how Brian describes their role in his company.
To his other points, I agree with the role of long-time vision but really disagree with the two-releases-a-year approach.
And I would also stretch his design-based approach even further, because, in reality, everybody makes design decisions all the time. Especially in such small teams as we have. Especially when we empower people to do that by applying CI/CD principles.
Hope you find this short video as thought-provocative as I did!
Глубоко уважаемые Clearer Thinking попросили рассказать о них людям, которым они могут быть полезны.
Рассказываю: инструменты и бесплатные мини-курсы, помогающие узнать что-то новое о себе и научиться лучше принимать решения — безусловно полезны продактам.
Качественное определение менеджера продуктов (не путайте с функциональным и другими) — социально-компетентный рациональный агент измеримых изменений.
Приблизиться к такому состоянию помогает, в том числе, и этот сайт-набор инструментов.
Ещё один юзкейс AI. Теперь для продуктов:
1. Описываем текущий статус компании: что делает, кто клиент, какие фичи, кто конкуренты, — кратко, но содержательно.
2. В Notion AI вызываем prompt "/Brainstorm ideas" и добавляем "based on the above and your own knowledge".
3. Читаем список, который радостно даёт нейронка.
4. НЕ ДЕЛАЕМ этот список — ничто из этого не будет конкурентным преимуществом
@kratko_po_delu
Сразу несколько знакомых коллег (Лев, Катя, привет!) проходят сейчас процесс онбоардинга в новых компаниях.
Это напомнило мне, что как раз год назад я тоже выходил на новую работу. По следам того опыта собрал шаблон, который помогает продакту не захлебнуться в потоке новой информации и не забыть вовремя узнать и, главное, зафиксировать самое важное.
Компания, продукт, люди, процессы. Чек-лист онбоардинга как фундамент будущей карты ваших знаний — onboarding checklist → body of knowledge map.
Берите за основу, модифицируйте, наполняйте.
Ценность, гипотеза, эксперимент. По версии Runwayml.
Читать полностью…
На всякий случай напомню, что предложение AMA все ещё действует )
Читать полностью…