Всем очень раннего и доброго утра. Я ничего не постил эти две недели, потому что был занят важной штукой, которую и хотел бы вам презентовать. Это Product Architecture Framework.

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

Если бы продукт был зданием, то какова могла бы быть его архитектура?! На этом вопрос я пытался ответить, пожалуй, с того самого момента, как стал продактом. Но лишь недавно все кусочки паззла собрались в одну картинку, которую я и назвал Product Architectire Framework.

Это моя третья попытка визуализировать различные аспекты продукта, выстроив из них структуру. Самую первую я совершил ещё три года назад, когда попытался скомпилировать весь свой опыт после LiveTex.

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

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

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

Также, я подготовил нормальный файл для печати фреймворка в формате а2. Вы можете свободно его печатать, вешать на стеночку возле рабочего места, вдохновляться или просто смотреть, как на мандалу.

Коллеги, добрый день. Послезавтра, в четверг, 23 августа на Product Club SPB #11 я расскажу о своём Product Architecture Framework.

Product Architecture Framework - наглядная схема архитектуры любого продукта, будь то мобильное приложение, интернет-магазин, saas-решение, оффлайн товар или услуга.

Фреймворк позволяет понять:
1) Как в целом организовать работу над продуктом.
2) Какие артефакты для управления продуктом вам нужны.
3) На какие аспекты продукта вы раньше не обращали внимание.
4) Где границы между отдельными активностями (research / product management / marketing).
5) Каким образом можно разделить управление продуктом по разным ролям.

Фреймворк будет полезен всем, кто вовлечен в работу с продуктами: продакт менеджеров и оунерам, проджект менеджерам, маркетологам, разработчикам, системным и бизнес-аналитикам, информационным архитекторам, UI/UX проектировщикам, дизайнерам, руководителям отделов и стартаперам.

Всем, кто хочет понимать, что же из себя действительно представляет продукт.

Участие бесплатное, регистрация обязательна, проходит в офисе Selectel в Питере https://product-managers-spb.timepad.ru/event/793333/

Не волнуйтесь, запись будет.

https://docs.google.com/presentation/d/1Rrq5ijwa6onMvr4Wr1QHdnHJ3ZGr5oqrX-lg3GgvhJo/edit?usp=drivesdk презентация с выступления. Запись была сделана, но будет чуть позже.

Подъехала запись выступления про Product Architecture Framework https://youtu.be/TKNBdv1Sh44

Хочу выразить благодарность Татьяне Гороховский, организатору Product Club SPb, за возможность рассказать, ребятам из Selectel за предоставление площадки, Алексею Васильеву за съёмку и более ста коллегам за присутствие, вопросы и важную обратную связь, которую я сейчас обрабатываю.

Всем здрасте. За время, прошедшее с момента выступления и рассказа про фреймворк, благодаря вам я собрал достаточное количество обратной связи об этой поделке. Я еще раз здраво посмотрел на фреймворк и вот какие мысли у меня возникли:

Во-первых, это вообще не фреймворк. Пока даже близко не валялся. Не хватает процессов, не хватает унифицированой компонентной базы и терминологии. Кто-то назвал это аналогом BABOK, но до этого тоже весьма рано. К тому же, аналог бабука для продактов вроде как есть http://productmanagementbook.com/, только вот содержание его непонятно, ибо стоит овердохрена.

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

В-третьих, не хватает примеров. Многим очень помогало описание того, как отдельные части фреймворка реализованы у нас в LAF24, однако, такое описание есть не для всего. Поэтому, чтобы фреймворк был действительно полезным, нужно будет добавлять описание кейсов.

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

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

В-пятых, не хватает ссылок на описание рекомендуемых моделей. Конечно же, я планировал в дальнейшем ссылаться на product notes, но сейчас поиск моделей вызвали трудности у некоторых людей (а точнее как их конкретно применять).

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

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

Хочу рассказать о сервисе UXfeedback. Ребята предлагают инструменты для сбора обратной связи от пользователей, которые помогают улучшать ваши продукт. Несмотря на название, сервис предназначен не только для UX-специалистов, которые замеряют эффективность интерфейсов, но и для продактов, маркетологов и специалистов отдела контроля качества, которым важно получать обратную связь от клиентов по продуктам, услугам или товарам.

