Классное интервью с Андреем Стыскиным, который был главой Яндекс Поиска, а теперь — директор в Амазоне (плюс-минус 100-150 человек в подчинении).

Он так рассказывает про культуру Амазона, что я обливаюсь ностальгическими слезами и хочу обратно. Его опыт соответствует моему, все по делу говорит. I approve.

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

Слушаю и тащусь.

Ещё один классный подкаст — интервью с Борисом Зарьковым, основателем ресторанов The White Rabbit Family. Из его ресторанов я несколько раз был в Горыныче. Там классные бутеры, пицца и сервис.

В интервью Зарьков говорит про текучку кадров. Когда высокая текучка, ресторан постоянно недоукомплектован, люди недообучены и сразу падает качество сервиса.

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

В ресторанах текучка до 100% в год. Представьте себе полную смену команды за 12 месяцев… 🤯

В худшие годы у них была текучка 300%. Три раза сменяется состав людей 🤯 🤯 🤯

Он дрючит своих управленцев за высокую текучку и лишает их бонусов.

ДОКУМЕНТ PRFAQ В АМАЗОНЕ ч.1: 5 вопросов

Судя по комментариям под постом про интервью со Стыскиным, тема документов в Амазоне интересна.

Любой продукт в Амазоне начинается с PR/FAQ:

1) Одностраничного пресс-релиза как будто продукт уже запускается
2) 5-страничного FAQ с гипотетическими вопросами пользователей и реальными вопросами внутренних стейкхолдеров
3) Неограниченного количества приложений с данными, исследованиями, скриншотами и т.п.

Работа над PR/FAQ начинается с пяти вопросов (5 questions). Ответив на самые важные 5 вопросов, у тебя будет вся информация для написания PRFAQ. Письмо пресс-релиза становится относительно механическим процессом.

Итак, пять вопросов:

1. Who is your customer?

Кто твой пользователь/кастомер? Здесь мы описываем аватар пользователя. Не гипотетический, а основанный на исследованиях, метриках и касдеве.

2. What is the customer problem or opportunity?

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

3. What is the most important customer benefit?

Какая у пользователя будет выгода от использования того, что мы предлагаем? Как она измеряется?

4. How do you know what your customer needs or wants?

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

5. What does the experience look like?

Описываем UX (можно с прототипами и скринами), как это интегрируется в общую экосистему, стоимость и т.п. Всё, что нужно понимать о том, как это будет работать, но не уходя в сильно глубокие дебри.

Обратите внимание, что тут нет ничего про то, какая в этом выгода для нас. Это важно. Мы отталкиваемся от пользователя, а потом уже анализируем есть ли в этом экономический смысл. Мы работаем не от "как заработать бабла?" а от "какую ценность принести? бабло приложится..."

—

Ответы мы пишем полными предложениями.

Our customers are mid-level product managers who are stuck in their roles and don't know how to move forward in their careers. They typically work in companies with ~500 employees. Geographically 40% of them are concentrated on the West Coast, 30% on the East Coast and 30% are spread throughout the country. Their median income is $120k/year. There are approximately 40,000 of them in the United States. Their average age is 30, 60% of them are male, and 25% of them have children.

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

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

👉🏻 Вторая часть

@ilyabezdelev_blog #продактменеджмент #бигтех #amazon

По четвертому пункту — он важен не только для того, чтобы доказать вышестоящему руководству и разработке, что это стоит делать. Это нужно в том числе для тебя самого. Чтобы ТЫ был уверен в своём предложении.

Если ты будешь уверен, ты сможешь это продать кому угодно. Если ты сам не уверен, то почему тебе должны выделить под это ресурсы?

Мне только что рассказали про прикольную практику — приглашать в середине спринта на встречу с командой (продакт + разработка + дизайн) пользователей, которым можно показать промежуточный прогресс по фиче.

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

