Архив недели @ZiminAlex
Понедельник
Всем привет, на этой неделе с вами Александр Зимин.
Я в прошлом мобильный разработчик, провел в карьере разработчика 7 лет. Работал от контрактов и стартапов, до крупных компаний, таких как Badoo, но почти всегда интересовался продуктовыми вещами
3 года назад решил запустить свой нетфликс для текстовых игр, вышло интересно и принесло 300к установок, но не росло, поэтому я пошел работать в стартап к бывшим фаундерам Lazada и теперь работаю продуктовым менеджером в нем. Адаптируем социальный e-com: apps.apple.com/us/app/agora-s…
Чтобы внести разнообразие в контент, решил построить провокационный план недели:
ПН: Моральная сторона продуктового менеджмента
ВТ: Продуктологи VS Маркетологи (в процессах принятия решений)
СР: Взаимодействие бизнес и тех. команд в стартапах
ЧТ: Наши продуктовые процессы
ПТ: Технологический бекграунд
СБ: Что если мир развалится? А где, собственно, инновации?
ВС: Отдых или общение
Ну и, конечно же, буду рассказывать про социальный e-com. В Китае он уже улетел в космос, а вот в Европе и США его только хотят привести на рынок.
Успешных купит Амазон/FB/Google за много денех, ну или они сами станут будущем амазоном)
Сегодня день моралиста, а значит мы обсудим: подписки, рекламу, манипуляцию метриками, создание крючков, провокационный контент (желтые заголовки, вызывающие картинки и т.п.), демпинг услуг и прочее, про что большинство продуктов прекрасно знает)
Вот это провокация, охуеть можно. Показываю первый и последний раз как надо: Пн: сесть на бутылку или стать РМом? Вт: разъебать очко маркетолога или своё? Ср: как перестать быть ебучим графоманом и перейти к сути таски в жире. twitter.com/produnderhood/…
Топ, прям в тему 1-го дня) twitter.com/a1tusha/status…
Давайте начнем с опроса, как много инструментов в вашем продукте, которые вы считаете не совсем правильными по отношению к юзеру, но важными для роста продукта?
Вообще практика применять какие-то трюки пронизывает почти любую сферу со временем, как только в ней появляются игроки, которые используют "допинг".
Другой вопрос, будет ли это направлено на вас лично (как допинг в спорте) или на потребителя (как лозунги в рекламе)
На днях увидел такой прекрасный постер, который был в журнале LIFE 1970. К тому времени уже было достаточно понимания насчет влияния сахара
Статья: divinations.substack.com/p/oatly-the-ne…
А вообще к теме использования разных хаков для личного преимущества есть отличный документальный фильм: kinopoisk.ru/film/732702/
В нем анализируется что же может влиять на человека:
Вспомнить заповеди – уменьшит читерство
Давать виртуальные монеты, как промужуточную награду, которую уже потом можно менять на реальные деньги – увеличит читерство
Я пришел из мобилки и в какой-то момент эту сферу захватили подписки, на мой взгляд это даже своего рода легальный обман
Вот вам головоломка: если сильно не вчитываться в комментарии, то какое приложение на видео?
Примеры отзывов картинкой
Ну не буду долго таить, это Calm, когда-то его оценили в 1 миллиард долларов
forbes.ru/tehnologii/372…
Это приложение, у которого на момент статьи был ретеншен 2-3% 30-го дня, судя по выгрузки из интересных сервисов)
7-го дня не сильно выше был (в лучшие месяцы 4%), кстати
Не ругайте за скрин, если бы я сюда из A повесил, у меня бы были сложности)
Правда в iOS 13 Эппл немного напряглись и усложнили процедуру: gopractice.io/blog/change-in…
Но это не сильно работает
Запросил у знакомого скрин по месячным подпискам
Говорит на 3-ий месяц дай бог 10% чарджихся использует (это 1.5%), а вот платят 15%
Это рынок США
Еще прикольно, что 7.5% заряджаных приносят ему в год 20$ * 12 = 240$ без использования приложения
Если кто-то вне контекста, как примерно это работает, то вот вам пример приложения, что зарабатывало 2 ляма год назад (судя по сенсор тауер)
А вот видос, очень доооолгий
@produnderhood тренд подписок - это худшее, что происходило. Когда это уже закончится и станет дурным тоном?
Эх, если бы был простой ответ
Но было бы интересно послушать мнение аудитории, а я свое под вечер выскажу :) twitter.com/sanchower/stat…
@ramzesenok @sanchower @produnderhood А вообще горячо рекомендую ознакомиться с темой, т.к. она полезна в целом (не только в работе). У господина Ханина есть хороший курс видео: youtube.com/watch?v=q1P8As…
Тут образовался довольно интересный тред
В целом кажется все логично, надо финансировать разработку, считать юнит экономику и вообще хорошие ребята не положат себе лишние деньги в карман
Но как всегда есть свои нюансы... twitter.com/HappyVlad/stat…
Попробую объяснить его на пальцах:
У вас есть луг, у вас хорошие коровы, вы добываете молоко и мясо, продаете за 50$. В целом это хорошее молоко и все окей
Тут ваш конкурент открывает стероиды, гормоны роста и прочие приколы, начинает пихать им, получаете куда больше некачественного мяса и продает за 30$
В целом пока все еще окей, кто надо покупает качественное мясо, кто не надо, некачественное
Но тут у конкурента заканчивается территория, ему перестает хватать клиентов, но т.к. его продукция дешевле и он явно не очень моральный товарищ, то он начинает скупать всю вашу землю, заказывает на вас негативную рекламу и т.п.
В итоге через какое-то время он останется один на рынке, может даже цены поднимет)
В целом так часто действовали монополии, привет AT&T, мягкие и 2020
Но подписки для меня ровно так же ломают экономику некогда здорового рынка
Вероятно вы бы делали свое приложение и продавали за 20$, вам хватало на маркетинг, на зарплаты, вас фичерят в App Store и Google Play.
Но когда у вас на рынке гороскопы, которые гребут по 2 мульта в месяц, они могут позволить повышать рынок зарплат, перебивать маркетинг ауки
Ну и гуглу, и эпл выгоднее их показывать на главной странице, потому что 30% на дороге не валяется)
Подписки вряд ли от нас уже уйдут, но если бы я выстраивал идеальный мир, то работал бы над следующими направлениями:
Единое крыло распределения контента (хороший пример Sony и ее эксклюзивы т.е. прекрасные игры с one time payment уживаются с pay to win шлаком)
На macOS хороший пример для меня Setapp
Улучшение опыта trial
Например, что после 3/7 дней триала у тебя не списывают деньги без дополнительного подтверждения
Это сильно снизит доход шлаковых приложений, тем самым улучшит баланс на рынке рекламы/кадров/фичеринга/топов
@produnderhood Когда люди не читают условия при скачивании...
Мой любимый кейс к этой теме: донорство органов twitter.com/Truskova/statu…
Нет, в Германии не живут очень плохие люди, как можно было подумать.
Просто в Германии, нужно подписаться, чтобы донатить
А в Бельгии отписаться, чтобы не донатить
researchgate.net/figure/Effecti…
Я это вел к тому, что можно сколько угодно говорить, что люди сами дурачки, но если общество не будут направлять люди с чувством соц. долга, то это общество очень быстро загнется)
В рамкам цифровой экономики это тоже работает)
Работа с возобновляемыми подписками
Например, если пользователь не посещает сервис, то зачем его чарджить?
Тут сложности в том, что если у сервиса есть сайт, то юзер может просто не использовать мобильно приложение. Но это техническая сложность
Морализация контент провайдеров
Редизайн App Store в iOS 11 открыл новые возможности, теперь редакторы Apple составляют рекомендации того, что юзерам качать
Вот только среди этих рекомендаций очень часто оказывается прибыльный мусор
Хотя качественного контента там тоже много
Вторник
@produnderhood Расскажи про социальный коммерс. На какие рынках работаете? Как заставляете авторов сидеть заходить не через инсту или тик-ток?
Для тех, кто вне контекста:
Social e-comm – это направление, когда у вас "ядро" магазин (с категориями, брендами и т.п.), но поверх его много социальных механик, таких как UGC (контент, который создают юзеры), лайки, комментарии twitter.com/kidrulit/statu…
Это дает 2 основных преимущества:
Контнет драйвит покупки (больше привлекательности, больше информации, люди получают комиссию)
В социальных сервисах ретеншен всегда очень хороший, а значит это стимулирует частые покупки
В китае уже на лайвстримах умудряются продавать товаров на сотни тысяч зеленых, а вот в США и Европу тренд только идет
Что такое e-commerce: valtech.com/insights/socia…
Пример роста RED в Китае: walkthechat.com/xiaohongshu-li…
Возвращаясь к вопросам: мы сейчас тестируемся на рынке UK в сфере Beauty, но планируем приоритетно захватывать Европу (в США уже есть похожие игроки, но они только растут)
Для привлечения и удержания авторов есть другая механика, о ней сейчас расскажу
сс @kidrulit
Мы запартнерились с брендами, которым интересно раздавать свои товары (в beauty это нормально, т.к. если тебе понравится, ты будешь покупать один и тот же товар N раз в год)
Ввели механику монет на платформе, что позволяет авторам контента зарабатывать их
Каждый день можно получить товары партнеров за эти монеты (но надо быть достаточно активным)
В целом монеты даются за много разных активностей, включая взаимодействие с чужими роликами
Это создает просто бомбический ретеншен и энгеджмент от создателей контента
Так же у нас есть небольшой "штат" своих инфлюенсеров, которые работают на платформе. Их задача создавать качественный контент, который мы показываем в приоритете
Сегодня будем обсуждать майндсет: продуктовый vs маркетинговый
Вброшу такой видос из интервью с Джобсом
Если вы работаете в крупной компании, скорей всего у вас ближе ко второму
Вас не заботит, можно ли перестроить сервис (да вам этого и не дадут сделать), вам надо будет запустить A/B тест на лучший экран акции, подумать как внедрить платежку партнера...
...придумать механику, чтобы нарастить ретеншен (например геймификация), придумать какой пуш увеличит ваши метрики и получил лучшие CTR и т.п.
Вы отчитываетесь перед руководством за рост, а не за инновации
Это иронично, что слово "CTR" от продуктовых менеджеров последнее время можно услышать очень часто, а вот википедия пишет, что это "метрика в интернет-маркетинге"
Но важно понимать, что оба направления важны для развития индустрии, главное понять что ближе.
Я знал парня, который работал продуктовым менеджером в крупной компании, неплохо справлялся со своими обязанностями, но каждую пятницу рассказывал нам, что рынок катится куда-то...
... в итоге спустя время этот парень ушел в один Лондонский стартап от топов из Airbnb и сразу жизнь заиграла новыми красками, рассказывал как там круто
Я еще тогда сделал вывод, что очень важно искать то, что тебе по стилю работы ближе
Но как же определиться?
Тут нет однозначного ответа, но я бы советовал:
Записывать какие задачи на работе делать комфортно, а какие нет, попробовать найти зависимость
Сформировать принципы и ценности (тут нельзя нет посоветовать Рея Далио), выбирать сферу по ним
Мне, например, очень близки ценности нетфликса. Очень хорошо понимаю, почему они избегают отображения рейтингов для фильмов)
Менять работу раз в несколько лет, не бояться терять в зарплате, особенно если еще обязанностей нет
Попробовать сделать пет проект (или полноценный стартап), понять каким задачам уделяешь больше всего времени, а что раздражает
Спросить коллег как они видят вас, что их восхищает в вас
Подумать чем вам нравилось заниматься много лет назад и какие у вас сейчас хобби
А вы понимаете себя?
Что вас больше драйвит?
Если варианты не очень, пишите свои предпочтения в работе над продуктом, вдруг это радикально изменит чью-то карьеру? ;)
Среда
Сегодня мы обсудим взаимодействие бизнес и тех. команд в стартапах (в крупных компаниях, обычно, все уже выстроено)
Для меня последние полгода это самая большая боль, но у меня есть плюс: я побывал с двух сторон баррикад и понимаю каждую
Ну если забегать вперед, то корень всего некая фундаментальная ошибка атрибуции: если люди ведут себя не так, как мы ожидаем (или вели бы себя сами), то мы считаем, что это проблема с характером людей (а в жизни почти всегда это внешние факторы)
Было исследование, в которым людям надо было сходить прочитать лекцию. Одной части говорили, что они опаздывают, а другой, что у них еще есть время.
По дороге был человек, которому явно нужна была помощь.
Как вы думаете, сколько % в каждой группе остановились помочь?
Раз остается 5 минут, то поделюсь правильным ответом: 10% и 60% соответственно
Исследование: greatergood.berkeley.edu/images/uploads… (страница 105)
А кейс взял отсюда: Richard Nisbett "Mindware"
Но в книге так же утверждалось, что когда другим студентам рассказали про то, что кто-то помог, а кто-то не помог страдающему человеку, то большинство студентов сразу оценило характер людей из эксперимента, как добрый/открытый и злой/эгоист
И такое происходит со всеми из нас, если что-то работает не так как мы хотим: бизнес не выделяет ресурсы на улучшение кода, хотя разработчики просили или разработчики не укладываются в срок (или делают не так, как было написано в PRD)
Но я бы выделил основной спектр проблем:
Разработчики чувствуют давление со стороны бизнеса (давят по срокам, возникают неожиданные созвоны, жалобы на мелкие баги, рабочие сообщения по вечерам)
Бизнес получает не то, что ожидает. Например, часть фичи реализована не так, как ожидалось.
Или сроки сдвинулись, или какой-то критический баг нашелся и большая часть пользователей страдает от него.
Бизнесу кажется, что разработчики должны уведомлять заранее, если сроки сдвигаются. Если фичу нужно доработать, то разработчик тоже запросит срок заранее. А PRD (en.wikipedia.org/wiki/Product_r…) читается очень внимательно.
Но со стороны разработки тут сразу 3 проблемы:
Разработчики оценивают задачи без учета, следующий факторов:
- Нужен срочный созвон
- Тут что-то сломалось, посмотри
- А посмотри, как у нас в коде как это трекается
- А это обычный дейли
- А сегодня разработчик идет к зубному
И т.д.
Можно, конечно, просить везде приписывать x1.5 (и опытные разработчики, переодически, так делают), но тогда часто будет оверестимейты, а разработчики будут смотреть видосы с котиками из-за низкой нагрузки
Лучшим решением данной проблемы будет:
Резервирование дополнительного времени в спринте на тех. долг и некритические баги. Если разработчики уложатся в срок, то они смогут этим заняться, а если нет, то у вас будет резервное время и никто не будет лишний раз нервничать
Второй проблемой являются баги. Оно и понятно, баги на клиенте, баги в аналитике, баги на бекенде и т.п. – это баги разного рода, разной частоты, да и понятие бага растяжимое, поэтому бизнес может супер по-разному реагировать на появляющиеся баги.
Одно можно точно сказать, баги будут всегда, даже если вы Badoo или Facebook и у вас небольшая фича может пару месяцев разрабатываться.
Баги можно минимизировать, вводя разные виды обеспечения качества (тесты, наем QA, прописанный релизный цикл), но ценник растет экспоненциально
Поэтому важно думать прагматично, если вы стартап и у вас падает у 0.5% юзеров (но у вас всего 400 DAU), не стоит заставлять разработчиков бежать и править все в 4 ночи. 2 падения за ночь не стоят того, что разработчик задумается искать новое место работы или выработает иммунитет
Большинство багов (даже если CEO кричит, как он опозорился на встрече, показывая приложения) стоит отправлять на ту прекрасную доску, которая позволяет тратить резервное время в конце спринта (или набора фич, если у вас другой стиль работы).
В целом проблему паники со стороны фаундеров я встречал очень часто (не реже слышал про нее от знакомых), как мне кажется, характер людей из тех. сферы слишком мягкий, чтобы противостоять этим паникам и контролировать процессы, поэтому именно продуктологу стоит брать удар на себя
Теперь про некачественное чтение PRD разработчиками: есть еще одно когнитивное искажение (не помню как зовут зверя), когда мы что-то создаем (продакт пишет PRD), нам кажется, что все должны внимательно это изучить (ну как, мы же потратили свое время)
Но это, конечно же, булщит
Синьер разработчики еще могут позволить это делать (в угоду скорости разработки, конечно же), а вот остальные, скорей всего, буду опираться на дизайн, а PRD просто пробегут глазами (особенно если там много букаф)
Примите и смиритесь с этим
Поэтому советую следовать следующим двум правилам:
Валидируйте дизайн очень внимательно, он должен отображать весь PRD (например, если текст может быть в несколько строк, не одобряйте дизайн, где во всех ячейках однострочный текст или если в дизайне нет zero-состояний)
Я пришел из мобилки и в какой-то момент эту сферу захватили подписки, на мой взгляд это даже своего рода легальный обман Вот вам головоломка: если сильно не вчитываться в комментарии, то какое приложение на видео? https://t.co/gIVRilsdhu
Про подписки:
twitter.com/produnderhood/…
Тут образовался довольно интересный тред В целом кажется все логично, надо финансировать разработку, считать юнит экономику и вообще хорошие ребята не положат себе лишние деньги в карман Но как всегда есть свои нюансы... twitter.com/HappyVlad/stat…
Про то, почему хаки влияют на всю индустрию
twitter.com/produnderhood/…
Мой любимый кейс к этой теме: донорство органов twitter.com/Truskova/statu… https://t.co/A9X9IU0rKt
Про то, почему юзеры не "сами дураки":
twitter.com/produnderhood/…
Сегодня будем обсуждать майндсет: продуктовый vs маркетинговый Вброшу такой видос из интервью с Джобсом https://t.co/hTlGiwj8If
Про майндсет (продуктовый vs маркетинговый):
twitter.com/produnderhood/…
Сегодня мы обсудим взаимодействие бизнес и тех. команд в стартапах (в крупных компаниях, обычно, все уже выстроено) Для меня последние полгода это самая большая боль, но у меня есть плюс: я побывал с двух сторон баррикад и понимаю каждую https://t.co/YuIjmiOMrv
Про конфликт бизнеса и тех. команды:
twitter.com/produnderhood/…
Не играйте в Толстого (не того, о ком вы подумали) и не пишите лонгриды в PRD: только важное и по-делу, в идеале выделяйте жирным важные детали и разделяйте на пункты логические компоненты (завтра я буду про это говорить)
Четверг
Сегодня поговорим про наши продуктовые процессы
У нас команда небольшая (в технической 9 человек + фрилансеры), и всех инструментов, про которые я расскажу сегодня, нам вполне хватает, чтобы искать свой рынок, решать задачи менеджмента и растить метрики
Вот самые основные:
@produnderhood супер-актуально! Будет здорово, если напишете как начинающему продакту договариваться строить с командой процессы и как мотивировать соблюдать новые созданные правила.
Про мотивацию, у меня есть веселая история. Когда мы только начинали и нас было 5 человек (из которых 2 фаундера), то общение было в WhatsApp/Telegram, что было очень неудобно.
Зарегал Slack, но все продолжали писать в старых мессенджерах. twitter.com/ameri2nhood/st…
В итоге просто сказал, что отвечаю на все вопросы только в Slack (и попросил разработчика сделать так же).
Уже через неделю все переписывались только там)
Начнем с самого важного: флоу выстраивания разработки.
Если разбить на этапы:
Что вообще нужно (родмап)
Что понадобится ближайшее время (планирование)
Подготовка и одобрение материалов: PRD, дизайн
Передача всего этого в разработку
Тест и релиз
Анализ
Начнем с самого важного: флоу выстраивания разработки. Если разбить на этапы: Что вообще нужно (родмап) Что понадобится ближайшее время (планирование) Подготовка и одобрение материалов: PRD, дизайн Передача всего этого в разработку Тест и релиз Анализ
Для формирования родмапа вам в целом не нужны сторонние инструменты, но хорошо сделать следующие вещи:
- Собирать табличку с конкурентами (в Notion или Google Sheets), в зависимости от их отношения к нам мы моторим следующие вещи: twitter.com/produnderhood/…
Размер их команды, инвесторы, инвестиции, фаундеры (это позволяет понимать роль конкурентов)
Сколько загрузок в месяц (у нас нет возможности платить за дорогие сервисы, поэтому раз в месяц смотрим тут: sensortower.com)
Какой функционал они выставляют напоказ (догадка о ядре продукта)
Обсуждения, что у них менялось последнее время
Так же у нас есть отдельная таблица, где мы смотрим, какие пользовательские юзкейсы есть у нас и наших конкурентов
Это позволяет следить за их вектором и подсматривать какой-то функционал у конкурентов. Пока вы ищете свою нишу, копирование успешных решений позволяет быстрее понимать, а что же подойдет вашим юзерам
- Вторым важным моментом в составлении родмапа являются ваши ключевые метрики: для нас (как и большинства) это retention, но есть очень много листьев, которые влияют на него
P.S. Единственной доской, что мы сделали в Miro, является доска наших метрик
Вот пример куска:
Мы целимся в увеличения ретеншена, на него влияют:
Работоспособность, интерес пользователей и т.д.
На интерес влияет:
Разнообразие, возможность найти контент, его качество и т.д.
На разнообразие: кол-во нового контента, ретеншен инфлюенсеров и т.д.
На конце каждой ветки есть ссылка на соответствующую диаграмму в Amplitude (а для каждого направления есть отдельные дашборды)
Повышение главной метрики идет за счет работы с каждым из узлов, отсюда и задача придумать фичи продукта, которые повысят метрики одного из этих узлов
Еще одним источником вдохновения являются сами пользователи:
Мы опрашиваем наших амбассадоров и лояльных пользователей
Раз в 2 месяца мы проводим UX интервью со случайными людьми, которые еще не пользовались нашим приложением
Мы ищем аномалии в метриках
Как результат, раз в 1.5 месяца (ну иногда и динамично) мы выбираем себе направление, чтобы мы хотели добавить в продукт. Выбор базируется на:
Решениях конкурентов
Креатива (придумываем сами) направленного на определенные метрики
Фидбека от пользователей
После этого идет оценка сложности реализации каждой функции, идеи как сделать ее как можно быстрее и т.п.
С этого момента у нас есть план на ближайшее время, который разделен на спринты разной длинны (от 1 до 2.5 недель)
По окончанию каждого спринта надо выпускать новую версию
Сегодня поговорим про наши продуктовые процессы У нас команда небольшая (в технической 9 человек + фрилансеры), и всех инструментов, про которые я расскажу сегодня, нам вполне хватает, чтобы искать свой рынок, решать задачи менеджмента и растить метрики Вот самые основные: https://t.co/lM5nui1rCy
Про продуктовые процессы:
twitter.com/produnderhood/…
Начнем с самого важного: флоу выстраивания разработки. Если разбить на этапы: Что вообще нужно (родмап) Что понадобится ближайшее время (планирование) Подготовка и одобрение материалов: PRD, дизайн Передача всего этого в разработку Тест и релиз Анализ
После того, как у нас есть понимание, что будет в спринтах, мы делаем корректировки:
Скажем мы планируем спринт 2 недели, у нас есть 30 MD (man days) на iOS и столько же на Backend из них 20 на фичи twitter.com/produnderhood/…
После того, как у нас есть понимание, что будет в спринтах, мы делаем корректировки: Скажем мы планируем спринт 2 недели, у нас есть 30 MD (man days) на iOS и столько же на Backend из них 20 на фичи twitter.com/produnderhood/…
Про планирование на ближайшее время:
twitter.com/produnderhood/…
Для формирования родмапа вам в целом не нужны сторонние инструменты, но хорошо сделать следующие вещи: - Собирать табличку с конкурентами (в Notion или Google Sheets), в зависимости от их отношения к нам мы моторим следующие вещи: twitter.com/produnderhood/…
Про родмап:
twitter.com/produnderhood/…
Пытаемся понять, что нам важно сделать быстрее всего из родмапа (обычно приоритизация приходит напрямую от СЕО)
Думаем как можно внедрить эти фичи быстрее всего (у нас была задача, которую оценивали в 25 MD, а мы придумали как проверить гипотезу за 3 MD, расскажу на днях
Распределяем по свободным слотам (конечно же все хотелки не влезут в 1 спринт)
Выбираем, что и куда подвинуть из задач
Важно сказать, что в результате такой активности получается 3-5 спринтов
@zagwalker Нас вполне устраивает, удобно, что формируется в формате списка (слышал Trello месяц назад что-то такое ввели), нет перегруженных компонентов Ведем спринты, как отдельные Project'ы, каждая команда применяет на себя фильтры и видит что и к какому дню надо сделать в текущем спринте https://t.co/D5XFg1NHXm
Для такой активности не требуется определенных инструментов, мы ведем все подсчеты в Google Sheets (довольно быстро и удобно), а переносим получившиеся задачи в отдельные Project в Asana
Я показал пример тут:
twitter.com/produnderhood/…
Вот пример планирования спринтов
Пятница
Начнем с самого важного: флоу выстраивания разработки. Если разбить на этапы: Что вообще нужно (родмап) Что понадобится ближайшее время (планирование) Подготовка и одобрение материалов: PRD, дизайн Передача всего этого в разработку Тест и релиз Анализ
Сегодня поговорим одну из самых важных частей – подготовка материалов)
Написание PRD, обсуждения, подготовка аналитики, дизайн и все такое twitter.com/produnderhood/…
Подготовка фичи проходит следующий цикл:
Описание идеи
Созвон, обсуждение и утверждение
Описание формального PRD и сверка с разработкой
Подготовка и утверждение дизайна
Дополнение PRD аналитикой
Отправка в реализацию
У нас в Notion есть 4 главных раздела для работы с фичами:
В целом карта приложения, чтобы ориентироваться (она у нас уже устарела, но надо будет обновить, если будут новые участники)
Таблица фич
Драфты фич
Сложные фичи связанные исключительно с аналитикой
Во время первого этапа мы идем в Features Draft и кратко описываем, как мы видим фичи, буквально драфт.
Можно и сплошным текстом можно и табличками, как кому удобно.
Формат не важен, т.к. все это будет рассказываться во время созвона при обсуждении фичи.
Созвоны у нас проходят следующей командой:
Я (выступаю в роли продуктового менеджера и делюсь инженерным опытом)
Project Manager (который берет на себя часть функций продукт менеджера)
Один из кофаундеров, который отвечает за тех. направление
Иногда и СЕО приходит
После обсуждения и утверждения, начинается формальная часть, заполнение PRD.
Для фич мы используем таблицу в Notion, вот пример с одним из view (об этом я скажу чуть позже):
У нас следующие колонки:
Название фичи
Ее категория (приложение, сервер, админская панель, утилитарная фича)
Типы, может быть несколько (части приложения, удобно для объединения фич в одну группу, про это напишу позже)
Статус подготовки PRD и выполнения фичи
Ответственный за фичи (к кому обращаться)
6 и 7. Ответственный за аналитику и кто реализовал (второе полезно, когда есть вопросы по отслеживанию, с ведением 7 у нас пока сложности)
Сегодня поговорим одну из самых важных частей – подготовка материалов) Написание PRD, обсуждения, подготовка аналитики, дизайн и все такое twitter.com/produnderhood/…
Про подготовку материалов (PRD, дизайн, аналитика):
P.S. В треде есть Notion
twitter.com/produnderhood/…
Теперь непосредственно создании фичи, мы используем темплейты в Notion, все это выглядит так:
Вот как выглядит экран после применения шаблона.
За основу мы взяли: atlassian.com/agile/product-…
И модернизировали под себя.
Проговорю про каждое поле отдельно:
Image: ссылка на Zeplin/Abstract, заполняются в будущем после того, как дизайнер подготовит их
Goals: кратко описывает, что хотим сделать
Key metrics: обычно для дизайнера, чтобы понять на чем делать акцент, но часто пропускается
Background and strategic fit: чтобы было понятно, почему мы делаем (например, подсмотрели у конкурента, юзеры попросили, должно повысить такую-то метрику и т.п.) полезно заполнять, в первую очередь, для самого продукта
Requirements: табличка с требованиями по фиче
У Requirements есть 4 основные колонки:
Что за компонент фичи
Его описание
Заметки (например, что длинна вода ограничена 120 символами или как ведет себя компонент)
Статус компонента (у нас 3 состояния: New, Implemented, Future)
Заметки никак не регламентируются, и у нас проблем с этим не было
Статус важен, чтобы в старых задачах, разработчик видел, что появилось нового (у компонента будет тэг New) или чтобы коллекционировать идеи, которые мы не готовы реализовывать прямо сейчас (тэг Future)
Таблциа аналитики разделена на 2 (Events и Person Properties):
В первой:
Название эвента
Поля у эвента
Описание эвента (если нужно) и описание полей
Статус реализации
P.S. Showed/Closed эвенты работают из коробки на клиентах
Вторая таблица описывает пользовательские свойства
Если вы не знаете в чем их разница от событий, то можете почитать тут: help.amplitude.com/hc/en-us/artic…
Если у задачи есть связанные с ней задачи, то мы часто делаем кросс линкинг через указывание Related tasks
Одной из топовых фич таблиц в Notion являются Views: notion.so/Intro-to-datab…
Это когда вы выводите не всю таблицу, а только определенные отфильтрованные и отсортированные критерии
Когда каждый из нас работает над каким-то набором задач, то может указать соответствующую сортировку, создать свой View и быстро обращаться к текущем задачам
После написания, PRD:
Оно проходит проверку и утверждается
Отдается дизайнеру (если надо, проходит созвон)
Дизайнер предлагает варианты, они утверждаются и добавляются в PRD
В PRD добавляется аналитика
После этого фича подготовлена
Воскресенье
Начнем с самого важного: флоу выстраивания разработки. Если разбить на этапы: Что вообще нужно (родмап) Что понадобится ближайшее время (планирование) Подготовка и одобрение материалов: PRD, дизайн Передача всего этого в разработку Тест и релиз Анализ
Сегодня я расскажу как выглядят у нас шаги 4-6 на текущем этапе развития twitter.com/produnderhood/…
Сегодня поговорим одну из самых важных частей – подготовка материалов) Написание PRD, обсуждения, подготовка аналитики, дизайн и все такое twitter.com/produnderhood/…
Я уже рассказал как идёт подготовка PRD, аналитики и дизайна: twitter.com/produnderhood/…
После все эти материалы заносятся в описания задач (в Asana), которые будут в следующем спринте для разработчиков. Мы стараемся делать так, чтобы бекенд реализовывал задачи первым twitter.com/produnderhood/…
Клиентам так удобнее (учесть, что мы используем Swagger и API запросы и модели для мобильных клиентов генерируется за счёт серверной реализации)
После распределения всех задач по разработчикам (на основе предпочтений и математики с Man Days) проходит предспринтовый созвон
Обычно это ничего не меняет, но переодически могут всплыть интересные детали от разработчиков, что заставляет поменять местами задачи (по приоритету выполнения или исполнителями)
Перед выполнением, но после чтения PRD задачи, разработчик может инициировать созвон с PM этой фичи
Предпочтительно, чтобы на созвоне присутствовали и мобильный, и бакенд разработчики.
После задача уходит в реализацию и PM забывает про задачу до последней четверти спринта.
У нас долгое время не было нужды QA, но тестирование задач было следующим:
Когда до завершения принята остаётся 3-4 дня, разрабочики готовят тестовую версию, а после бизнес команда (состоящая из 7 человек) тестируют приложение в течении нескольких часов
Плюсом такого подхода является то, что бизнес команда всегда понимает как выглядит приложение и какой в нем есть функционал (что позволяет эффективнее общаться с пользователями, помогать формировать родмэп и участвовать в цикле разработки)
Минусы следующие:
У бизнес команды нет квалификации, они часто репортят проблемы, связанные с самими платформами или не являющиеся важными для бизнеса
Тестирование выполняется в конце спринта, а значит разработчик мог уже забыть как реализовывал первую фичу (если таких 2+)
Процесс тестирования не автоматизируется
После того, как разработка перешла за определённую черту (стало больше жалоб от разработчиков), мы решили нанять QA, но пока процесс тестирования и релиза у нас остаются такими, как я описал выше
Возвращаясь к нашим процессам:
После первого цикла тестов от бизнес команды, project manager заносит баги на отдельную доску и разработчики должны их править (каждый спринт на правку багов выделяется 0.5-1 Man Day на человека)
После правок повторяется короткий цикл тестирования
Когда качество соответствует нашим ожиданиям, приложения отправляются на проверку в магазины приложений, этот процесс сложно контролировать, он может занять от пары часов до N дней, но у нас есть правило: мы не релизимся в пятницу (чтобы не решать проблемы в выходные).
После релиза новой версии (и фич), у PM есть несколько обязанностей:
Активно наблюдать за "product doesn't work" дашбордом (там собраны все метрики, которые характеризуют стабильность: конверсия в регистрацию, скорость загрузки контента, кол-во серверных ошибок и т.п.)
На всякие краши и т.п. стоят уведомления, но не все метрики можно легко отследить на аномальность.
2. Сформировать отдельный дашборд по анализу новых фич (особенно если это A/B тест), который можно будет проанализировать через 1-2 недели
Начнем с самого важного: флоу выстраивания разработки. Если разбить на этапы: Что вообще нужно (родмап) Что понадобится ближайшее время (планирование) Подготовка и одобрение материалов: PRD, дизайн Передача всего этого в разработку Тест и релиз Анализ
Организовать встречу по обсуждению результатов и метрик через какое-то время (обычно 1-2 недели)
После этого весь описанный тут цикл повторяется:
twitter.com/produnderhood/…
Сегодня я расскажу как выглядят у нас шаги 4-6 на текущем этапе развития twitter.com/produnderhood/…
4-6. Про передачу в разработку, релиз и анализ
twitter.com/produnderhood/…
На этом моя неделя подходит к концу
Спасибо, что читали, лайкали и ретвитили :)
Если есть любые вопросы – пишите, постараюсь ответить
Всем привет, на этой неделе с вами Александр Зимин. Я в прошлом мобильный разработчик, провел в карьере разработчика 7 лет. Работал от контрактов и стартапов, до крупных компаний, таких как Badoo, но почти всегда интересовался продуктовыми вещами
Напомню, что основные треды недели можно найти под этим твитом:
twitter.com/produnderhood/…
А если хотите о чем-то спросить в личку, то можно писать в телеграм: azimin