До 30 сентября у ребят проходит бесплатный бета-тест, на который можно записаться тут https://uxfeedback.ru/. В рамках теста, или даже крупных пилотных проектов, можно адаптировать сервис под вид вашего продукта, в чём вам помогут. Коллегам важно создавать свой продукт вместе с бизнесом, поэтому им важна обратная связь от тех, кто согласился на тест.

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

Оффтоп, но хочу поделиться. Пару недель назад вернулся с Алтая, где ходил в поход к подножию Белухи. Походник из меня, конечно, не очень, но для остановки процессора этот способ весьма годный.

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

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

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

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

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

Ну, поехали

41. Morphological Analysis #ProductNotes

42. Stakeholders Matrix #ProductNotes

Великолепное описание того, как Microsoft изменил свой стратегический фокус http://mobile-review.com/articles/2018/windows.shtml

Хорошая новость: я определился с платформой для размещения фреймворка. Да, это Тильда.

А ещё я пересобрал его заново. Стало логичнее и менее противоречиво.

Теперь у фреймворка есть отдельный сайт http://productframework.tilda.ws

Я полностью его пересобрал на основании обратной связи логики "от процессов". Постепенно валидирую его другими моделями: пока противоречий не возникает. Сейчас нужно сделать более строгие, лаконичные и понятные формулировки ко всем пунктам, добавить описание ролей. На этом текущая итерация будет завершена и версия 1.1 станет релизной.

Впереди ещё много работы. Я создал отдельную страничку, на которой будет информация по процессу работы над ним. http://productframework.tilda.ws/versions

Да, и отображение для мобильных пока не работает - нужно адаптировать каркас под несколько вариантов разрешений. Так что пока только для десктопа и планшетов. Остальные - на выходных.

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

Та встреча мне особо хорошо запомнилась, т.к. кардинально отличалась от того пресейла, который мы обычно проводили в компании LiveTex, когда ходили к потенциальным крупным клиентам. Во-первых, ребята предлагали IT-продукт, но стиль переговоров был больше похож на стрелку из 90-ых. Ребята были очень уверенны в себе, звучали фразы вида "если сейчас не подпишем договор, завтра подключение может стоить уже в десять раз дороже, а потом вообще потеряете рынок". На просьбу прислать презентацию, чтобы ознакомиться хотя бы с концепцией продукта (самого то его ещё не было), нам было отказано. Естественно, мы расстались с ними так ни о чем и не договорившись. Тогда я предрек, что с такой политикой, ни одной крупной компании они не добавят в свой агрегатор. Да и сама бизнес-модели социальной сети как то не сочетается с моделью агрегатора автосервисов. Соединить это органично они не смогут, да и не зачем. Какую проблему это решает?

Недавно мы снова общались с этой компанией, но уже в LAF24. Ребята сделали продукт, он даже работает. Правда вместо заявленных "мы быстро сделаем mvp в течение шести месяцев", работающая версия была только спустя полтора года. Они даже подключили несколько сотен автосервисов, да и вообще стиль общения был совершенно другой. Вместо "брать на понт" - позиция прозрачности. Правда, мы уже общались не по поводу подключения наших автосервисов, а по теме покупки нами самого продукта.

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

В этой истории много соли. Во-первых, продавать ожидания клиентам нужно не только, когда у тебя стальные яйца, но нет продукта, но и не разводя клиента, как лоха, требуя денег просто за подключение без гарантии генерировать нужное количество лидов (в итоге все автосервисы брали подключены к системе бесплатно, а вместо модели "плата за подключение" стали использовать cost per order). Во-вторых первую версию продукта получается сделать в срок только тогда, когда вы реально понимаете, как управлять проектом и отсекать из продукта все лишнее. В-третьих, наличие продукта не гарантирует продажи, если маркетинг привлечения не только не протестирован, но и просто не продуман. В-четвёртых, нужно чётко видеть свою бизнес-модель (да блин просто шаблон Остервальдера хотя бы построить) и не пытаться в продукт впихнуть несколько. Умные компании наоборот идут в сторону разделения продукта на несколько (vk, fb, foursquare).

Это грустно, но в бизнесе больше историй неуспеха, чем успеха. Любой успех - это большой кусок удачи (нужное время / место / слова / связи / ситуация и т.д.) и чуть меньший воли и компетенций тех, кто создаёт этот проект. Ребята прошли большой путь и многое узнали о мире продуктов и том, с какими трудностями сталкиваешься в процессе их создания. Возможно, если бы они были из IT, или в их команде был человек с продуктовыми навыками, эта история не звучала бы так печально.