Продакт, который мне это рассказал, просто связывался с существующими пользователями и приглашал их. Они соглашались и приходили.

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

А что так можно было?

Кого-нибудь ещё бесит новый интерфейс в фотках в iOS 18? Стало элегантнее, но пздц неудобно. Визуальный дизайн в ущерб UX.

ДОКУМЕНТ PRFAQ В АМАЗОНЕ ч.2: Пресс-релиз

(первый пост про PRFAQ — пять вопросов — тут)

Когда написали пять вопросов, отревьювили их неформально с коллегами (другими продактами, разработкой, менеджером), можно приступать к следующему этапу — написанию пресс-релиза и FAQ (отсюда название PRFAQ, который также пишут как PR/FAQ).

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

У пресс-релиза есть определённая структура и ограничения.

Начнём с ограничений: строго одна страница, удобочитаемый шрифт (Таймс 12пт), адекватные поля. Новички растягивают пресс-релизы на полторы-две страницы или пишут 8-м шрифтом без полей, за что получают по голове при первом же ревью и уходят переделывать.

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

Структурно пресс-релизы всегда следуют одному и тому же шаблону во всей компании. Без исключений.

Пресс-релиз состоит из заголовка и 7 параграфов:

Заголовок

Одно-полтора предложения, своего рода elevator pitch, в котором коротко и ясно описывается ключевая ценность.

Never miss an important infrastructure alert. Get all your AWS notifications in Slack with AWS Chatbot.

1) Саммари

Основной текст пресс-релиза начинается с параграфа, где описывается что продукт делает и для кого он.

Этот параграф, написанный мною, был опубликован в реальном пресс-релизе, когда мы запустили AWS Chatbot. Только, как мне помнится, во внутреннем пресс-релизе вместо "you" мы использовали "DevOps teams."

AWS Chatbot is a new service that makes it easy to set up ChatOps for AWS in your Amazon Chime chat rooms or Slack channels. AWS Chatbot provides an interactive agent that enables you to monitor and interact with your AWS resources from team chat rooms. You can receive alerts and execute commands to return diagnostic information so your team can collaborate and respond to events faster.

Обратите внимание, что мы не пытаемся пустить пыль в глаза. Всё по делу. Почти без прилагательных.

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

2) Пользовательская проблема

Параграф проблемы — это краткая выдержка второго вопроса, о котором я писал в посте про 5 вопросов. Он формулируется по принципу "раньше был полный пздц, потому что..." только опять же всё по делу.

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

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

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

3) Решение проблемы

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

Продолжение 👇🏻

Начало 👆🏻

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

А теперь когда у них есть чатбот, девопсы узнаЮт об упавшей инфраструктуре в считанные секунды и могут в общем чате запросить у бота больше инфы, логи, графики и коллективно всё пофиксить за 5 минут отправив боту команду.

Можно ещё использовать "например", чтобы объяснить сложную концепцию на пальцах.

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

4) Цитата от руководителя внутри компании

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

По факту продакт менеджер придумывает цитату сам, пишет имя своего VP, а потом на ревью с самим VP, вице-президент может подкорректировать "свои" слова.

5) Как начать пользоваться

Здесь мы в одном параграфе описываем UX и как легко начать пользоваться.

Чтобы начать пользоваться AWS Chatbot, зайдите в консоль AWS, нажмите кнопку, пройдите аутентификацию в Slack, выберите канал куда слать уведомления и выберите что слать.

Казалось бы зачем описывать UX словами, если его можно показать на картинке? Если ты описываешь UX словами и кажется, что получается слишком сложно, значит это слишком сложно. Если не можешь объяснить на пальцах без визуала, нужно доработать.

6) Цитата пользователя

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

У нас в чатботе сначала была выдуманная цитата, которую мы впоследствии заменили на цитату одного из наших бета пользователей (компании из Fortune 100).

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

7) CTA — позыв к действию

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

—

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

