Июнь 2019: токсоплазма ярости, подход Do/Understand/Feel, анбоардинг и приблизительный консенсус

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

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

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

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

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

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

А теперь смотрите.

Крутой ход.

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

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

I. Первая система делит все изменения на следующие сегменты:

Game Changers & Moonshots” — изменения, которые:

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

Showstoppers and Activators” — изменения, которые:

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

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

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

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

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

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

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

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

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

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

Недели: cписок задач, которые готовы для разработки и список задач в работе. Задачи являются следствием проектов из предыдущего списка. Планирование на следующие 3-4 недели. Пересматриваются и изменяются раз в 1-2 недели.

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

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

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

Как именно переворачивать.

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

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

Люди будут переставать пользоваться продуктом. Не такая простая задача сделать так, чтобы:

Это unboarding.

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

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

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

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

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

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

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

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

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

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

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

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

Вот неочевидный пример.

Пару недель назад была история с 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 Ocean это были настоящие плохие ребята (спамеры, хакеры — кого нужно закрывать и кого не жалко), а false positives мало относительно общего числа клиентов, то планка снизилась. Всем было “норм”, А ЧТО ТАКОГО. В таких ситуациях нужен человек, который сможет сказать “ребята, ну это же фигня какая-то — разве это правильно? Давайте это исправим”. Каждый может и должен быть таким человеком.

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

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

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

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

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

§§§
Отличный тред про то, как продакт-менеджеру завоевать доверие и уважение команды: https://twitter.com/johncutlefish/status/1124938723093766144

110 - Don’t hide things from your team in an effort to protect/shield them. That’s weird. It’ll come back to bite you.

210 - Do actual work. Meaningful work. Context-building work. Analysis. Research. Design smart experiments. A good test is whether the team would pay you if they controlled the budget.

310 - Act like a member of the team, not as a manager of the team. The second you create a wall…the team will create a wall as well. Consider inviting a facilitator in so you can express your own needs (instead of juggling facilitation and team membership)

410 - Take ownership of your decisions. Don’t celebrate when things go well, and make excuses when they don’t (and don’t, don’t, don’t throw your team under the bus). This asymmetry can be maddening for passionate problem solvers.

510 - The second it seems like you’re only in this for you and your self-advancement…you’ll lose the team. Share all wins. Be humble. This is trust-building/maintaining 101, but too many PMs smack of selfish careerism

610 - On the flipside, don’t fake being humble or “deep”. There’s so much talk about humble servant leadership, that you’re seeing people go through the motions in obviously very forced and unnatural ways. Be yourself.

710 - Don’t sugar-coat. Master talking about uncertainty with certainty. Explain what you know and don’t know. Be transparent about risks. Let the data/context do the inspiring and census building. Lots of PMs over-use their charisma and salesperson-ship and it backfires

810 - Don’t disappear for days on end — “because [your] calendar is sooooo full” — and come back empty-handed. This is an extension of “do actual work” (2). It is one thing to be unavailable. Another thing to ignore your team.

910 - Your job is not to keep the team busy or “topped up”. You don’t feed them work. You don’t do story point by engineer spreadsheets. Yuck. Focus on value and opportunity. If you need to back off and rethink things….well do that.

1010 - Finally…remember engineers make cost/benefit decisions all day. No one wants to add lots of complexity to the product without impact. Consider product as IDD (impact driven development). Give yourself passing tests. Be transparent about those tests. Impact builds trust

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

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

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

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

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

§§§
Неплохая статья, которая описывает подход к анимациям в интерфейсах: https://tobiasahlin.com/blog/meaningful-motion-w-action-driven-animation/

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

§§§
Интересный подход к принятию решений в организации IETF (они придумывают разные интернет-стандарты): rough consensus. Можно почитать про это в блог-посте или подробно в этом RFC (английский)

Главный смысл этого подхода в том, что в первую очередь идет поиск не согласия, а несогласия. Вместо вопроса “всем ли ОК формат А?”, который конечно вызовет кучу разного фидбэка и возражений, задается вопрос “кто-то не может жить с форматом A?”. Это позволяет им отделить возражения вида “просто хотел бы по другому” (= это не идеальное решение) от “это абсолютно неприемлимо для меня” (= это плохое решение).

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

