У этого подхода есть проблема, которую надо учитывать.
Если в команде низкий уровень иерархии (power distance) и есть выработанная привычка давать фидбэк и спорить (то есть такое поведение поощряется), то такой подход будет хорошо работать. Если же ситуация другая: дисбаланс во влиянии (разница в power и/или высокий power distance в команде, причем на мой взгляд менеджеры эти штуки недооценивают), отсутствие привычки давать фидбэк и отстаивать другое мнение (например такое поведение не поощряется явно) или же нежелание идти на конфликт у человека (не все любят конфликты, даже небольшие, — это нормально), то в такой ситуации высказанное громкое strong opinion может просто не быть никем оспорено. Оно будет принято по дефолту, без обсуждения и push back, даже если у команды есть сомнения. И это неэффективно. (ну и strong opinion высказанное явно, побуждает тебя его защищать, даже если на словах ты за weakly held — так уж мы устроены)
Поэтому надо на эти штуки делать поправку. Например заранее уменьшать уровень высказываемой уверенности(если к ней нет причин) и активно побуждать всех спорить со своим высказанным мнением (“покритикуйте?”, “поделитесь — что может пойти не так?” и так далее).
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 в один тап (вводить логины/пароли с часов муторно).
Крутой ход.
Про категоризацию роадмапа (не путать с приоритезацией).Роадмап можно сортировать разными способами: 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
Ну и делишь фичи из бэклога на эти сегменты, в каждом сегменте приоритезируешь отдельно. В зависимости от целей тот или иной сегмент может получать приоритет сам, но в целом это позволяет сохранять какой-то баланс, без перекосов в ту или иную сторону.
Со временем я от этой штуки отказался и перешел к следующей.
II. Вторая (текущая) система еще проще. Это иерархия целей.
Годы: Сначала надо создать список глобальных целей / возможностей / проблем в продукте. Это штуки достаточно высокого уровня, которые планируются на год-два (и которые займут годы). Пересматриваются и изменяются пару раз в год, не больше.
↓
Месяцы: список проектов/задач/целей, на которые продакт-менеджер(ы) будет сфокусирован в следующие 3-4 месяца. Они должны быть прямым следствием глобальных целей и работать на их достижение. Пересматриваются и изменяются 2-3 раза за квартал.
↓
Недели: cписок задач, которые готовы для разработки и список задач в работе. Задачи являются следствием проектов из предыдущего списка. Планирование на следующие 3-4 недели. Пересматриваются и изменяются раз в 1-2 недели.
Вот этот подход пока работает хорошо и не требует сильного оверхеда на его поддержание.
Заметил штуку, которая у меня срабатывает автоматически при обдумывании какой-то новой концепции, идеи, вопроса или оценочного суждения. Я начинаю по разному этот вопрос переворачивать в голове, каждый раз проверяя свое отношение к новой версии.Вот допустим есть озвученная идея “Россия хочет запретить жестокие игры” (специально для примера идея немного дурацкая)
Как именно переворачивать.
- Вывернуть наоборот: “а если разрешать только добрые игры без жестокости?”
- Посмотреть на антипод: “а если разрешать любые жестокие игры?”
- Примерить на себя: “а я бы запретил жестокие игры?”, “что будет со мной, если жестокие игры запретят?”
- Расширить на всех: “что будет со всеми, если жестокие игры запретят?”
- Поменять субъекта: “а что если бы жестокие игры запретила другая страна?”
- Поменять объект или подставить другие вещи: “а что если бы запретили жестокие фильмы или комиксы?”, “а что если бы запретили вещи, которые ассоциируются с жестокостью (например ножи или мат)? "
- Увеличить или уменьшить частотность события, усилить или ослабить идею: “а если запретят любую жестокую игру?”, “а если запретят только самые жестокие игры?”
- Сделать крупный план или мелкий план по времени: “насколько этот запрет важен на горизонте 10 лет? 50 лет? На горизонте следующей недели?”
- Посмотреть на выводы: Если А — верно и из A следует B, что ещё следует из B и нравится ли мне это? “Запрет жестких игр это вмешательство государства, что еще следует из такого прецендента такого вмешательства и ОК ли мне это?”
Для каждого “если” автоматически оцениваю отношение (нравится или нет, правильно или нет, хотел бы или нет). Это позволяет взглянуть на идею более глубоко и выработать про нее более взвешенное мнение (без черно-белых максимумов)
Вот есть понятие онбоардинга — про эту штуку пишут разные статьи и книги (хороших не так много, впрочем). Это про то, как люди начинают пользоваться продуктом. Но вот статей про изменения в продукте, которые позволяет получить максимум пользы, когда человек перестает пользоваться продуктом — нет.Люди будут переставать пользоваться продуктом. Не такая простая задача сделать так, чтобы:
- Уйти с продукта было достаточно болезненно, чтобы уходили только настойчивые (“При даунгрейде у меня перестанет работать сайт, который у меня уже три года”)
- Не переборщить с настойчивостивостью и блоками, чтобы продукт не начали считать мудацким (“эти мудаки требуют позвонить для отмены подписки — сволочи!”)
- Собрать макимум фидбэка с уходящего, чтобы сделать продукт лучше для будущих ребят
- Приложить усилия для “спасения” пользователя, который захотел уйти. Может быть его можно уговорить остаться. (“Думал, что так сделать нельзя — а саппорт объяснил, что можно”)
- Если уж человек уходит, сделать так, чтобы у него остались приятные воспоминания и он продолжил вас рекомендовать (“мне не подошли, но ребята хорошие — буду их советовать при случае”)
Это unboarding.
P.S. (технически de-boarding, но unboarding звучит забавней)
P.P.S. Уважаемые читатели (Julia, Kostya — спасибо!) прислали немного добавлений:
- Общепринятое название этой штуки на английском языке: offboarding. По запросу product offboarding можно найти несколько статей.
- Есть чувак, который активно про эту тему рассказывает и даже написал книгу: http://www.andend.co/ Также у него много разных выложенных докладов на эту тему: http://www.andend.co/talks
Это длинная статья, но я ее рекомендую ее всем прочитать. Она про радикализацию идей, сигнализировании о своих моральных принципах и спорах в интернете.
В ней утверждается, что люди склонны публично поддерживать наиболее радикальные идеи или мнения. Когда нет явно хороших и плохих, когда ответ неочевиден и сильно зависит от твоих текущих убеждений.
Почему: публичный выбор стороны в спорном деле (когда “все сложно”) это лучший способ просигнализировать о принадлежности к определенной идентичности или о своих (высоких) моральных убеждениях.
Например убеждение “мучить животных нехорошо” — плохое для сигнализирования. Большинство людей с тобой будут согласны и так. Поэтому оно никак тебя не выделяет. Убеждение “надо перестать есть любые продукты животного происхождения” уже достаточно спорное, чтобы человек его произносящий смог достаточно сильно просигнализировать о своей индентичности и/или высоких и стойких моральных убеждениях (“не то что у остальных!”)
Очевидные и бесспорные штуки никто не обсуждает и не шарит. Все говорят только про спорные ситуации — информация о них получает наибольшее распространение. В процессе люди радикализируют свои мнения, что приводит к еще большему расколу. Появляются “враги” 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 версию для создания форм внутри приложения. Это нормальный обмен в некоторых ситуациях (гладкость работы на скорость выпуска). Но при этом чтобы дойти до создания первой формы надо пробраться через кучу препятствий.
- Два разных баннера, которые рекламируют апп в котором я уже нахожусь
- Баннер про куки, который совсем можно убрать (и предупредить про все эти штуки при регистрации)
- Кнопка “Создать форму” в приложении, которая открывает web страницу в которой надо нажимать “Создать форму” еще раз ಠ_ಠ
- Просят разрешение на пуш-нотификации сразу после регистрации — слишком рано
Также в идеале надо объясняющие welcome экраны совсем убирать — они там бесполезные и ничего не объясняют на самом деле. Регистрацию тоже или убирать совсем или откладывать на самый последний шаг (не всегда регистрацию можно быстро убрать совсем). Вместо текущего подхода надо было сразу задавать вопросы про первую форму (какой вопрос у тебя, какие поля хочешь спросить, на какую почту слать ответы и т.д.), потом показать preview формы со ссылкой и спросить создать аккаунт, чтобы сохранить созданный результат.
Хороший антипод онбоардингу у TikTok.
Отличный тред про то, как продакт-менеджеру завоевать доверие и уважение команды: https://twitter.com/johncutlefish/status/11249387230937661441/10 - Don’t hide things from your team in an effort to protect/shield them. That’s weird. It’ll come back to bite you.
…
2/10 - 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.
…
3/10 - 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)
…
4/10 - 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.
…
5/10 - 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
…
6/10 - 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.
…
7/10 - 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
…
8/10 - 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.
…
9/10 - 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.
…
В каждой книге или статье про интервью с пользователями будет мысль, что не надо смотреть на то, что люди говорят или обещают. Надо смотреть на то, что они делают сейчас или делали в прошлом. Человек может рассказывать, что ему нужна какая-то фича, но если он ничего не сделал, чтобы ее получить (не нашел обходной путь, не обратился в саппорт, не ушел на другую платформу) — скорее всего не так уж она ему и нужна.10/10 - 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%. Это очень неожиданный результат.
Это правило справедливо для массивов чисел, основанных из данных из реальной жизни. Длина рек (причем не важно в чем измеряная), цены на акции, ваши расходы, смертность и так далее — для всего этого закон будет работать.
Эта штука работает для очень многих данных (особенно если темп роста величины пропорционален её текущему значению), но не для всех. Не сработает, если:
- У данных есть ограничения сверху или снизу
- Данных мало или же они покрывают только один-два порядка (например IQ)
- Числа назначаются искусственно: например индексы или номера заказов или маркетинговые цены в магазине ($9.99)
- В данных нет нормального распределения Но если перемешать много таких разных данных, то результат уже будет подчинятся этому закону.
Интересно то, что эту штуку используют для нахождения мошенничества с финансами. Числа в финансовых отчетах как правило соотвествуют закону Бенфорда, поэтому если не соответствуют — скорее всего их подгоняли вручную с мыслью “надо сделать их похожими на случайные числа”, что как раз приводит к обратной ситуации.
Онбоардинг — штука, которая затрагивает весь продукт. И перед тем как сразу пытаться добавлять визарды, письма и прочие мотивационные штуки, надо сделать самое сложное: определить что же мы хотим, чтобы пользователь сделал. Это самый сложный этап в проектировании онбоардинга, который определяет все.Я со временем пришел к следующему формату. Он вот такой:
- Context / Goals / Questions & Fears
- Do / Understand / Feel
Мы берем продукт и пользователя. Сначала мы описываем пользователя и его состояние.
- Какой контекст у пользователя? Какой у него бэкграунд и в каком состоянии он находится? (Context)
- Что пользователь хочет? На какую “работу” он хочет нанять наш продукт в терминах JTBD? (What does user want? What’s the job they hired us to do?)
- Какие вопросы, страхи или препятствия есть у пользователя? (What questions, fears and obstacles does a user have?)
Вторая часть посвящена тому, что мы хотим от пользователя.
- Что мы хотим, чтобы пользователь сделал в продукте? (DO)
- Что мы хотим, чтобы пользователь понял о продукте? (UNDERSTAND)
- Что мы хотим, чтобы пользователь почувствовал, после использования продукта? (FEEL)
Хорошие вдумчивые ответы на эти вопросы это половина планирования онбоардинга уже.
Документ с ответами будет основой, которую можно использовать и с которой нужно будет консультироваться при планировании онбоардинга. Это дает возможность как и понять, что делать, так и убедится, что все части продукта работают на одну цель.
Также,
- лучше чтобы он не был больше листа A4
- иногда on-boarding делится на отдельные части, например для e-commerce это “запустить магазин” и “получить первую продажу”. В этом случае каждая часть рассматривается отдельно и для каждой части задаются эти вопросы.
Искусственный пример, который очень упрощен для демонстрации.
Допустим у нас есть сервис, который продвигает бизнес пользователя, добавляя информацию о бизнесе автоматически в Яндекс.Карты и Гугл-карты.
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 Интересно почитать про этот запуск.- Все началось с мысли “а как сделать заказ ЕЩЕ проще”. У Амазона был бесплатная “Super Saver” доставка, но она работала только если заказ от $25. Получается ты не можешь быстро купить один товар с бесплатной доставкой, надо думать, что еще добавить в корзину. Один чувак предложил “а давайте в начале года брать денег с покупателя заранее, а потом ему всегда давать бесплатную доставку?”. Потом идеи с апгрейдом доставки стали крутить по разному, но все они были ОК, но не что-то что люди могут действительно полюбить. В конце конце пришли к идее “если ты на подписке, то двухдневная доставка бесплатно, а в тот же день в два раза дешевле”.
- Проект получил очень высокий приоритет. По сути его цель — создание штуки, которые другие ребята не смогут повторить никогда. Слова Безоса: “I want to draw a moat around our best customers. We’re not going to take our best customers for granted.”
- Проект запустили в рекордные сроки за 6 недель. Главная причина, почему это получилось, годы вложений в инфраструктуру до этого.
- У проекта было много противников, была боязнь, что он потопит (финансово) Амазон.
- eBay проворонил рост успеха Амазона, так как уговорил себя, что они не конкурент “да у них аукционы не взлетели”, “да у них только книги, фильмы и музыка, кто пойдет к ним одежду покупать?”. А потом бац и Амазон всех победил.
- После запуска Amazon Prime доходы от доставки упали. Люди которым была важна быстрая доставка и которые за нее платили, первыми подписались на Prime. Амазон не стал дергаться (“не взлетело — закрываем!”) и стал ждать, оптимизируя подходы и инфраструктуру. Хитрый прием: заказываешь какую-то мелочь за $3 и Амазон теряет деньги на бесплатной двухдневной доставке этой штуки. Поэтому Амазон предлгагает тебе другие штуки с очень хорошей скидкой, но эти особенные товары уже не попадали под двухдневную бесплатную доставку. Со временем Prime начал расти, Амазон стал включать туда все больше и больше хороших бонусов (от разных частей своей компании, например доступ к видео). И добавил Prime для сторонних продавцов через свою программу Fulfillment by Amazon.
- Доступ к цифровому видео для Prime подписчиков не был очевидной идеей, так как Prime воспринимался как штука про доставку.
- Расходы надо считать с учетом роста и будущих возможностей. В 2016 у Амазона был один фулфилмент центр. Доставка стоила им $1.50 по земле и $15 по воздуху за посылку. Ну и чувак презентовал как много будет стоить Prime из-за процента доставок по воздуху. На что Безос ответил: “You aren’t thinking correctly.” Если пользователям нравится Prime, то из будет больше и посылок через Prime будет больше. А так как из больше, это даст возможность построить больше фулфилмент центров, что уменьшит процент дорогих доставок по воздуху.