Пресс-релиз никогда не презентуется сам по себе. Только в связке с FAQ. О них — в следующем посте.

Если было полезно, дайте какую-то обратную связь. Огонёк поставьте хотя бы.

👉🏻 Третья часть

@ilyabezdelev_blog #продактменеджмент #amazon #бигтех

Боковым зрением прочитал это как «Gluten morgen». Было бы классное название для магазина традиционной немецкой выпечки.

ДОКУМЕНТ PRFAQ В АМАЗОНЕ ч.3: FAQ и Appendix
(первая часть, вторая часть)

Неотъемлемая часть PRFAQ — это FAQ. В сумме пресс-релиз и FAQ составляют не более 6 страниц: 1 страница пресс-релиз и 5 страниц частых вопросов и ответов.

FAQ — это моя любимая часть процесса. Это просто список из 100500 вопросов с короткими ответами. Вопрос-ответ, вопрос-ответ. Каждый ответ обычно не больше абзаца.

FAQ делится на две секции: вопросы пользователей и вопросы стейкхолдеров.

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

Сколько он стоит? Как мигрировать с другого приложения? Возвращаются ли деньги при отмене подписки? Какие форматы данных поддерживаются?

И так две-три страницы сплошных вопросов. Любой вопрос, который возникнет — пишем сюда и отвечаем.

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

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

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

На некоторые вопросы ответы могут быть очень длинными. Например, нужно приложить таблицу с моделью P&L. В таких случаях в ответе просто ссылка на "приложение Х", которое приложено в этом же документе.

Приложения (Appendix) могут быть любой длиной. На моём опыте их страниц 20-30. Там разного рода расчеты ТАМ, скрины дизайна, P&L, детальное саммари касдевов и т.п.

Всё это — PR, FAQ & Appendix — в одном файле, который можно распечатать или переслать, не теряя важную информацию.

Подытожим:

— Пресс-релиз описывает проблему пользователя и её решение. Он про ценность.

— FAQ про то, чтобы всеобъемлюще описать стоимость, функционал, интеграции, стратегию выхода на рынок и т.п. в сжатом формате.

— Appendix про то, чтобы доказать, что проблема есть, показать ценность и предоставить детали для всех цифр в документе.

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

👉🏻 Четвёртая часть

@ilyabezdelev_blog #продактменеджмент #бигтех #amazon

Слушаю интервью с Дэвидом Гоггинсом, мега-бегуном, бывшим морским котиком и пожарником.

1️⃣ Зашла мысль о том, что для дисциплины нужны условия.

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

Всегда под ногами будут путаться дети, жены/мужья, холодильник, видосики в ютубе и игры.

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

2️⃣ «Дисциплина ест мотивацию на завтрак» — это перефразирование знаменитой фразы Питера Друкера (культура ест стратегию на завтрак).

Мотивация — это скоропортящийся продукт. Она тухнет. Дисциплина нет.

3️⃣ Каждую секунду ты принимаешь решение идти дальше или нет. Слабость в эту секунду => годы сожалений.

Классное интервью. Я вчера послушал половину, пока бегал в 9 градусов по Питеру. Пробежал больше, чем когда-либо (почти 5 км в темпе 7,5). Сегодня начал день с того, что «съел лягушку» через силу и сделал то, на что у меня обычно уходит день, за 2 часа. При этом ещё успел помедитировать (обычно у меня не хватает на это времени).

Когда подходишь к жизни из позиции дисциплины и контроля, получается неполучаемое.

Я потерял хватку в ковид. Сильно расслабился, ушел в духовное. Давно уже хочу «вернуться в строй», но не хватало Гоггинса, который накричал на меня вчера в ухо на подкасте и дал заряд для того, чтобы собраться.

На том же подкасте послушал интервью с ультра-правым журналистом Беном Шапиро.

Там есть сегмент, где они обсуждают личности типа А (мега-ачиверы) и типа Б (диванная картошка). Первые не умеют отдыхать, вторые не умеют работать.

