Qetzal-1UP channel. Страница 6

Они решили срезать углы и использовать свою web версию для создания форм внутри приложения. Это нормальный обмен в некоторых ситуациях (гладкость работы на скорость выпуска). Но при этом чтобы дойти до создания первой формы надо пробраться через кучу препятствий.
— Два разных баннера, которые рекламируют апп в котором я уже нахожусь
— Баннер про куки, который совсем можно убрать (и предупредить про все эти при регистрации)
— Кнопка "Создать форму" в приложении, которая открывает web страницу в которой надо нажимать "Создать форму" еще раз
— Просят слать пуш-нотификации сразу после регистрации — слишком рано

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

Хороший антипод онбоардинга у TikTok.

Увидел рекламу нового приложения JotForm Mobile Forms — там обещали, что можно формы создавать на телефоне. Я люблю смотреть разные онбоардинги, но в данном случае ребята не порадовали.

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

Со временем все разрушается.

Если сделать отличный продукт, процесс, да что угодно и перестать трогать, то со временем он испортится. Начнет немного "подгнивать". Быстрый продукт станет медленным. Хороший сервис станет посредственным. В крутой команде появляются странные (в плохом смысле) люди. Прекрасный, удобный и понятный дизайн превратится в "кухонный комбайн" из фич.

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

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

Вот неочевидный пример. Пару недель назад была история с Digital Ocean (это такой хостинг известный), когда они заблокировали аккаунт какой-то компании вместе со всеми бэкапами. Поднялся шум в Твиттере и в конце концов аккаунт разблокировали. CTO Digital Ocean написал подробный пост-мортем, который интересен сам по себе. Но меня же там привлекла вот эта часть:

> Upon recognizing his resources had been powered off, and the account locked, the customer replied to the ticket created for communication on the action. An Abuse Operations agent re-enabled the account 12 hours after the initial ticket. However, a mistake occurred and the agent did not flag the account as approved for the CPU-intensive activity that was the cause of the initial flag.

> On May 30, the same automated service then acted on the account a second time, due to the absence of a safety flag. Upon a second review by a different Abuse Operations agent (nearly 29 hours after the customer responded to the second flag), the agent failed to recognize this was a false positive, and the agent fully denied access back into the account. This action triggered the final “access denied” communication to the customer. At this point, the customer initiated the series of tweets to gain the attention of DigitalOcean.

В первый раз аккаунт заблочили. Владелец аккаунт дал объяснения, которые были обработаны только спустя 12 часов. Когда аккаунт заблочили второй раз, то задержка составила 29 часов и саппортер не разобрался, закрыв доступ насовсем.

Вдумайтесь, среднее время рассмотрения аппеляции, когда закрыли твой аккаунт (и ты в панике) — 12 часов или больше! Но так как скорее всего подавляющее число обращений к Abuse Operations у Digital Ocena это были настоящие плохие ребята (спамеры, хакеры — кого нужно закрывать и кого не жалко), а false positives мало относительно общей числа клиентов, то планка снизилась. Всем было "норм", А ЧТО ТАКОГО. В таких ситуациях нужен человек, который сможет сказать "ребята, ну это же фигня какая-то — разве это правильно? Давайте это исправим". Каждый может и должен быть таким человеком.

Невероятно отличная статья "Токсоплазма ярости": https://ru-ssc.tumblr.com/post/130203733367/ (оригинал на английском)

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

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

Почему: публичный выбор стороны в спорном деле (когда "все сложно") это лучший способ просигнализировать о принадлежности к определенной идентичности или о своих (высоких) моральных убеждениях.

Например убеждение "мучить животных нехорошо" — плохое для сигнализирования. Большинство людей с тобой будут согласны и так. Поэтому оно никак тебя не выделяет. Убеждение "надо перестать есть любые продукты животного происхождения" уже достаточно спорное, чтобы человек его произносящий смог достаточно сильно просигнализировать о своей индентичности и/или высоких и стойких моральных убеждениях ("не то что у остальных!")

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

P.P.S. Уважаемые читатели (Julia, Kostya — спасибо!) прислали немного добавлений:

