Если прочитать Канемана и разные штуки про когнитивные искажения, то все это сложно уложить в голове и запомнить. Но это и не нужно. Вместо этого надо просто понять теорию перспектив, за которую Канеман и Тверски получили Нобелевскую премию. Теория достаточно простая и укладывает все в голове. В упрощенном виде она выглядит вот так.
- Воспринимаемая ценность любой штуки, события и выбора всегда зависит от ценности самой штуки и вероятности ее получения. Мы всегда смотрим на обе эти штуки одновременно и оцениваем их вместе. Ценность получения $100 c 100% вероятностью всегда больше чем $100 с 50% вероятностью. Ценность может быть положительная (приобретения) или отрицательная (потери).
- Наша внутренняя субъективная оценка вероятности события (как мы считаем внутри) отличается от объективной вероятности.
- Наша внутренняя субъективная оценка ценности события отличается от объективной ценности.
Получается вот такая формула: U = w(P) × v(x)
Ожидаемая ценность это произведение субъективной вероятности и субъективной ценности.
- U — ожидаемая ценность
- P — объективная вероятность, w(P) — субъективная вероятность. Это зависимость / функция перевода объективного значения в субъективное.
- x — объективная ценность, v(P) — субъективная ценность
Особый интерес представляют как раз эти функции перевода объективных значений ценности и вероятности в субъективные.
Зависимость объективной ценности x от cубъективной v(x).
Видно, что это не прямая линия, то есть субъективная оценка отличается от объективной.
Воспринимаемая ценность при потере всегда сильно больше чем при приобретении. Видно, что в случае негативной ценности график сразу круто идет вниз, сильно круче чем рост при росте положительной ценности. Радость от получения $100 всегда меньше чем от потери $100. Это вызывает желание избегать рисков.
Справа график становится приплюснутым. То есть при росте объективностой ценности субъективная ценность перестает расти с такой же скоростью. Мы становимся менее чувствительными к приобритениям. Радость между событиями “получить $0” и “получить $100” сильно больше чем между “получить $1,000” и “получить $1,100” или cильно-сильно больше между “получить $10,000” и “получить $10,100”.
При потерях график тоже становится приплюснутым немного, но совсем не так сильно как с приобретениями. То есть огорчение от между событиями “потерять $0” и “потерять $100” больше чем между “потерять $1,000” и “потерять $1,100”, но не сильно.
При этом важно отметить, что “x” и “v(x)” тут именно изменение ценности, то есть разница между было и стало. Мы же реагируем именно на изменение ценности, на разницу, а не на уровень абсолютного результата.
А вот зависимость субъективной вероятности w(P) от объективной P.
Опять же видно, что это не прямая пунктирная линия, как было бы, будь мы абсолютно рациональны.
- Мы переоцениваем вероятность редких и особенно сверх-редких событий.
- Мы недооцениваем вероятность частых событий (это начинается где-то после объективной 30%-40% вероятности события). Чем больше объективная вероятность, тем больше недооцениваем.
Так как у выбора может быть несколько исходов, то более полная формула выглядит вот так: U = ∑ w(P) × v(x)
Сумма произведений субъективной вероятности и субъективной ценности каждого возможного исхода у этого выбора
Этот фреймворк с двумя графиками очень хорошо укладывается в голове и применяется при любых решениях, включая продуктовые. Также помогает исправлять свои оценки вероятности и ценности, делая поправку на субъективное восприятие.
Умение устанавливать правильные цены — наука и искусство одновременно. Люди целые книжки пишут и компании организовывают вокруг этого. Я знаю три штуки про цены. Первые две очевидные: скорее всего вам надо сделать цены выше (даже если некомфортно) и цена не равна ценности (отталкиваться надо от создаваемой ценности).Третья штука про цены у SaaS компаний: я думаю, что хорошие тарифные планы у SaaS компании всегда должны иметь (явно или неявно) две штуки, которые я называю “налог на понты” и “налог на успешность”.
Налог на понты
У разных клиентов разный бюджет. Для небольшой компании, стартапа, цена имеет значение, поэтому разница между $9 и $59 в месяц важна. Для крупных ребят эта разница значения не имеет совсем. Хорошие тарифные планы должны быть устроены так, чтобы позволить потратить клиенту весь доступный бюджет, дать ему потратить столько денег, сколько он может себе позволить.
Это обычно делают через более старшие тарифные планы с “enterprise” фишками. Некоторые ребята даже имеют планы без цены с “позвоните нам чтобы узнать” — это как раз для того, чтобы подобрать цену под бюджет клиента.
Налог на успешность
Клиент использует продукт и (если все хорошо) становится с ним успешнее (в рамках этого продукта и получаемой ценности). Цена, которую платит клиент, должна зависеть от успешности, от получаемой ценности. Если очень успешный клиент платит столько же, сколько и не очень успешный — это не хорошо.
Эту штуку обычно делают тремя подходами:
- Плата за единицу использования (за пользователя, за сайт, за потребленные мегабайты чего-то)
- Процент с транзакций (transaction fees, revenue share), если продукт как-то через себя перегоняет деньги
- Ограничения, которые выдавливают успешных ребят на старшие планы.
Вот например Dropbox. Есть как разные планы для разных клиентов, так и зависимость цены от величины использования продукта (количества пользователей). Shopify: явно прописали transaction fees, берут процент с оборота. У BigCommerce интереснее: они гордо пишут, что не берут процент с оборота, но если промотать ниже, то будет строчка с ограничением по “Online sales per year” — продаешь больше — переходи на старший план.
P.S. Конечно все сложнее и надо учитывать еще и контекст/нюансы: например если задать слишком высокие цены на старшие планы, то это может отпугнуть ваш сегмент пользователей, которые будут думать, что продукт не из их ценовой категории. Низкая цена может быть методом конкурентной борьбы, как например Basecamp, который заявляет, что берет $99/mo без всяких дополнений и хитростей.
Тут Apple недавно узнала, что есть компании, которые занимаются тем, что дают аналитику по сессиям пользователей. Записывают экран и передают его на сервер, чтобы дизайнеры и продакты могли анализировать как люди взаимодействуют с приложением. Известные сервисы про это: Appsee и UxCam.Всем приложениям, которые использовали SDK этих компаний было вынесен ультиматум: убрать SDK в 24 часа или приложение будет удалено из App Store. ТЫДЫЩ и бизнес Appsee и UxCam уменьшился.
Вторая новость про email провайдера из US. Ребята предоставляли email хостинг 18 лет, а потом хакер удалил все данные с их серверов, включая бэкапы. ТЫДЫЩ, бизнес исчез.
Эти две новости наводят на размышления об устойчивости компаний к таким событиям “черного лебедя”.
Очевидно, что невозможно защититься от всех-всех маловероятных событий — строить бункер для защиты от потенциального метеорита было бы глупо, это тот пример, когда вероятность события слишком мала, а вложения для его предотвращения слишком велики. Но это очень хороший вопрос — а что если?
А что если платформа, в экосистеме которой вы растете, отрубит доступ или сделает что-то свое? А что если все сервера сломаются? А что если бэкап будет невозможно восстановить? А что если…?
Баланс между тем от событий какой вероятности защищаться и что вкладывать в защиту — свой выбор каждой компании. Но вопрос “а что если..?” супер-важный для всех.
Обсуждали тут с ребятами доклады на конференциях. Часто слышу мнение “не хочу выступать, не знаю, что рассказать в докладе”. Я убежден, что найти тему для доклада может практически любой человек. И может этот доклад и не будет звездой конференции, которую потом друг другу пересказывают, но это будет крепкий нормальный доклад. (Оставим пока в стороне вопрос “зачем выступать с докладом”, это отдельная тема).Если не знаешь про что рассказать, есть четыре беспроигрышных подхода.
1. Как мы решили проблему. Берем проблему, чем страшнее, тем лучше. Было все плохо, стало норм. Расскажу как это сделали.
2. Как мы достигли классной цели. Берем классную цель, которую в прошлом себе поставили. Старались-старались, половина усилий мимо, но наконец достигли. Расскажу про тернистый путь.
3. Про одну крутую идею. У меня есть классная идея или принцип. Я ее выдумал или прочитал в книге. Все должны про него знать, но еще не знают. Расскажу про эту одну идею и почему она важна.
4. Как мы делаем что-то. У нас есть процесс или подход, который интересный или просто неплохой. Вот мы делаем так и этак, пробовали по разному, а вот так получается лучше всего. Расскажу про детали процесса и как мы эту штуку делаем.
Конечно рассказать можно еще про много чего, но если в голову ничего не приходит для рассказа другим, то надо просто задать себе вопросы:
- Была ли какая-то проблема или челлендж, которую я решил?
- Была ли какая-то интересная цель, которую я достиг?
- Есть ли какой-то процесс, принцип, подход или идея, которые я считаю правильной и другим стоит о нем знать?
Ответ на эти вопросы сразу задаст тему для доклада, которую, просто в силу структуры, будет просто оформить в рассказ.
Большая подробная интересная статья про истории переписывания с нуля нескольких продуктов “Lessons from 6 software rewrite stories”: https://medium.com/@herbcaudill/lessons-from-6-software-rewrite-stories-635e4c8f7c22Есть распространненное мнение, что подход “а давайте все к чертям перепишем с нуля и после этого ЗАЖИВЕМ” ошибочен и приводит к фейлам. В статье на разных примерах показывается когда это так и когда это (иногда) не так.
Переписывание всего к чертям с нуля проблемно по следующим причинам:
- Это очень сложно для успешного сформировавшегося продукта. Переписать с нуля с сохранением существующей функциональности это как правило сложнее, чем просто создать. Надо сохранить все особенности, обходные пути, баг-фиксы, которые появились за годы и про которые уже все забыли. Поэтому такие проекты очень долгие, вязкие, выматывающие.
- Пока переписываешь продукт, ты его не улучшаешь. После такого большого проекта ты оказываешься с потраченным временем и — почти — тем же самым продуктом. Пользователь видит, что ты долгое время его не развивал и в конце концов показал то же самое, если не хуже (новые баги, а часть вещей решили не переимлементировать для скорости).
- Убеждение, что если все переписать, то это волшебным способом решит все проблемы у продукта очень часто ошибочно.
При этом я видел и успешные кейсы. Например вот недавно мы в Эквиде завершили большой проект, переписали с нуля критически-важную часть продукта. Это заняло где-то 4 человеко-года. Для нас хорошо сработали две штуки:
- Разбили проект на части и релизили отдельно. Каждая часть занимала где-то 3-4 календарных месяца от начала работа до релиза. Это позволило иметь темп, видеть постоянный прогресс и не вязнуть.
- Мы не только поменяли технологию этой штуки, но и перепридумали дизайн с учетом опыта за прошедшие года. Так как дизайн там важен, то пользователи сразу видели ценность после выпуска каждой части проекта, не было “внутри все поменялось, а пользователь разницы не видит”.
Два момента особенно запомнились.
Cоздание ценности или защита ценности (value creating or value protecting)? Каждая роль может требовать или создания ценности или сохранения ее. Важно понимать, кто конкретно нужен вам для конкретной роли и понимать, что для этого нужны ребята с разными способностями. Для создания ценности нужен человек, готовый идти на риск и принимать неопределенность, умение пройти полный путь от идеи к ее реализации, а вот предыдущий опыт не важен. Для защиты ценности важен хороший предыдущий опыт в области в которой надо будет работать.
Критерий эффективности сотрудника: “Effective executives need to be able to take things off your plate, not add to it.”.
→ Lorem ipsum? Dolor sit amet! Рассказ про интерфейсный контент и дизайн
Хитрость от Литреса: большая кнопка “Хочу получать рассылку реже” в подвале письма. То есть они в середине пути, который ведет к негативным для них последствиям, предлагают заметную альтернативу, которая частично решает проблему/задачу пользователя, но последствия не такие негативные.Ну то есть кто-то устал от частых писем и хочет отписаться. По привычке ищет ссылку в футере. А ему говорят, погоди — может просто пореже тебе их слать, а то вдруг все таки что-то хорошее пропустишь. Кто точно хочет отписаться — отпишется и так (ссылка там есть, хоть и менее заметная). Кто сомневается — останется на более редкой рассылке (а не уйдет совсем, как было бы с одной ссылкой Unsibscribe)