Выбирая из двух, тип А все-таки в большем профите по жизни.

Лайфхак от Тима Ферриса — make before managing. Создавай перед тем как «управлять».

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

Начинать утро с того, чтобы написать строчку кода, страницу текста для требований к продукту, запостить что-нибудь полезное в блог, сделать анализ данных. Сделать что-то креативное.

Принцип в том, что как только ты начинаешь отвечать на сообщения и затягиваться в мелкие неважные дела, твоя креативная эффективность идет по пзде.

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

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

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

У меня сейчас четкое ощущение, что великие достижения не могут идти только от "хочу" и "по сердцу". Иногда нужна жесткая дисциплина и "надо" через "не могу". Иначе всегда будешь в середнячках. Топ ачиверы идут дальше, где середнячки отваливаются, потому что сложно.

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

Меня всегда увлекала этимология слов. Почему ксерокс называется ксероксом? Джип джипом? Скотч скотчем?

Сегодня слушал книгу про брендинг The 22 Immutable Laws of Branding (русской версии нет, но нашел краткое содержание на русском тут) и узнал этимологию слова "факс."

Fax происходит от "facsimile" ("cs" звучит как "х"), на русском "факсимиле".

Вот как его определяет википедия:

Факси́миле (от лат. fac simile — букв. «делай подобное») — воспроизведение любого графического оригинала передающее его вполне точно, со всеми подробностями.

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

"Факс" — это скеоморфизм в названии. Не знаем как назвать — называем тем, на что это похоже. Точная передача копии документа по телефонному проводу — это факсимиле. Помните их ещё называли "телефаксами"? Makes sense!

Потом был забавный момент.

Мой старший сын любит такие приколы с языком. Я весь из себя довольный говорю ему — "знаешь от какого слова происходит слово факс?"

Он такой — "а что такое факс?" 🙈

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

Получился кайфовый момент для бати-скуфа и сына-альфы. Гиковость, походу, передается через ДНК.

Подытожу тем, что, как прирожденный гик, я рад, что родился именно в аналоговых 80х и смог застать и модемы, и факсы, и робики, и денди, и аудиокассеты, и VHS, и черно-белые телевизоры без пульта, и батин Москвич АЗЛК 1956 года без подголовников, и радио от розетки на кухне, и Napster, и CD, и DVD, и рипанье музыки с дисков с битрейтом 128 кб/с чтобы сэкономить место, и пасьянс Косынку, и бухгалтеров не знающих с какой стороны взяться за мышку.

Есть какие-то слова, чья этимология стала для вас откровением, когда вы про неё узнали?

ДОКУМЕНТ PRFAQ В АМАЗОНЕ ч.4: PRFAQ как культ внутри компании

Четвертый пост из серии про процесс “Working Backwards (from the customer)”, так же известный как PRFAQ. Рекомендую сначала прочитать первую, вторую и третью части, чтобы была полностью понятна суть.

Итак…

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

Чтобы раскрыть тему процессов, мне потребуется несколько постов. Начну с самого важного — безоговорочной стандартизации на одном процессе во всей компании, в которой работает 1,5 миллиона сотрудников.

Амазон настолько привержен PRFAQ и процессу Working Backwards, что каждый сотрудник безоговорочное принимает PRFAQ как должное.

Образованию уделяется огромное внимание. Продакт менеджеров учат писать PRFAQ в обязательном порядке после найма. Все другие функции тоже могут пройти воркшопы, так как практически любому человеку в компании, кто так или иначе связан с созданием продукта — разработчику, дизайнеру, руководителю — рано или поздно понадобится описать свою идею в PRFAQ (иначе её никто не будет рассматривать).

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

У каждой команды обязательно есть PRFAQ для их продукта. Это работает как магия.

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

Это очень эффективно.