IETF говорит, что консенсус для них это не самоцель. Это инструмент, который позволяет принимать лучшие технические решения. По их мнению другие подходы этого не дают сделать, например голосование позволяет большинству просто проигнорировать какую-то проблему или же продвинуть свое решение. Технологические решения это всегда нелегкий выбор, когда чем-то жертвуешь, всегда компромисс (в хорошем смысле). Но они хотят избежать компромиссов в плохом смысле, среди людей, когда какое-то меньшинство против решения даже после обсуждения (считает, что есть проблема), но не хочет доказывать это дальше из-за того, что надоело “хрен с вами, делайте что хотите”. Это плохой компромисс, несмотря на “согласие”, проблема же осталась и не решена.

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

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

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

§§§
Общее правило: умный человек, когда дает совет всегда рассказывает контекст и условия, в которых совет применим. Также умный человек, когда получает совет, спрашивает условия и контекст, когда совет применим. Советы без контекста и условий — выстрел в коленку.

P.S. Какой контекст и условия применения этого совета про советы? 🤔

§§§
Есть вещи вокруг, которые очень контринтуитивны. Cамый известный пример, это наверное Парадокс Монти Холла — не буду про него рассказывать, каждая книжка о статистике его упоминает. Если не слышали — поищите, очень поражает. Я до сих пор, понимая что к чему, не могу этот парадокс полностью осознать.

Еще одна похожая штука: закон Бе́нфорда.

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

Первое, что приходит в голову, что так как цифр 10 и первая не может быть нулем, то вероятность ⅑. Это не так. Вероятность единицы — ~30%, двойки — ~17.6%, тройки — ~12.5% и вероятности потом постепенно убывают для каждой цифры. Минимальное значение у девятки — 4.6%. Это очень неожиданный результат.

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

Эта штука работает для очень многих данных (особенно если темп роста величины пропорционален её текущему значению), но не для всех. Не сработает, если:

Интересно то, что эту штуку используют для нахождения мошенничества с финансами. Числа в финансовых отчетах как правило соотвествуют закону Бенфорда, поэтому если не соответствуют — скорее всего их подгоняли вручную с мыслью “надо сделать их похожими на случайные числа”, что как раз приводит к обратной ситуации.

§§§
Онбоардинг — штука, которая затрагивает весь продукт. И перед тем как сразу пытаться добавлять визарды, письма и прочие мотивационные штуки, надо сделать самое сложное: определить что же мы хотим, чтобы пользователь сделал. Это самый сложный этап в проектировании онбоардинга, который определяет все.

Я со временем пришел к следующему формату. Он вот такой:

Мы берем продукт и пользователя. Сначала мы описываем пользователя и его состояние.

Вторая часть посвящена тому, что мы хотим от пользователя.

Хорошие вдумчивые ответы на эти вопросы это половина планирования онбоардинга уже.

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

Также,

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

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

  1. Какой контекст у пользователя? Какой у него бэкграунд и в каком состоянии он находится? (Context)
    — Это владелец бизнеса, который хочет получить новых покупателей. Он уже создал аккаунт в сервисе, но еще ничего не сделал.

  2. Что пользователь хочет? На какую “работу” он хочет нанять наш продукт в терминах JTBD? (What does user want? What’s the job they hired us to do?)
    — Хочет новых посетителей, которые бы сами приходили и тратили деньги. — Хочет чтобы если родственники поискали в Яндексе — там его бизнес показывался “как взрослый”

  3. Какие вопросы, страхи или препятствия есть у пользователя? (What questions, fears and obstacles does a user have?)
    — Вопросы: а точно приведет пользователей? а сколько денег возьмут? — Страх: деньги возьмут, а результата не будет. — Препятствие: нет времени все настроить

  4. DO
    — Хотим, чтобы пользователь нашел 15 минут и ввел информацию о своем бизнесе: адрес, сайт и тд. — Хотим, чтобы пользователь заплатил деньги и запустил размещение.

  5. UNDERSTAND
    — Вручную это очень долго делать и это было бы сложно. Он сэкономит себе кучу времени за смешные деньги.

  6. FEEL
    — Это было просто! — Я потратил 15 минут и в будущем мой бизнес ждет успех. — Я умный предприниматель, на “ты” с клевыми технологиями.

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

§§§
Большая статья про запуск Amazon Prime в 2005 — подписка, которая дает тебе быструю доставку и кучу других бонусов: https://www.vox.com/recode/2019/5/3/18511544/amazon-prime-oral-history-jeff-bezos-one-day-shipping Интересно почитать про этот запуск.

↑ 👾 🚀