— Общепринятое название этой штуки на английском языке: offboarding. По запросу product offboarding можно найти несколько статей.
— Есть чувак, который активно про эту тему рассказывает и даже написал книгу: http://www.andend.co/ Также у него много разных выложенных докладов на эту тему: http://www.andend.co/talks

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

Люди будут переставать пользоваться продуктом. Не такая простая задача сделать так, чтобы:
— Уйти с продукта было достаточно болезненно, чтобы уходили только настойчивые ("При даунгрейде у меня перестанет работать сайт, который у меня уже три года")
— Не переборщить с настойчивостивостью и блоками, чтобы продукт не начали считать мудацким ("эти мудаки требуют позвонить для отмены подписки — сволочи!")
— Собрать макимум фидбэка с уходящего, чтобы сделать продукт лучше для будущих ребят
— Приложить усилия для "спасения" пользователя, который захотел уйти. Может быть его можно уговорить остаться. ("Думал, что так сделать нельзя — а саппорт объяснил, что можно")
— Если уж человек уходит, сделать так, чтобы у него остались приятные воспоминания и он продолжил вас рекомендовать ("мне не подошли, но ребята хорошие — буду их советовать при случае")

Это unboarding.

P.S. (технически de-boarding, но unboarding звучит забавней)

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

Вот допустим ест озвученная идея "Россия хочет запретить жестокие игры" (специально для примера такую немного дурацкую)

Как именно переворачивать:
— Вывернуть наоборот: "а если разрешать только добрые игры без жестокости?"
— Посмотреть на антипод: "а если разрешать любые жестокие игры?"
— Примерить на себя: "а я бы запретил жестокие игры?", "что будет со мной, если жестокие игры запретят?"
— Расширить на всех: "что будет со всеми, если жестокие игры запретят?"
— Поменять субъекта: "а что если бы жестокие игры запретила другая страна?"
— Поменять объект или подставить другие вещи: "а что если бы запретили жестокие фильмы или комиксы?", "а что если бы запретили вещи, которые ассоциируются с жестокостью (например ножи или мат)? "
— Увеличить или уменьшить частотность события, усилить или ослабить идею: "а если запретят любую жестокую игру?", "а если запретят только самые жестокие игры?"
— Сделать крупный план или мелкий план по времени: "насколько этот запрет важен на горизонте 10 лет? 50 лет? На горизонте следующей недели?"

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

II. Вторая (текущая) система еще проще. Это иерархия целей.

Годы: Сначала надо создать список глобальных целей / возможностей / проблем в продукте. Это штуки достаточно высокого уровня, которые планируются на год-два (и которые займут годы). Пересматриваются и изменяются пару раз в год, не больше.
↓
Месяцы: список проектов/задач/целей, на которые продакт-менеджер(ы) будет сфокусирован в следующие 3-4 месяца. Они должны быть прямым следствием глобальных целей и работать на их достижение. Пересматриваются и изменяются 2-3 раза за квартал.
↓
Недели: cписок задач, которые готовы для разработки и список задач в работе. Задачи являются следствием проектов из предыдущего списка. Планирование на следующие 3-4 недели. Пересматриваются и изменяются раз в 1-2 недели.

Вот этот подход пока работает хорошо и не требует сильного оверхеда на его поддержание.

Про категоризацию роадмапа (не путать с приоритезацией).

Роадмап можно сортировать разными способами: Kano model, по функциональным частям и т.д.
Расскажу про две, которые я использовал и которым пришел как-то сам.

I. Первая система делит все изменения на следующие сегменты:
— Game Changers & Moonshots
— Showstoppers and Activators
— Keepers and Success Generators
— Money generators from loyal merchants

"Game Changers & Moonshots" — изменения, которые:
- Открывают для вашего продукта совершенно новый сегмент пользователей, которого не было до этого
- Штуки, без которых какой-то сегмент пользователей полностью отвергает продукт с порога (не рассматривая)
- Штуки только ради которых какие-то пользователи купят ваш продукт
- Рискованные эксперименты, новые рынки, прототипы, пивоты: ставки у которых высокий шанс провала, но и высокий выигрыш.