Это позволяет людям синхронизироваться без встреч. Это позволяет новеньким въезжать в продукт за считанные дни. Это помогает моментально распространять знания внутри компании.

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

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

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

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

“Кто к нам с powerpoint-ом придёт, тот знает, где дверь” (с) народная мудрость. В Амазоне запрещены слайды.

P.S. Тема настолько интересная, что заслуживает теоретического + практического воркшопа. Детали анонсирую сегодня-завтра. Предварительно в следующую субботу 26 октября в 10:00 по Москве (онлайн).

👉🏻 Пятая часть

@ilyabezdelev_blog #amazon #продактменеджмент #бигтех

Удалил с телефона игру, от которой я потерял сон и приобрел тревогу.

Я понял на своей шкуре за последние полгода как это быть зависимым, понимающим, что у него зависимость. Как наркоман или курильщик, который каждый день собирается «бросить завтра».

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

Я, 40-летний мужик, не мог слезть с этой иглы. Даже ввалил в игру около $100, чтобы не было рекламы и (курам насмех) купить недостающие машины и (двойной насмех) золото.

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

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

Игра была источником суррогатных дофаминов и «достижений» во время сложного жизненного этапа. Она помогала отвлечься от проблем. Но меня засосало и перемололо в её жерновах.

Судя по постам на сабреддите NFS No Limits, я такой далеко не один. Эта игра разрушает жизни тех, кто не может себя контролировать… подозреваю, таких игр множество. Я просто попал на одну из тысяч.

— Всем привет. Меня зовут Илья и я геймоголик.
— Привет, Илья.

В комментах раскрыл немного тему механик игры — это только верхушка айсберга, но самое больное для меня. Места, где я залип.

Забыл ещё указать, что там в день тебе дают 5 бесплатных «сундуков» с ништяками, содержимое которых ты не знаешь. После того, как открыл сундук, через 10 минут его можно открыть снова.

Таким образом, тебя мотивируют возвращаться как минимум 5 раз в день. Когда открыл все пять, тебе дают ачивку в виде 3 золотых слитков. Соберешь 8 других ачивок (за то, что дрифтишь, летаешь, сыграл 3 гонки и т.п.) и получаешь ачивку за достижение 9 ачивок и ещё золота…

Расскажешь это не игроману, на тебя посмотрят как на дебила 🙈 но эта херня работает!

Здесь остальной коммент про механики в игре: https://t.me/c/1401899176/11291

🎓 Воркшоп: Создаём продукты по методике “Working Backwards” компании Amazon

Приглашаю продакт менеджеров, руководителей продуктовых команд, предпринимателей и всех, кому интересна разработка технологических продуктов, на 4-часовой практический воркшоп по методике Working Backwards, также известной как “PRFAQ”, которая лежит в основе каждого продукта, создаваемого в Amazon.

Ведущий воркшопа: Илья Безделев, ex-Principal Product Manager в Amazon Web Services в Сиэтле в 2015-2020гг. Продуктовый лид в AWS UX Platform, отвечающей за весь пользовательский интерфейс AWS. Запустил с нуля продукт AWS Chatbot, сервис для быстрого развёртывания виртуальных машин и внутреннюю платформу аналитики данных. Неоднократно презентовал свои PRFAQ Энди Джесси, нынешнему СЕО Amazon.

Пройдя воркшоп, вы научитесь:

1️⃣ Искать и коммуницировать ценность продукта, используя подход “5 вопросов” и написание пресс-релиза в Амазоновском стиле.

2️⃣ Убирать неопределённость для стейкхолдеров при помощи детального документа FAQ, выводящего вас из зоны комфорта.

3️⃣ Давать экологичную, но справедливую обратную связь во время ревью документов. Мы также поработаем над тем, как принимать обратную связь и внедрять её в документ.

4️⃣ Создавать процессы ревью продуктовых документов, которые вносят ясность, устраняют самодурство и приводят к более продуманным продуктам на выходе.

