Подглядывание в 🆎 тестах. Я ошибся, я могу один раз ошибиться?

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

В чем основная суть?

Предположим, мы запустили эксперимент, который должен идти 14 дней (так мы определили по дизайну). Возьмем для примера базовый t-test для двух выборок.

Вдруг мы решили посмотреть на результаты, видим значимое изменение. По сути (если мы знаем формулу для t-test'а или другого статистического критерия), накопительно на каждый день можем посчитать статистику и увидеть, что, например, в 4 день (ладно-ладно, в 7), мы увидели значимое изменение. Пришла в голову гениальная мысль отрубить тест и экстраполировать выводы, но так, очевидно делать нельзя, и вот почему:

1. Мы рассчитывали сроки эксперимента в зависимости от трафика. Чем меньше пользователей, тем сильнее шум.
2. Доверительный интервал получается весьма широким, мы можем не до конца быть уверенными в эффекте (та же история может случиться и в обратную сторону, p-value от статистики (например, разницы средних) может "отскочить" от промежутка (0, alpha). Если бы мы подсмотрели, мы сделали неправильное решение.
3. На симуляциях мы повышаем ошибку первого рода (FPR) достаточно сильно. Подглядывание даже может имитировать подбрасывание монетки (по факту, мы проверяем несколько гипотез, что за 1, 2, 3, ... n день средние различаются, тем самым мы рискуем ошибиться. Подробнее можно посмотреть тут

Что можно посмотреть по этому поводу?

1. Статья от GoPractice..
2. Видео от Анатолия Карпова.
3. Пост от ProductSense на Facebook

Про это очень много есть статей + давно было интересно покопаться в проблеме подглядывания, например, ребята из Spotify использовали методы последовательного тестирования для досрочного принятия решения (чтобы не держать эксперимент какое-то время). История может быть актуальна, если мы хотим принимать правильные решения как можно чаще, а неправильные - сразу отрубать, чтобы не терять деньги во время теста. Также читал, что советуют обращаться к байесовскому тестированию, но давайте ко всему последовательно).

🐳🐳🐳 100 реакций на пост и разгоняем дальше 🐳🐳🐳

😏 Итоги года

🚶‍♂️ х2.2 подписчиков с начала года. Дальше - больше. Ставим таргет на х2 к концу следующего года.

😱 104 публикаций за год. Обещаю повысить эту цифру к следующему году, чтобы влиять на вовлеченность пользователей

🎄 Всем спасибо! Хороший выдался год! Желаю каждому карьерных успехов, интересных задач и сочных офферов

🐳 4.5к реакций за год? Интересно, можем ли сделать +2-3% к этой метрике?

😑 А что интересного случилось у вас за этот год? Пишите в комментариях

Как проводите новогодние праздники? Отдыхаете / обучаетесь / работаете?

Планирую в ближайшее время актуализировать роадмап + подкрепить средним временем прохождения пунктов / расписанием того, как все изучать, чтобы вкатиться (и не только вкатышам). Возможно, это будет в Figma / Miro с дальнейшей развилкой в ML, руководящие позиции. Если вам по-прежнему это интересно, накидайте очень много реакций, а я постараюсь сделать так, чтобы вы четко понимали как идет развитие / что нужно дополнительно изучить + рассмотрю варианты как можно качаться внутри команды, чтобы дорасти еще выше.

Как я вижу для себя:

1. Сделать для новичков
2. Сделать для продолжающих (а как можно расти еще быстрее, что нужно делать, чтобы расти)
3. Объединить несколько форматов.

Все зависит от вас! Ставьте много 🐳(200?) и я начну двигаться к разработке данного формата.

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

https://t.iss.one/boost/zasql_python

Недавно наткнулся на подкаст, где обсуждалась важная тема для аналитиков. Там говорили о том, что всех аналитиков условно можно разделить на две категории: “аналитики-калькуляторы” и “аналитики-партнеры”. Захотелось поделиться своими мыслями.

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

🍪 🍪 Аналитики-партнеры - это уже другой уровень. Они не просто считают и отдают результаты, а берут на себя ответственность за влияние этих данных на бизнес. Они понимают, для чего нужны те или иные задачи, предлагают решения, которые не только закрывают запросы, но и приносят реальную пользу. Здесь уже важны не только технические навыки, но и способность общаться, правильно доносить идеи до людей из разных отделов, выбирать подход к каждому, чтобы убедить в правильности решений. Это те, кто видят шире, чем просто таска.

Как вырасти до аналитика-партнера? [мое мнение]

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

2️⃣ Адаптация коммуникации. Мы часто забываем, что общаемся с людьми, которые могут не знать, что такое p-value или зачем ты используешь тот или иной метод. Людям из бизнеса важно понимать результат: как это повлияет на их задачи, принесет ли прибыль или решит проблему. Умение говорить на языке разных команд - аналитиков, маркетинга, продукта - это ключ к тому, чтобы становиться партнером.

3️⃣ Активная позиция и фильтрация задач. Когда задач много, важно понимать, какие из них действительно решают проблему, а какие - просто затыкают дыру в имеющемся процессе. Аналитик-партнер не просто выполняет запланированные таски, а задает вопросы: “А это точно решит проблему?”, “Какое влияние это окажет?”, “Можно ли сделать проще или эффективнее?”. При этом нужно уметь фильтровать входящие запросы. Не все задачи стоит брать в работу, но те, которые ты принимаешь, важно выполнять так, чтобы не пришлось переделывать или добавлять правки. Инициативность здесь тоже играет роль: иногда ты можешь предложить свой вариант решения, который окажется лучше исходного.

4️⃣ Учиться у тех, кто уже разбирается в области. Коллеги, которые давно работают в компании или просто сильнее тебя в каких-то аспектах, – это ценный источник знаний. Если ты не понимаешь, как работает тот или иной процесс, не бойся задавать вопросы. Работать в паре над задачами – это тоже хороший способ быстрее разбираться в сложных темах.

Что думаете, корректно ли делить аналитиков именно так? Конечно, есть те, кто работает исключительно в операционной зоне, и это тоже важная часть. Но здесь речь именно про тех аналитиков, которые могут влиять на развитие бизнеса своими инициативами. Если интересно, ставьте 1️⃣0️⃣0️⃣ реакций (завез еще кастомные), и я разберу что-нибудь ещё - подкаст, статью или, может быть, ваш запрос. А в комментариях будет круто почитать ваши мысли, делитесь!

Заскулил питона at the gym

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

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

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

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

Вечером обычно ходит много людей и тренировка может заканчиваться в 22-23, остается только доехать до дома и ночью(либо в течение дня) находить свободное время для изучения нового

А как вы совмещаете хобби с работой?
Поделитесь своим опытом?

#личнаяжизнь@zasql_python

Как считать пенетрацию пользователей в продукте на SQL?

🎮 В сервисе у нас есть чарт, характеризующий количество пользователей в сервисе (MAU / DAU / WAU), мы смотрим за определенный промежуток времени количество пользователей. Этот график интуитивно понятен, есть практически во всех продуктах и является одной из тех метрик, которую отслеживают.

Тут достаточно понятно, берем группировку по дням / неделям / месяцам, считаем уникальных пользователей в приложении и готово!

❓ Пенетрация позволяет ответить на вопрос: "Сколько всего пользователей пользуются продуктом в динамике?". В сервисе есть старички, которые регулярно продукт используют и за время мы их учитываем несколько раз (по дням). Мы можем взять весь год и посмотреть сколько всего пользователей использовали фичу X и посчитать статично, найти долю и все. Но хочется понимать как инициативы влияют на абсолютные значения / доли относительно всех пользователей продукта до момента T.

WITH daily_users AS (
    SELECT 
        event_date,
        user_id
    FROM user_events
    WHERE event_date BETWEEN '2024-01-01' AND '2024-01-30'
),
date_series AS (
    SELECT DISTINCT event_date 
    FROM daily_users
),
cumulative_users AS (
    SELECT 
        d.event_date,
        COUNT(DISTINCT u.user_id) AS cumulative_unique_users
    FROM date_series d
    LEFT JOIN daily_users u ON u.event_date <= d.event_date
    GROUP BY d.event_date
    ORDER BY d.event_date
)
SELECT * FROM cumulative_users;

⬆️ Выше представлен скрипт, который считает накопительно пользователей по дням, теперь мы можем это применить для ответа на вопрос: "Какой процент пользователей когда-либо использовал продукт на момент времени T?". Это нам может быть нужно для отслеживания доли использования от всей аудитории накопительно. Мы можем более явно отслеживать как наша база (в тотале) реагирует по дням, когда мы используем какие-то механики, например, или запускаем новые фичи

WITH daily_feature_users AS (
    SELECT 
        event_date,
        user_id
    FROM user_events
    WHERE event_name = 'feature_x' 
      AND event_date BETWEEN '2024-01-01' AND '2024-01-30'
),
daily_total_users AS (
    SELECT 
        event_date,
        user_id
    FROM user_events
    WHERE event_date BETWEEN '2024-01-01' AND '2024-01-30'
),
date_series AS (
    SELECT DISTINCT event_date 
    FROM daily_total_users
),
cumulative_feature_users AS (
    SELECT 
        d.event_date,
        COUNT(DISTINCT u.user_id) AS cumulative_feature_users
    FROM date_series d
    LEFT JOIN daily_feature_users u ON u.event_date <= d.event_date
    GROUP BY d.event_date
    ORDER BY d.event_date
),
cumulative_total_users AS (
    SELECT 
        d.event_date,
        COUNT(DISTINCT u.user_id) AS cumulative_total_users
    FROM date_series d
    LEFT JOIN daily_total_users u ON u.event_date <= d.event_date
    GROUP BY d.event_date
    ORDER BY d.event_date
)
SELECT 
    cfu.event_date,
    cfu.cumulative_feature_users,
    ctu.cumulative_total_users,
    ROUND(100.0 * cfu.cumulative_feature_users / (ctu.cumulative_total_users, 0), 2) AS penetration_rate
FROM cumulative_feature_users cfu
JOIN cumulative_total_users ctu ON cfu.event_date = ctu.event_date
ORDER BY cfu.event_date;

⬆️ Выше представлен код, как мы считае долю тех, кто использовал фичу относительно всех пользователей до момента T.

🐖 Используете ли вы пенетрацию для отслеживания доли относительно всех пользователей? Был ли этот пост полезен? Ставьте 100 🐳 и я выложу еще что-нибудь по этой тематике)

Когда дашборд превращается в хаос

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

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

___________________________

Как сделать дашборд, который реально нужен бизнесу?

Частая ошибка: не уточнить контекст задачи. Получил запрос, построил отчёт, принёс и тут начинаются уточнения:

“А это для выгрузок или для ежедневного контроля?”

“Нам вообще-то важен срез по регионам, почему его нет? А по приложениям? Точкам входа в продукт?”

“А где сравнение с прошлым месяцем?”

"А нам еще важно следить за этим, сделаешь парочку графиков?

"Смежникам важно смотреть на это, а давай еще сделаем так: на одной вкладке будет общая информация, а на второй возможность для финансов грепнуть

(вопросов может быть много)

1. Почему так произошло?

Не зафиксировали цель дашборда. Какую проблему позволяет решить данный дашборд?

Не проверили, а покрывает ли эту задачу существующая отчётность?

Не уточнили, какие срезы реально важны. Заказчик сам может не знать, пока не увидит готовый отчёт.

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

2. Как избежать переделок?

1️⃣ Сначала обсуждать контекст задачи. Зачем решили делать этот отчёт именно сейчас?

2️⃣ Формулировать основные показатели заранее. Бизнесу нужна конкретика, а не “что-нибудь полезное”.

3️⃣ Закладывать время на доработки, но минимизировать их за счёт хорошего брифинга на старте. Каждую отчетность важно документировать и подсветить основным пользователям за что он отвечает и почему он выглядит именно так.

4️⃣ Понять, кто будет пользоваться дашбордом. Одним важно смотреть верхнеуровнево, другим необходима детализация

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

Было у вас такое, что делали сложный отчёт, а потом оказалось, что его никто не смотрит или вы постоянно вносили в него правки? Делитесь в комментариях!
Понравился формат? Ставьте 🐳, буду рассказывать подробнее с чем сталкивался и чего бы я не хотел допускать в будущем.

🤩 Увидел, что у телеграма есть фича: отправить "Когда будет в сети" (испытан a-ha момент, поэтому с запозданием + практически никто не показывает, что он в сети, поэтому…).

Интересно, как это работает на тех, кто поставил статус "был(а) недавно".

(никак, на них не влияет)

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

Если это катилось с экспериментом, то какие бы вы предложили метрики для эксперимента? Пишите в комментариях!

😏 А вы уже успели пощупать? Видите ли плюс от этой фичи?

🔥 Ухудшающие A/B-тесты: зачем ломать продукт ради роста?

В мире продуктовой аналитики A/B-тесты обычно ассоциируются с улучшением продукта (или его неухудшением). Однако существует менее очевидный, но крайне полезный метод — ухудшающие A/B-тесты. Давайте разберём, что это такое, зачем их проводят и какие преимущества они дают.

________________________

Что такое ухудшающие A/B-тесты?

Ухудшающий A/B-тест — это эксперимент, в котором намеренно ухудшаются определённые характеристики продукта, чтобы оценить их влияние на ключевые метрики. Вместо того чтобы улучшать элемент и смотреть на рост показателей, мы ухудшаем его и наблюдаем за снижением. Это помогает понять, насколько сильно данный элемент влияет на пользовательский опыт и бизнес-результаты. Ухудшающие тесты планируется проводить на очень узкий срез аудитории, так как реакция пользователей может быть негативной на какое-то изменение. При дизайне (если есть какой-то единый процесс заведения A/B экспериментов, может тикет), нужно указать, что эксперимент является ухудшающим.

____________________

🤔 Зачем компании проводят ухудшающие A/B-тесты?

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

Экономия ресурсов. Прежде чем инвестировать в улучшение определённой функции, стоит понять, насколько она влияет на метрики. Если ухудшение не приводит к значимым изменениям, возможно, улучшение не принесёт ожидаемой отдачи. За внедрение фичи отвечают 4 лица: менеджер, дизайнер, аналитик и разработчик.

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

____________________

😡 Пример применения

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

Гипотеза: Замедление работы приложения негативно повлияет на метрики.

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

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

____________________

🤬 Почему не использовать глобальный контроль?

Глобальный контроль подразумевает наличие постоянной контрольной группы, которая не подвергается изменениям, для сравнения с тестовыми группами. Однако такой подход не всегда позволяет выявить влияние конкретных характеристик продукта. Ухудшающие A/B-тесты дают возможность точечно оценить значимость отдельных элементов, что особенно полезно при ограниченных ресурсах и необходимости быстрой проверки гипотез.
____________________

Про пользу ухудшающих тестов в статье Авито

Метрики перформанса могут влиять и на продуктовые показатели. К такому выводу мы пришли после проведения ухудшающих тестов.

Про ухудшающие A/B тесты

📺 link1, link2
🔗 link3

А вы проводили ухудшающий эксперимент? Что проверяли? Наберется 100 🐳, выложу посты про стенды метрик, используемые при анализе результатов A/B экспериментов

Реально на мои апельсинки 🍊 кто-то позарился? Или кто-то пытается их мне втюхать?

Как относитесь к таким пушам? Заставляют ли они вас более активно реагировать на них или вообще все равно?

Пользуемся продуктом (или собираем фидбек) для генерации новых гипотез

Если ты сам не пользуешься продуктом, многое ускользает. По факту на основе данных мы отвечаем на вопрос: «Что случилось?»

Ты не замечаешь очевидных неудобств, которые мешают пользователям. Ты видишь, что на этапе оплаты большой отток. Анализируешь данные, проверяешь A/B-тесты, но не находишь явной причины. А если бы ты попробовал оплатить заказ сам, то заметил бы, что в мобильной версии кнопка “Оплатить” уходит за границы экрана.

Данные могут показывать проблему, но не её причину. Например, ты понимаешь, что время нахождения на странице сильно меньше, чем ожидается (мы считаем, что просмотр контента этой страницы улучшает бизнес-показатели). Проблема могла быть с тем, что очень много текста, непонятное содержание страницы, техническая ошибка и т.д. Хорошее правило с ошибками: «Если воспроизводится у двух и более людей, значит проблема глобальная».

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

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

[Я понимаю, что для разных аналитиков в разных продуктах по-разному. Мы можем по факту и не трогать продукт, а получать фидбек по нему на основе обращений в саппорт или качественных исследований по интересующему направлению]

Ставьте реакции ❤️, если пост понравился, пишите комментарии.

А вы тестируете продукт, который анализируете? Как часто замечаете проблемы, которые не видно в метриках?

Материалы для прокачки навыков в pandas для начинающих 🐼 [ч. 1]

Хотите прокачаться в pandas, но не знаете, с чего начать? Собрал полезные инструменты, шпаргалки и ресурсы, которые помогут вам разобраться во всем шаг за шагом!

Можно основные операции потыкать на этом сайте (сводные таблицы, join'ы, сортировки и др.)

Есть официальная документация с быстрым стартом (как устроены данные, как создавать чарты, сводники)

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

У Яндекс Образования в курсе по Python: блок по pandas

Шпаргалки по pandas (если нужно освежить быстро в памяти):

1. link1
2. link2
3. в одном PDF, во втором PDF, в третьем PDF

Была ли вам интересна подборка? Какие материалы помогли вам лучше всего разобраться в pandas? Делитесь в комментариях! А если пост соберёт 100 реакций, выложу следующую подборку с практическими задачами 😏

#дляначинающих@zasql_python

UPD:
https://dfedorov.spb.ru/pandas/

Сеньор под прикрытием 😂

Ссылка на пост в LinkedIn

Формирование пользовательской привычки: почему одни продукты входят в повседневность, а другие нет?

Недавно наткнулся на интересную концепцию из книги Hooked от Нира Эяля.

Суть в том, что привычные продукты формируются на пересечении двух факторов:

1. Частоты использования – чем чаще мы совершаем действие, тем быстрее оно закрепляется
2. Воспринимаемой ценности – насколько полезным это кажется пользователю

🔍 Google – высокая частота использования, люди ищут информацию каждый день, поэтому привычка сформирована
🚔 Amazon – покупки совершаются реже, но воспринимаемая ценность высокая, поэтому пользователи возвращаются

Что здесь важно понимать?

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

Если продукт используется нечасто, но его воспринимаемая ценность огромна (например, Airbnb), пользователи всё равно возвращаются
Не всегда можно просто "увеличить частоту" – если пользователю не нужна ежедневная покупка товаров, пытаться формировать привычку через увеличение касаний может быть бесполезно

Как это применимо к продуктам и аналитике?

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

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

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

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

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

1️⃣ Работа в долгосрок

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

If it helps in the short-term, but hurts Duolingo in the long-term, it’s not right

2️⃣ Культура экспериментов: быстрые A/B тесты вместо долгих споров

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

When we disagree, we test ideas and let the metrics decide.

3️⃣ Минимизация промежутков между действиями (Clock Speed)

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

Duolingo сокращает все простои

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

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

4️⃣ Простота в продукте и фокус на миссии

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

Learners need to get utility out of whatever we’ve built. Otherwise, we’ve made something that adds more complexity to the app and distracts learners from what they’re here to do.

Every feature we ship must be intuitive, delightful, useful, and polished.

If a feature or screen requires explanation or additional context, it’s not right.

5️⃣ Радикальные идеи приветствуются — «99 Bad Ideas»

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

Some of our best features and campaigns have come from asking ridiculous, unlikely questions

6️⃣ Меньше говорить, больше делать

> TL;DR-культура — вместо долгих обсуждений краткое выжимка из сути проблемы и решения.
> Говорить меньше — показывать больше (на примере прототипов).
> Когда в компании нет лишнего шума, решения принимаются быстрее.

Talking about ideas is rarely as effective as building them

7️⃣ Высокие планка: от команды до продукта

Duolingo строит культуру превосходства. Здесь ожидают, что сотрудники будут делать лучшую работу в своей карьере. Они не боятся ошибок, но главное правило — не обвинять, а разбираться в причинах:

We don’t chase blame. We dig in and figure out what happened. This is how we continuously raise the bar—not by being perfect, but by being a little bit better each day.

Жесткие стандарты качества в продукте: Всё должно быть полезным, интуитивным, восхитительным и продуманным. Если фича требует пояснений — она сделана неправильно. Никаких избыточных функций и сложностей.

Темп + ориентация на долгосрок + простой UI = <3

🐳🐳🐳 А вы что думаете? Пишите в комментариях, ставьте реакции!