Метрики: повышает количество регистраций и их активацию

"Showstoppers and Activators" — изменения, которые:
— Улучшают активацию пользователей (большее их количество начнет пользоваться продуктом) и их мотивацию продолжать
— Штуки, которые необходимые определенным сегментам, чтобы пользоваться продуктом.
— Штуки, которые убирают препятствия для того, чтобы начать пользоваться продуктом.

Метрики: повышают активацию и конверсию в платные аккаунты (если у вас они есть). Уменьшают churn в первые месяцы.

"Keepers and Success Generators" — это:
— Штуки, которые становятся нужны пользователю, когда он стал успешен с продуктом(и теперь имеет другие потребности), перешел в cегмент power users или же пользуется долгое время. Без них пользователь может перерасти продукт.
— Штуки, которые долговременно помогают пользователю быть успешным с продуктом

Метрики: уменьшают долговременный churn, увеличивают метрику успешности пользователей (у каждого продукта она своя)

"Money generators from loyal merchants" — это,
— Штуки, которые позволяют зарабатывать тем больше, чем успешнее довольный пользователь с продуктом.\
(если пользователь недовольный — это уже Keeper)

Метрики: увеличивают ARPU

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

Со временем я от этой штуки отказался и перешел к следующей.

Apple не стесняется использовать всю свою мощь для продвижения своих интересов. И делает это замечательно, очень интересно наблюдать.

На прошедшем WWDC 2019 объявили о новой штуке "Sign in with Apple" — быстрый способ логиниться куда-то, используя аккаунт от Apple. Как кнопки логина от Фейсбука/Гугла, но с фокусом на приватность данных и отсутствие данных для рекламного трэкинга.

А теперь смотрите.
— Apple требует от всех разработчиков приложений поддерживать "Sign in with Apple" везде, где есть кнопки логина через Facebook/Google. Изменения вступят в силу осенью, если не поддерживаешь — твое приложение не проаппрувят.
— Разработчики вынуждены добавить эту штуку.
— Если пользователи заходят через "Sign in with Apple" в какой-то сервис и у сервиса есть веб-версия, то пользователи ожидают эту опцию и на вебе. То есть разработчик вынужден добавить ее и туда. А если есть Android app и есть люди переходящие с iPhone на Android, то и в Android app.
— Куча сервисов начинает демонстрировать бренд Apple при логине
— Apple получает еще большую видимость на чужих брендах, при этом заявляя что их главная цель это защита пользователей ("высокая цель"). Также есть разные побочные бонусы типа логина с Apple Watch в один тап (вводить логины/пароли с часов муторно).

Крутой ход.

Идея "Strong Opinions, Weakly Held" весьма популярна. Смысл ее в том, чтобы быть очень уверенным в своем мнении, но быть готовым сменить мнение, если появятся противоречащие факты.

У этого подхода есть проблема, которую надо учитывать.

Если в команде низкий уровень иерархии (power distance) и есть выработанная привычка давать фидбэк и спорить (то есть такое поведение поощряется), то такой подход будет хорошо работать.
Если же ситуация другая: дисбаланс во влиянии (разница в power и/или высокий power distance в команде, причем на мой взгляд менеджеры эти штуки недооценивают), отсутствие привычки давать фидбэк и отстаивать другое мнение (например такое поведение не поощряется явно) или же нежелание идти на конфликт у человека (не все любят конфликты, даже небольшие, — это нормально), то в такой ситуации высказанное громкое strong opinion может просто не быть никем оспорено. Оно будет принято по дефолту, без обсуждения и push back, даже если у команды есть сомнения. И это неэффективно. (ну и strong opinion высказанное явно, побуждает тебя его защищать, даже если на словах ты за weakly held — так уж мы устроены)

Поэтому надо на эти штуки делать поправку. Например заранее уменьшать уровень высказываемой уверенности(если к ней нет причин) и активно побуждать всех спорить со своим высказанным мнением ("покритикуйте?", "поделитесь — что может пойти не так?" и так далее).