"Если продакт не отвечает за деньги, то он не продакт, а проджект (т.е. просто отвечает за сроки доставки фич).

Деньги это валидация ценности. Пользователь сталкивается с продуктом, и он платит за велью или нет (это показатель того, есть ли велью у продукта). Не очень точная, но очень честная.

Чем больше ценности ты даешь, тем лучше конверсия, тем выше ARPU”.

Недавно Аня в @proproduct опубликовала интересное интервью с Ильей Красинским, сильно советую посмотреть: https://youtu.be/w_TJSWxY5vw
Если нет времени - ниже в вольной форме еще несколько заметок и цитат:

У людей нет метрик, у них есть сценарии. За последние три тысячи лет они не сильно поменялись. Они что-то ищут, появляется триггер, который запускает какой-то сценарий, который они хотят выполнить.

У нас нет контроля над кошельком клиента. Мы работаем над продуктовыми метриками. Мы не работаем с теми, кто купил. Мы больше работаем над теми людьми, кто НЕ купил - чтоб они купили. Пытаемся влиять на их поведение косвенно, чтоб в итоге купили.

“Помнишь, как появились в Яндексе продакты? Было много проджектов, потом вдруг стало модным быть продактом. Потому сначала все стали продакт овнерами, это пришло из скрима, а потом на линкедине поменяли себе это на продакт менеджеров. Теперь ты продакт менеджер, будешь отвечать за сроки, говорили они”.

Когда продакт не отвечает за реальные метрики использования, за деньги, он начинает галлюцинировать - появляется огромный бэклог, олицетворяющей собой огромное количество непроверенных гипотез, проверка которых в сумме (с учетом стоимости команд разработки) будет стоить компании миллионы.

Когда же продакт отвечает за деньги, он начинает думать, как ему максимально дешево проверить гипотезу, чтоб тратить время разработки на фичи с максимальной вероятностью высокого КПД. Интервью, тесты.

Если ты работаешь через проверку гипотез, ты 50% времени тратишь на то чтоб родить годную для проверки боем гипотезу, а команда тем временем имеет время закрыть техдолг. Потом ты приходишь и говоришь “давайте вот это сделаем, это все равно конечно придется переделывать потом, но мы по крайней мере сделаем это дешево. И мы не пилим весь наш архипелаг, и если не сработало - выкинули”.

Задавать себе вопрос: Где точки роста в этой компании?

О дата сайенс. Люди, которые сидят с данными, часто не способны принимать решения. Стать хорошим продуктовым аналитиком очень сложно и дорого. Как только такой человек начинает разбираться в бизнесе, он становится продакт менеджером 🙂

Churn rate - метрика не actionable. Ты на нее смотришь и плачешь.

Аналитика головного мозга. “Как-то я сидел высчитывал кривую эластичности спроса. Провел кучу тестов, нашел математически правильные цифры. Через три месяца пришел собственник и сказал: давай повысим цены в два раза. Я ему час читал лекцию о том, как это нельзя делать, но потом сдался. Мы повысили цены в два раза, и увеличили доход в два раза. Теперь я сторонник дешевых экспериментов. Разведка боем”.

Важно, чтоб команды параллельно занимались и кратным ростом (основные фичи, точки роста), и локальными оптимизациями (напр, команда маркетинга тюнит регистрацию).

Точки роста обожают смещаться в зону некомпетентности команды.

Дашборды показывают цифры, которые ты и так знаешь, а проблемы скапливаются в тех цифрах, о которых ты не подозреваешь.

Ты не можешь три метрики считать, а две не считать. Тебе нужна целостная система метрик, чтоб ставить диагностику.

Людям нравятся красивые штучки в UI, которые ничего на самом деле не стоят в разработке - картинка, простая анимация. "Я стараюсь в каждую итерацию одну такую штучку добавлять”.

С какого-то момента больше нельзя учиться по книгам, потому что для тебя книги еще не написаны. Чтобы развиваться дальше, можно преподавать самому, заниматься консалтингом, работать с сильными людьми. Так тренироваться.

На прошлой неделе на очередном собрании Product Club SPb обсуждали, у кого какие кейсы были product discovery и делали выводы. Собрал свои заметки здесь https://www.notion.so/Product-Discovery-a7402d9ed75f456884814377ef80d609 Может, кому будет полезно.