5️⃣ Декомпозировать PRFAQ в роадмап и артефакты для разработчиков. Мы увидим, как из “кораблей, бороздящих космическое пространство” получается реалистичный роадмап и набор задач для MVP.

Формат: Для каждого модуля я буду давать теорию и примеры из своей практики, потом мы будем вместе писать документы и их обсуждать. Будьте готовы к интерактиву со включенными камерами и двусторонними диалогами. Я планирую взять не более 25 человек, чтобы обеспечить камерный формат.

📆 Когда: Суббота, 26 октября 2024 с 10:00 до 14:00 по Москве.
📷 Где: Google Meet, запись будет доступна только участникам воркшопа.
💰 Стоимость: 5 тыс. рублей переводом на Сбер или $60 иностранной картой/PayPal.

Как вписаться?
Места закончились. Чтобы попасть на следующий воркшоп, занесите свои данные в лист ожидания. Когда наберётся достаточное количество человек для ещё одного воркшопа, я с вами свяжусь.

Если есть вопросы, пишите мне в личку @ilyabezdelev.

Когда я ушёл с работы в Гугле, Арнаб ушел из Амазона, и мы начали работать над Metacast, мы думали, что сможем запуститься за полгода и с весьма продвинутым функционалом.

Спустя 14 месяцев, наше приложение наконец-то в обоих эпп сторах. Функционал значительно урезан по сравнению с тем, как мы представляли себе скоуп в середине 2023-го.

Причины было две:

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

Когда мы выкатили v0.1, которое умело делать только "фишку" — показывать транскрипты, которые можно читать, сохранять и помечать закладками, некоторые сказали "всё классно, но я хочу слушать подкасты быстрее".

Мы добавили изменение скорости. Они сказали — “всё супер, но я хочу более точное регулирование скорости.” Мы добавили и это. Вопрос скорости наконец-таки закрыт, но на него ушло 2 недели.

Другие сказали — "всё супер, но мне нужен таймер для отхода ко сну" (над этим Арнаб работает сейчас). Или "мне нужно, чтобы работало в Android Auto" (сделали). Или "всё здорово, но как я могу добавить подписку на платный подкаст"? (на очереди) Кто-то хотел автоматическую миграцию из уже существующих приложений (мы сделали простой вариант и этого).

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

Я уже писал про table stakes — минимальный функционал для MVP на устоявшемся рынке. Мы понимали, какие table stakes на нашем рынке, но их разработка оказалась значительно сложнее, что ведёт меня ко второму пункту.

2) Всё оказалось значительно сложнее.

Мы не первый год в разработке, но даже нас удивила сложность всего, что мы делаем. На поверхности мы бы оценили всё, как “средняя сложность”. На деле всё оказалось 2х.

Сказалось то, что ни у кого из нас не было опыта мобильной разработки. Набивали шишки по ходу дела. До сих пор набиваем.

Проблемы были и на бэкенде. “Не работает подкаст Х” (проблемы были с http headers) или “не импортируется подкаст Y” (разные причины) — когда ты работаешь с 4 миллионами подкастов в открытой экосистеме с кхм-кхм “гибкими” стандартами, что-то где-то не работает с первого раза, пока не подточишь напильником.

Продолжение 👇🏻

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

Сейчас наша цель — пользователи приложения-конкурента, у которого всё плохо. Будем атаковать его как стервятники. Благо мы и так собирались делать эти фичи. Ускорим их разработку, отвечая на запрос рынка.

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

Кто захочет скачивать приложение с 4 отзывами, даже если это 5 звезд? У приложения с 50 отзывами уже больше шансов, а уж тем более у приложения с 500 отзывами. Это “социальная валидация”. Мухи на плохой мёд садиться не будут, ведь так?

Независимо от того, слушаете вы подкасты или нет, вы можете поддержать наш проект 5-звездочным рейтингом в Apple App Store и Google Play.

Спасибо ❤️