Очень интересные слайды про A/B эксперименты от чуваков из Bing: "Seven Rules of Thumb for Web Site Experimenters" https://exp-platform.com/Documents/2014-08-27ExperimentersRulesOfthumbKDD.pdf

Куча разных примеров. Особенно мне запомнились вот эти штуки.

— Twyman’s Law: Any figure that looks interesting or different is usually wrong.
Если статистика (или результаты эксперимента) выглядит необычно, удивляет, показывает какие-то невероятные результаты — скорее всего где-то ошибка и надо в первую очередь искать ее. Главная ошибка: сразу объяснять удивительный результат неверной причиной (например результатами эксперимента)

— Пример неправильного объяснения: цинга и витамин C. Цинга была серьезной проблемой в 16-18 веках у моряков. Доктор James Lind обратил внимание на отсутствие цинги у кораблей в Средиземном море. В 1747 году он провел экспериент и давал одним морякам лаймы, другим обычную еду. Чуваки, кто ели лаймы не заболели. Но Lind сделал неправильный вывод и объяснил успех неверной причиной. Позже в Англии он начал лечить пациентов с цингой концентрированнным лимонным соком. К сожалению в процессе его приготовления его подогревали, что разрушало витамин C. Поэтому у доктора не получилось повторить успешный результат и он разочаровался в своей теории (и стал лечить цингу кровопусканием)

— Второй пример: известная история от Гугла, когда они увеличили количество результатов на странице с 10 до 20, скорость загрузки страницы выросла на полсекунды, а revenue (заработок с рекламы) снизился на 20%. Это объясняли как "смотрите как скорость влияет". Чуваки из Бинга задумались — да, скорость влияет, но неужели 500ms влияет на 20% (!) revenue со страницы. Стали копать и повторили эксперимент. По их словам дело не в скорости, а в кол-ве рекламы на странице. На странице с 10 результатами — определенное количество рекламных объявлений. Когда количество результатов увеличивается, а количество объявлений остается тем же — это понижает их видимость (ну и соответственно клики и заработок). Они увеличили количество рекламы (еще больше замедлив страницу) и влияние на revenue исчезло.

— Часто эксперименты не улучшают engagment или abandonment rate, а всего лишь направляют клики/путь пользователя в другое место. Поэтому важно смотреть, не каннибаллизируют изменения просто существующий трафик, не улучшая картину в целом. Надо смотреть на улучшение общей метрики и если уж каннибализировать существующие клики, то направлять их на области, которые чем-то лучше чем существующие.
Перефразируя: легко оптимизировать локальные штуки (использование фичи, кликабельность элемента и тд) — сложно улучшать глобальные штуки (общие метрики, общий успех)

(весь тред на Реддите -- есть очень смешные штуки)

В следующий раз, когда будете думать, что ваш проект идет сильно не так, вспомните про этот марафон на Олимпиаде 1904 года.

(Альтернативное название: "если ваш проект не выглядит как этот, даже не вздумайте приглашать меня на него")

Большой комментарий на Реддите про условия работы в Боинге: https://www.reddit.com/r/videos/comments/bdfqm4/the_real_reason_boeings_new_plane_crashed_twice/ekyyd9g/

Автор рассказывает всяческие ужасы про бюрократию и политику там. Но интересно там не это (правда ли это и насколько — открытый вопрос, каждый решает сам). Интересна там вот эта выдержка:

> Anyhow, James (or was it Jim? It's been a while.) was a grouchy old engineer they stuck me next to. He was close to retirement and clearly wasn't too stoked about losing half his cubicle to an unwanted programmer that showed up one day. James had a bunch of photos of an old 747 and structural diagrams pinned to his cubicle wall. One day, I asked what those were.

> They were pictures and failure analysis diagrams of JAL 123, the single worst single airplane disaster in history. 520 people died. It was because a couple of Boeing engineers fucked up. That 747SR had had a tailstrike incident on takeoff that damaged the rear pressure dome. A team of Boeing AOG (Airplane On the Ground) mechanics were flown out there to fix it. To oversimplify, they rushed and accidentally did the equivalent of 1+1=1 on one of their stress calculations. It was an error very similar to the infamous Hyatt Regency walkway collapse. 12,318 flights later, (well before what should have been at least 25-30,000 flight cycles that the crack inspection cycle would have assumed) the rear bullkhead ripped out mid flight and severed all hydraulic control lines. The plane lost all control and flew in a rollercoaster trajectory for 32 minutes before running into the side of a mountain. Many of the passengers had time to write goodbye letters to their loved ones. James had those photos and diagrams on his cubicle so that every day, he could look at them and remind himself of why his job was important and why he couldn't cut corners.

Вот эта вот способность видеть за работой (кодом, тикетами, тасками, изменениями) живых людей — очень важна. Спустя какое-то время начинаешь путать настоящую цель с ее проекциями. Теряешь эмпатию к людям, которые твоим продуктом пользуются. Это ведет к тому, что срезаешь углы, делаешь фигню, перестаешь вдохновляться своими делами, начинаешь делать штуки, которые важны для short-term метрик, а не для будущего.
Короче — ничего хорошего. Для тебя каждый пользователь становится одним из миллионов многих, простая строчка в таблице. А на самом деле это живой человек со своими чувствами, для которого твой продукт важен для достижения этого человека важных целей.

Важно про это время от времени себе напоминать.

Slack не показывает preview у Ютуб-видео с рикроллом (а у других видео показывает): https://twitter.com/SlackHQ/status/1120655978347868160 Ну то есть у них прям в коде хранится логика "если шарят именно это видео — не показывать preview, чтобы не портить шутку". Классная и забавная деталь.

II. Технологические партнерства это штука обоюдоострая.
Тинькоф-банк сначала запустил брокера через БКС: это позволило им запустится, провалидировать спрос на услугу, понять что и как работает. Потом они сделали все у себя — БКС стал не нужен и они стали конкурентом (как я понимаю) БКС.

Есть и еще подобные примеры.

Например Mailchimp: они были супер-классным партнером для сторонних ecommerce ребят, которые хотят предлагать рассылки. Потом Mailchimp сделал конструктор landing страниц и добавил туда прием платежей. Я предполагаю, что они на горизонте 1-2 лет запустят свое собственное ecommerce решение. То есть Mailchimp вырос во многом за счет партнерств с другими решениями и станет им прям конкурентом (подход "троянский конь").

Или вот история от Mozilla про Гугл: https://threadreaderapp.com/thread/1116871231792455686.html (делайте поправку на bias ребят из Mozilla).

То есть если вы технологический партнер у других ребят, то надо про это подумать. Если вы не решаете хорошо (по мнению других ребят) задачу и она стратегически важна для них — вас могут заменить на in-house решение рано или поздно. Даже если вы решаете задачу достаточно хорошо — вас могут заменить только из-за желание бОльшего контроля над ключевой технологией. У других ребят ваше направление может не быть стратегическим сейчас, но может стать таким через пару лет. Короче, чтобы не заменили надо быть незаменимым (что бы это не означало: супер-продукт, компетенции, сложность повтора продукта, известность бренда и тд).

Ребята из Тинькофф-банка рассказывают про то, как они открыли своего биржевого брокера — проект Тинькофф Инвестиции: https://m.habr.com/ru/article/446262/

Статья напоминает про две важных мысли.

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

> "Например, после продажи ценной бумаги перевод денег с биржи идет от двух дней, а клиенты хотели моментально вывести деньги — ни один брокер не предлагает такого"

Легко убедить себя, что сейчас "норм". Что лучше уже не сделаешь и "у всех так". Это может завести в тупик. Неудолетворенность и вопросы "а можем ли мы тут сделать еще лучше?" — хороший двигатель.

При этом важный момент: это не означает, что надо считать свой продукт чем-то плохим. Это неконструктивно: вы будете считать, что делает фигню (синдром самозванца), это плохо влияет на команду (кому хочется работать над плохой фигней?). Я же говорю про подход "мы сделали отличную штуку — но ее можно сделать ЕЩЕ лучше".