No Data No Growth | Pavel Bukhtik
رفتن به کانال در Telegram
О карьерном росте при работе с данными и развитии аналитической культуры в компаниях. РКН: №5218310250 Менторю специалистов и руководителей продуктовых компаний. Для связи: @pbukhtik
نمایش بیشتر📈 تحلیل کانال تلگرام No Data No Growth | Pavel Bukhtik
کانال No Data No Growth | Pavel Bukhtik (@nodatanogrowth) در بخش زبانی روسی بازیگری فعال است. در حال حاضر جامعه شامل 12 799 مشترک است و جایگاه 5 447 را در دسته تجارت و رتبه 50 536 را در منطقه روسيا دارد.
📊 شاخص‌های مخاطب و پویایی
از زمان ایجاد در невідомо، پروژه رشد سریعی داشته و 12 799 مشترک جذب کرده است.
بر اساس آخرین داده‌ها در تاریخ 25 اکتبر, 2026، کانال فعالیت پایداری دارد. در ۳۰ روز گذشته تغییر اعضا برابر 35 و در ۲۴ ساعت گذشته برابر 3 بوده و همچنان دسترسی گسترده‌ای حفظ شده است.
- وضعیت تأیید: تأیید نشده
- نرخ تعامل (ER): میانگین تعامل مخاطب 26.16% است و در ۲۴ ساعت نخست پس از انتشار، محتوا معمولاً 12.88% واکنش نسبت به کل مشترکان کسب می‌کند.
- دسترسی پست‌ها: هر پست به طور میانگین 3 348 بازدید دریافت می‌کند. در اولین روز معمولاً 1 648 بازدید جمع‌آوری می‌شود.
- واکنش‌ها و تعامل: مخاطبان به‌طور فعال حمایت می‌کنند؛ میانگین واکنش به هر پست 34 است.
- علایق موضوعی: محتوا بر موضوعات کلیدی مانند метрика, собеседование, лифт, sql, сегмент تمرکز دارد.
📝 توضیح و سیاست محتوایی
نویسنده این فضا را محل بیان دیدگاه‌های شخصی توصیف می‌کند:
“О карьерном росте при работе с данными и развитии аналитической культуры в компаниях. РКН: №5218310250
Менторю специалистов и руководителей продуктовых компаний.
Для связи: @pbukhtik”
به لطف به‌روزرسانی‌های پرتکرار (آخرین داده در تاریخ 26 اکتبر, 2026)، کانال همواره به‌روز و دارای دسترسی بالاست. تحلیل‌ها نشان می‌دهد مخاطبان به‌طور فعال با محتوا تعامل دارند و آن را به نقطه اثرگذاری مهم در دسته تجارت تبدیل کرده‌اند.
12 799
مشترکین
+324 ساعت
+137 روز
+3530 روز
در حال بارگذاری داده‌ها
کانال‌های مشابه
ابر برچسب‌ها
اشارات ورودی و خروجی
---
---
---
---
---
---
جذب مشترکین
اکتبر '26اکتبر '26
اکتبر '26
+105
در 0 کانال‌ها
سپتامبر '26
+111
در 0 کانال‌ها
Get PRO
اوت '26
+164
در 0 کانال‌ها
Get PRO
ژوئیه '26
+153
در 0 کانال‌ها
Get PRO
ژوئن '26
+287
در 1 کانال‌ها
Get PRO
مه '26
+239
در 0 کانال‌ها
Get PRO
آوریل '26
+190
در 0 کانال‌ها
Get PRO
مارس '26
+230
در 1 کانال‌ها
Get PRO
فوریه '26
+296
در 2 کانال‌ها
Get PRO
ژانویه '26
+285
در 1 کانال‌ها
Get PRO
دسامبر '25
+250
در 2 کانال‌ها
Get PRO
نوامبر '25
+248
در 2 کانال‌ها
Get PRO
اکتبر '25
+278
در 0 کانال‌ها
Get PRO
سپتامبر '25
+234
در 2 کانال‌ها
Get PRO
اوت '25
+265
در 1 کانال‌ها
Get PRO
ژوئیه '25
+226
در 1 کانال‌ها
Get PRO
ژوئن '25
+281
در 0 کانال‌ها
Get PRO
مه '25
+247
در 1 کانال‌ها
Get PRO
آوریل '25
+339
در 0 کانال‌ها
Get PRO
مارس '25
+329
در 0 کانال‌ها
Get PRO
فوریه '25
+838
در 1 کانال‌ها
Get PRO
ژانویه '25
+568
در 1 کانال‌ها
Get PRO
دسامبر '24
+558
در 2 کانال‌ها
Get PRO
نوامبر '24
+351
در 0 کانال‌ها
Get PRO
اکتبر '24
+486
در 4 کانال‌ها
Get PRO
سپتامبر '24
+518
در 4 کانال‌ها
Get PRO
اوت '24
+375
در 2 کانال‌ها
Get PRO
ژوئیه '24
+2 169
در 0 کانال‌ها
Get PRO
ژوئن '24
+1 285
در 4 کانال‌ها
Get PRO
مه '24
+319
در 1 کانال‌ها
Get PRO
آوریل '24
+460
در 1 کانال‌ها
Get PRO
مارس '24
+437
در 5 کانال‌ها
Get PRO
فوریه '24
+774
در 1 کانال‌ها
Get PRO
ژانویه '24
+440
در 3 کانال‌ها
Get PRO
دسامبر '23
+197
در 1 کانال‌ها
Get PRO
نوامبر '23
+182
در 1 کانال‌ها
Get PRO
اکتبر '23
+292
در 0 کانال‌ها
Get PRO
سپتامبر '23
+226
در 0 کانال‌ها
Get PRO
اوت '23
+246
در 0 کانال‌ها
Get PRO
ژوئیه '23
+260
در 0 کانال‌ها
Get PRO
ژوئن '23
+897
در 0 کانال‌ها
Get PRO
مه '23
+104
در 0 کانال‌ها
Get PRO
آوریل '23
+183
در 0 کانال‌ها
Get PRO
مارس '23
+182
در 0 کانال‌ها
Get PRO
فوریه '23
+765
در 0 کانال‌ها
| تاریخ | رشد مشترکین | اشارات | کانال‌ها | |
| 26 اکتبر | +2 | |||
| 25 اکتبر | +4 | |||
| 24 اکتبر | +5 | |||
| 23 اکتبر | +5 | |||
| 22 اکتبر | +3 | |||
| 21 اکتبر | +2 | |||
| 20 اکتبر | +2 | |||
| 19 اکتبر | +4 | |||
| 18 اکتبر | +2 | |||
| 17 اکتبر | +6 | |||
| 16 اکتبر | +4 | |||
| 15 اکتبر | +6 | |||
| 14 اکتبر | +5 | |||
| 13 اکتبر | +5 | |||
| 12 اکتبر | +2 | |||
| 11 اکتبر | +4 | |||
| 10 اکتبر | +5 | |||
| 09 اکتبر | +4 | |||
| 08 اکتبر | +9 | |||
| 07 اکتبر | +2 | |||
| 06 اکتبر | +5 | |||
| 05 اکتبر | +3 | |||
| 04 اکتبر | +5 | |||
| 03 اکتبر | +1 | |||
| 02 اکتبر | +5 | |||
| 01 اکتبر | +5 |
پست‌های کانال
📊 Ценность аналитика в мире AI
Еще пару лет назад умение писать сложные SQL запросы, строить ETL и витрины данных, разрабатывать Python библиотеки для автоматизации A/B было конкурентным преимуществом аналитика.
Сегодня AI заметно снизил порог входа в эти задачи. И дальше техническая реализация будет становиться только доступнее.
Но остается навык, ценность которого на этом фоне только растет. Это умение проверять гипотезы и делать обоснованные выводы для принятия бизнес-решений.
Причем неважно, проводим мы классический A/B или оцениваем эффект изменений без эксперимента.
Ключевые вопросы остаются прежними:
-> Как отличить причинно-следственную связь от корреляции?
-> Какой дизайн эксперимента позволит корректно проверить гипотезу?
-> Каким результатам можно доверять, а какие могут вводить в заблуждение?
-> Как оценить эффект изменений, если провести A/B невозможно?
-> Какое решение принять с учетом полученных результатов и неопределённости?
AI может помочь написать код для CUPED, построить витрину или рассчитать доверительный интервал. Но корректность расчетов еще не гарантирует правильности выводов. Можно идеально посчитать эффект, которого на самом деле нет, или принять неверное решение на основе статистически значимого результата.
Поэтому, на мой взгляд, ценность аналитика все больше смещается от умения получать цифры к умению понимать, что за ними стоит, что они действительно доказывают и какие решения позволяют принять.
И даже при всей моей любви к техническим задачам, лично меня эта тенденция радует. Чем меньше времени уходит на рутинные инженерные задачи и бесконечные ad hoc запросы, тем больше его остается на работу с осязаемым результатом: проверку гипотез, исследования и поиск возможностей для роста бизнеса.
А как вам кажется, какие навыки аналитика станут наиболее ценными в ближайшие годы?
| 2 |  📐 Как связаны продвинутые методы в А/В и линейная регрессия?
Раньше я рассказывал, что A/B тест можно представить как линейную регрессию:
Yᵢ = β₀ + β₁Tᵢ + εᵢ
где β₀ – среднее значение метрики в контроле, β₁ – исследуемая разница между тестом и контролем.
Многие «продвинутые» методы в A/B являются продолжением этой же идеи. На картинке выше я показал, что добавляется в каждом методе и в чем его главная идея.
Если присмотреться, то мы добавляем информацию, которая помогает объяснить вариацию outcome, не связанную с treatment.
Задачу предсказания ожидаемого outcome по pre-treatment данным можно рассматривать как обычную ML задачу. А значит, нам открывается доступ ко всему ML инструментарию:
-> feature engineering по истории пользователя;
-> бустинги, нейросети и любые другие модели вместо одной pre-treatment метрики;
-> кросс-валидация и подбор гиперпараметров;
-> понятные метрики качества прогноза.
Чем больше вариации outcome, не связанной с treatment, мы объясняем, тем точнее измеряем сам treatment effect. | 3 014 |
| 3 | ❓ Сколько А/В ты провел?
Или самый бессмысленный вопрос на собеседовании.
Все чаще рекрутеры спрашивают: «Сколько А/В ты провел?» и ждут в ответ большую цифру.
По моим наблюдениям, ответ «до 6 А/В в год» почти гарантированно относит тебя к «недостаточно опытным». «Норм» начинается где-то от 12. И чем больше, тем лучше.
Забавно, что этот вопрос задают даже команды, где А/В нет и не будет. И свой же фильтр они бы не прошли.
Но главная проблема в другом: количество тестов почти ничего не говорит об уровне специалиста.
-> Можно штамповать десятки А/В на маркетинговые рассылки;
-> Можно раз в две недели менять блоки местами или перекрашивать кнопки, а итоги за тебя посчитает А/В-платформа;
-> Можно раз в месяц проводить один выверенный тест на крупное изменение продукта;
-> Можно раз в квартал запускать квази-эксперимент с гео-делением или switchback для работы с сетевым эффектом;
-> А можно полгода ждать, пока докатится B2B-тест.
У первых двух цифра будет ощутимо больше. Но делает ли это специалиста сильнее? Ответ очевиден.
Правильный вопрос звучит иначе:
«Расскажите про самый сложный эксперимент. С чем столкнулись и как решали?»
Поэтому не оправдывайся цифрой перед рекрутером, который пытается измерить твою экспертизу количеством тестов. Переверни разговор:
«Эксперимент эксперименту рознь. Задайте мне любой методологический вопрос по А/В, и я развернуто на него отвечу».
Но этот ход работает, только если ты действительно уверен в своих знаниях. Иначе блеф вскроется на втором уточняющем вопросе.
А чтобы не блефовать, приходи на мой практический курс по А/В-тестированию. Старт – 2 ноября.
На нем разбираем все, от классических А/В до сложных дизайнов: квази-эксперименты, switchback, тесты в B2B, ускорение тестов. Все на реальных продуктовых кейсах и с разбором ошибок, которые ломают выводы.
После курса тебе будет сложно найти вопрос по А/В, на который ты не сможешь содержательно ответить. Ни на собеседовании, ни в споре с продактом.
🔗 Оставляй заявку: https://nodatanogrowth.com/product-analyst-ab-testing | 3 265 |
| 4 | 🚪 Почему я закрыл свой последний pet project и какие 5 уроков из этого вынес
Год назад я писал про SkillBeast, micro-learning сервис для прокачки хард-скиллов (раз, два, три). Мы сделали несколько версий, исправили баги на закрытой бете и публично запустились. А потом проект довольно быстро перестал существовать как отдельный продукт.
Мне долго не хотелось об этом писать. Про успехи все-таки писать проще и приятнее. Но выводы из этой истории оказались для меня полезнее самого проекта. Делюсь ими тезисно.
1️⃣ Думать о тайминге
Когда SkillBeast начинался, vibe coding только зарождался. Сейчас за пару дней можно собрать то, на что раньше у целой команды уходили месяцы.
Порог входа в разработку резко упал. Но появился другой риск. Теперь стоит думать не только «Сможем ли мы это реализовать?», но и «Не станет ли это через полгода функцией ChatGPT или Claude?».
Порой проще просто подождать следующую версию модели.
2️⃣ Не собирать команду на энтузиазме
Я уже знал, что это плохая идея, но снова наступил на те же грабли.
Разработчик, которому я доверял, предложил сделать проект бесплатно, ради опыта. Я согласился. В итоге разработка превратилась в долгострой. И ровно в день запуска он объявил, что уходит заниматься своими идеями. От денег и доли в проекте он отказался.
Если нужен конкретный результат, зачастую проще сразу нанять человека за деньги, чем собирать команду на энтузиазме.
3️⃣ Не решать за пользователя
Я придумал механику, где открывался один кейс в день. А пользователи хотели открыть все сразу и проходить в своем темпе.
Причем ограничение было удобно в первую очередь нам. Для максимального качества кейсы составлялись вручную. На старте контента было мало. Но мы превратили свою внутреннюю проблему в продуктовую механику.
По сути, MVP должен проверять ключевые риски, а не показывать, что продукт можно сделать. Мы много думали про интерфейс и механики, а главный вопрос был проще: будут ли люди возвращаться и платить?
И показательно, что проблемы с Retention появились уже на теплой аудитории, которая знала меня и хотела дать продукту шанс. А теплая аудитория еще не рынок. На холодной все было бы еще веселее.
4️⃣ Считать экономику заранее
Я люблю считать unit-экономику. И многие свои идеи отсекаю еще до разработки.
Со SkillBeast я решил дать себе больше свободы, т. к. видел это как часть текущих механик обучения. Масштабных планов на продукт не было, хоть мысли такие и проскальзывали.
А когда появились первые цифры, стало понятно, что для самодостаточного продукта работы еще очень много.
Можно было генерировать контент через LLM, подкручивать механики, оптимизировать воронку. Но, честно говоря, мне не хотелось это чинить.
5️⃣ Проверять founder-market fit
Пожалуй, главная причина закрытия – я потерял интерес. Мне разонравилась сама идея продукта.
Да, может, стоило поднажать: найти нового разработчика, попробовать новые решения, дать проекту еще полгода. Но я почувствовал, что не хочу больше доказывать, что эта идея должна сработать. Хочу просто ее отпустить.
И отпустил. И ни о чем не жалею.
Тогда я гораздо лучше понял смысл founder-market fit. Мало придумать решение, которое тебе нравится. Нужно хотеть много лет жить внутри решаемой проблемы. Со SkillBeast такого fit у меня больше не было.
—
Теперь мне стало понятнее, чего я хочу от следующего продукта: более острой боли, более высокого чека, более быстрого результата от использования продукта и влияния на доход пользователя. А еще работу с существующей потребностью вместо формирования новой привычки.
Отголоски SkillBeast теперь в личном кабинете новых потоков курса по A/B-тестированию. А для меня это хороший урок: важно не только уметь начать, но и вовремя отпустить.
Но, как говорится, кто не стучится, тому и не открывают. И я все еще хочу работать над своими идеями. Поэтому сейчас мы с женой готовимся к лаунчу совершенно нового продукта. И многие решения в нем появились именно благодаря ошибкам SkillBeast. | 3 687 |
| 5 | 🎱 Разбор задачи с собесов на шары и перегородки
Задачи на чистую комбинаторику на собеседованиях встречаются редко. Обычно комбинаторика это составная часть задачи на теорвер.
Но есть один вид задач, которым любят подловить на собесе. Он выбивается из привычной схемы «сочетания / перестановки / размещения». И если сразу его не узнать, решить такую задачу крайне сложно.
Классическая формулировка звучит так:
Пусть имеется r одинаковых (неразличимых) предметов (шаров) и n различных (различимых) ящиков. Сколькими способами можно разложить все r шаров по n ящикам?
Но бывают и более замаскированные формулировки:
-> Бросаем 3 кубика. Сколько различных исходов без учета порядка?
-> Сколько неотрицательных целых решений у x₁+x₂+x₃=10?
Все это задачи на метод шаров и перегородок.
Узнать такую задачу можно по следующей конструкции: есть r одинаковых объектов, которые нужно распределить по n различимым "корзинкам". При этом важен только результат, т. е. сколько объектов оказалось в каждой корзинке.
У таких задач есть два подвида.
1️⃣ Пустых ящиков нет. Тогда ответ C(r-1, n-1).
2️⃣ Ящики могут быть пустыми: C(r+n-1, n-1).
Формулы можно просто запомнить. Но лучше понять интуицию за ними:
1️⃣ Без пустых ящиков. Выкладываем r шаров в ряд. Между ними есть r-1 промежутков, в которые нужно поставить n-1 перегородок. Итого C(r-1, n-1).
Причем не больше одной перегородки в промежуток, иначе появится пустой ящик. По той же причине нельзя ставить перегородки по краям.
2️⃣ С пустыми ящиками. Теперь перегородки могут стоять рядом и по краям.
Можно представить ряд из r+(n-1) позиций. Т. е. что у нас заготовлены ячейки под нужное количество шаров и перегородок. В каждой позиции должен стоять либо шар, либо перегородка. Выбираем n-1 позиций под перегородки, остальные заполняем шарами. Получаем C(r+n-1, n-1).
—
Попадались вам задачи на шары и перегородки на собеседованиях? Поставьте 🐳, если да. А если видите такую задачу впервые – 🔥.
И можете поделиться формулировками подобных задач в комментариях.) | 3 541 |
| 6 |  🔺 Как связаны бизнесовые, продуктовые и сервисные метрики?
Часто на метрики смотрят как на плоский список. Когда нужно выбрать ключевые, рядом оказываются Revenue, CR, SLA поддержки, среднее время доставки, Retention, NPS и еще десятки метрик.
Но мне кажется полезнее мыслить не списком, а уровнями. Например, можно выделить три крупных уровня:
1️⃣ Бизнесовые метрики
Это взгляд на компанию сверху: что происходит с бизнесом?
Чаще всего это условный P&L и деньги: выручка, темпы роста, прибыльность, юнит-экономика, запас денег.
То, на что C-level или инвестор может посмотреть и понять общее здоровье бизнеса, не погружаясь в поведение пользователей и операционку.
2️⃣ Продуктовые метрики
Это метрики пользователя на его жизненном пути в продукте. Здесь хорошо работает AAARRR:
Awareness → Acquisition → Activation → Revenue → Retention → Referral
То есть метрики, характеризующие этапы узнал → пришел → получил ценность → начал платить → остался → привел других.
Именно этот уровень чаще всего помогает объяснить, почему меняются бизнесовые показатели.
3️⃣ Сервисные метрики
Это метрики ежедневных операций, благодаря которым продукт вообще существует. Например: без дарксторов, курьеров и логистики приложение доставки – это просто приложение с кнопочками.
Сюда попадают метрики операционки, стабильности инфраструктуры, работы клиентских приложений и поддержки.
И здесь метрики сильнее всего зависят от индустрии и конкретного продукта.
—
Продуктовые аналитики чаще всего работают на уровне продуктовых метрик. Но он не существует сам по себе: сверху есть бизнесовый результат, а снизу процессы и сервисы, которые этот результат в том числе обеспечивают.
Классификация, конечно, нестрогая: одна и та же метрика может относиться к разным уровням, в зависимости от того, на какой вопрос мы ей отвечаем.
Мне нравится использовать такую пирамиду как способ мыслить о метриках чуть шире: понимать, на каком уровне есть точка роста или проблема и куда копать дальше.
Шпаргалку со всеми уровнями и примерами метрик собрал на картинке выше. Сохраняйте, пригодится. | 4 109 |
| 7 | 💸 Как мы «потеряли» деньги на опционах Miro
5 лет назад моя жена работала в Miro. Часть ее компенсации была в опционах. После ухода она решила их выкупить и оставить себе, потому что верила в компанию.
Продать такие акции в основном можно в двух случаях: IPO или продажа компании.
В 2022 году Miro привлекла раунд при оценке $17,5 млрд и начала усиливать команду людьми с опытом публичных компаний. Например, наняли Hollie Castro, которая до этого выводила на IPO YETI, следом появился первый CFO.
Для меня это был сигнал, что компания готовится к IPO. Но не случилось.
А недавно вышла новость, что Miro продается Bending Spoons. Сначала мы особо не придали этому значения. Скорее было жалко компанию и ее финальную оценку. А потом дошло: это же тот самый триггер для выплаты по акциям.
Только есть нюанс. Bending Spoons покупает Miro примерно за $1,8 млрд. Т. е. почти в 10 раз дешевле той самой оценки 2022 года. То есть ставка делалась на пике ожиданий вокруг компании, а продаваться акции будут уже сильно ниже той оценки.
Закрыть сделку обещают ближе к концу 2026-го. Тогда мы узнаем точную сумму. На иксы рассчитывать точно не приходится.) Хорошо, если вернется то, что заплатили за выкуп.
Эта история напомнила мне «Яндекс» в 2022-м. После остановки торгов на NASDAQ компания свернула программу RSU и предложила сотрудникам обменять их на денежные выплаты. При этом многие туда шли на оклад ниже рынка, рассчитывая добрать акциями, и после обвала котировок в итоге потеряли деньги.
И для меня это все хорошие примеры того, почему не стоит соглашаться на меньшую зарплату ради бонусов и equity.
Пока компания растет, их легко воспринимать как полноценную часть зарплаты. Но на самом деле это венчурная ставка с очень неопределенным исходом:
-> Компания может вырасти в десятки или сотни раз;
-> Может годами топтаться на месте;
-> Может размыть вашу долю новыми раундами;
-> Может продаться сильно дешевле последней оценки;
-> А может вообще закрыться, и тогда equity будет стоить ноль.
Поэтому мне нравится очень простое правило.
Если вам предлагают большие бонусы или equity вместо части оклада, мысленно вычеркните их из оффера и посмотрите, устраивает ли вас все остальное.
Если да, то отлично. Тогда акции становятся приятным бонусом сверху.
Если без них оффер выглядит слабым, я бы хорошо подумал, прежде чем менять реальные деньги сегодня на очень неопределенные деньги когда-нибудь потом.
Equity может изменить жизнь. Но пока нет ликвидности, лучше относиться к нему как к бонусу, который может выстрелить, а не как к части зарплаты. | 4 492 |
| 8 | 📦 Задача с собеседования про новые ПВЗ Ozon
Небольшой продуктовый кейс на сегодня.
«Представьте, что Ozon хочет расширять сеть ПВЗ. Как бы вы определяли гео, в которых компании стоит стимулировать открытие новых точек?»
Мне нравится эта задача тем, что она очень простая по формулировке, но довольно быстро разгоняется.
Какие данные вы запросите? Что и как будете считать? Как сравнивать гео между собой? И как поймете, что открытие нового ПВЗ действительно дало бизнесу инкрементальный эффект, а не просто перетянуло тех, кто и так заказывал?
Попробуйте набросать структуру решения так, как делали бы это на собеседовании.
Жду ваши рассуждения в комментариях 👇 | 4 582 |
| 9 | 👻 Что такое фантомная вакансия?
Иногда бывает так, что вакансия есть, но компания никого нанимать не собирается. При этом отклики могут обрабатываться и даже проводиться собесы. Такие вакансии называют фантомными.
Зачем они тогда вообще нужны? Причин на самом деле довольно много:
🔹 Разведка рынка. Нужно понять, есть ли такие специалисты и сколько денег хотят.
🔹 Поиск единорога. Позиция открыта бессрочно на случай, если придет идеальный кандидат за половину от рыночной вилки. Остальным отказ или молчание.
🔹 Сбор базы. Резюме уходят в пул «на будущее». Сейчас человек не нужен, а через три месяца может понадобиться.
🔹 Оправдание отсутствия найма. Компании нужно показать, что она честно ищет специалиста уже N месяцев и никак не может найти. Даже если это неправда.
🔹 Демонстрация роста. Большое количество открытых вакансий создает ощущение активно растущего бизнеса для кандидатов, инвесторов, конкурентов.
🔹 Давление внутри. Вакансия на роль, которую кто-то уже занимает. Этакий сигнал сотруднику, что он заменим.
🔹 Скрытая замена. Ищут преемника человеку, который еще не знает, что его увольняют.
🔹 Инерция. Вакансию заморозили, а объявление снять забыли.
🔹 Формальность. Кандидат уже выбран (внутренний перевод, знакомый, релокант), но по регламенту позицию обязаны опубликовать.
И список можно продолжать...
Что с этим делать?
Перестать относиться к каждой вакансии как к реальной возможности трудоустройства. Часть откликов может уходить в пустоту, потому что никакой вакансии и нет. Смотрите на поиск работы как на воронку. Важнее количество активных треков и конверсия по ним.
А если интересно узнать, как отличить фантомную вакансию от настоящей, то поддержите пост огоньком 🔥 | 4 409 |
| 10 |  🚀 Седьмой поток интенсива по собесам стартует в понедельник
Осталось 2 дня, чтобы присоединиться. Свободно 6 мест на Оптимальном и 1 на Менторстве с сопровождением до оффера.
Это последний поток по собесам, который я веду лично онлайн. Т. е. с теорией в Zoom, практикой и личной обратной связью. Следующий, уже в другом формате, будет не раньше февраля.
Также интенсив стал более интенсивным. Теперь программа занимает месяц вместо двух, без ущерба качеству. А внутри я добавил новые механики для отработки навыков.
Часть материалов переработана под реалии 2026 и мои прогнозы на 2027. Акцент всё больше смещается на продуктовые кейсы и кейсы на А/В. При этом не забываем про SQL, Python, мат. задачки и софты (подготовку резюме, самопрезентацию и поведенческие моменты).
Я уверен, что большая часть знаний у тебя уже есть. На интенсиве я помогаю собрать их в систему, закрыть пробелы и довести до выдающегося уровня на собесах. Также учимся решать задачи в нужном для собесов формате и под критерии, по которым тебя будут оценивать.
Если давно хотел подготовиться лично со мной и планируешь менять работу, оставляй заявку:
🔗 https://nodatanogrowth.com/product-analyst-interview
Созвонимся на 15 минут, разберу твою ситуацию и расскажу, как могу помочь.
Если не увижу реалистичного пути к росту дохода хотя бы на 30% – так и скажу. | 3 856 |
| 11 | 🛠 Как я чуть не стал девопсом
На первом месте работы я впитывал знания как губка.
Руководитель вечно пропадала на встречах. Зато рядом сидела аналитик, которая охотно делилась всем, что знала. Плюс десятки курсов, записи конференций и вылазки в соседний аналитический отдел.
Через год источники иссякли.
Но рядом оказались девопсы. Сначала я приходил к ним с рабочими задачами. Потом начал разбираться сам: ClickHouse, Docker, Kafka, Spark, Kubernetes, Terraform, AWS. Как раз тогда на меня свалилась перестройка аналитической инфраструктуры, и я нырнул туда с головой.
Однажды я поймал себя на мысли: может, мне интереснее строить системы, чем заниматься аналитикой?
Сейчас понимаю, что дело было не в аналитике. В той компании исследования уходили в стол, инициативы могли продвигаться годами, а результат твоей работы часто никому не был нужен.
В инфраструктуре все было наоборот. Сегодня ты чего-то не умеешь. Завтра разобрался. Послезавтра это работает на проде и приносит пользу.
Меня тянуло не в девопс. Меня тянуло туда, где я снова рос и видел, что моя работа что-то меняет.
Потом случился ковид, компания чуть не развалилась. Чуть позже я стал руководителем, и стало уже не до девопса.
Когда спустя время я вышел на рынок, то решил искать работу сразу по трем направлениям: продуктовый аналитик, руководитель и дата-инженер.
И довольно быстро понял, что это плохая стратегия. Когда претендуешь на три разные роли, в каждой конкурируешь с людьми, которые последние несколько лет занимались только этим. У меня сильнее всего была аналитика. Тогда я впервые по-настоящему почувствовал, сколько стоит накопленная глубина.
С тех пор я вижу две крайности у начинающих спецов:
1️⃣ Годами сидеть в профессии, которая давно не нравится. Чем позже решишься перейти, тем дороже будет смена направления. Часто придется откатиться по деньгам и уровню. Чем выше успел забраться, тем болезненнее этот откат.
2️⃣ Постоянно метаться. Год аналитиком, год дата-инженером, потом продактом, потом в ML. Ширина растет. Но не глубина. А сеньорные вилки обычно платят именно за глубину.
Но есть и третий путь. На ранних этапах пробовать как можно больше. Этаким стохастическим градиентным спуском нащупывать то, что действительно нравится. И менять роль только тогда, когда стало ясно: дело не в компании, не в руководителе и не в проекте. Тебе не нравится сама работа.
Как вы уже поняли, я остался в аналитике. Docker-контейнеры больше не собирал. Но время на инфраструктуру не пропало. Мне стало гораздо проще разговаривать с разработчиками и архитекторами. Позже, уже в роли руководителя, это постоянно выручало.
Девопсом я не стал. Но перестал быть аналитиком, с которым разработке тяжело. На длинной дистанции это оказалось ценнее.
–
Если сейчас тянет сменить направление, начните с одного вопроса: вам правда нравится другая профессия или просто на текущем месте закончился воздух?
Ощущения похожи, но решения разные. | 3 159 |
| 12 |  +5🔥 Эти 6 лайфхаков выведут твою подготовку к продуктовым кейсам на новый уровень
Кейсы часто заваливают не потому, что человек не знает, как их решать.
Просто на интервью нужно одновременно думать и говорить, структурно излагать мысль, укладываться во время и разбираться в продукте, который видишь впервые.
В карточках выше я описал 6 приемов, которые стоит применить в подготовке, чтобы выделиться на следующей продуктовой секции.
Начни с одного кейса уже сегодня: придумай его сам, поставь таймер, разбери вслух и запиши себя. Через неделю разницу будет слышно прямо на записи. | 3 230 |
| 13 | 🎯 Ты можешь быть сильнее того, кому дали оффер
Потому что на собеседовании оценивают не весь твой опыт.
Интервьюер не видел, как ты последние несколько лет тащил рабочие задачи, запускал А/В и драйвил продукт. У него есть примерно час, чтобы понять твой уровень по набору сигналов:
→ Как ты уточняешь задачу
→ Как рассуждаешь вслух
→ Как выбираешь подход
→ Замечаешь ли ограничения
→ Можешь ли понятно объяснить решение
Поэтому быть сильным аналитиком и хорошо проходить собеседования – это два разных навыка.
И здесь возникает главная ошибка. После отказа человек решает: «мне не хватает знаний». И снова идет пересматривать пройденные курсы по A/B, нарешивать продуктовые кейсы и задачки на кодинг.
Хотя знаний может быть достаточно. Просто дома ты спокойно решаешь задачу, а на интервью нужно одновременно думать, говорить вслух, реагировать на уточнения и укладываться во время. Это другой навык, и молча он не тренируется.
Готовиться стоит в том же формате, в котором тебя будут оценивать. Не решать задачи молча, а проходить их вживую – с таймером, слушателем и обратной связью.
Так устроен мой интенсив по подготовке к собеседованиям.
Сначала находим, где именно ломается твой путь до оффера. Потом закрываем пробелы и тренируем продуктовые кейсы, A/B, SQL, Python и математические задачи в формате реальных интервью. Финалим упаковкой резюме, позиционированием и подготовкой к переговорам об оффере.
Не чтобы выглядеть сильнее, чем ты есть. А чтобы твой реальный уровень наконец было видно.
Новый поток стартует уже 14 сентября. Осталось 9 мест.
Если ты планируешь менять работу или уже ходишь по собеседованиям, но не понимаешь, почему не доходишь до оффера – оставь заявку:
🔗 https://nodatanogrowth.com/product-analyst-interview
Созвонимся на 15 минут, я разберу твою ситуацию. Если увижу, что интенсив тебе не подходит – так и скажу. | 3 870 |
| 14 |  🔥 Полный гайд по собеседованиям на продуктового аналитика
Быть сильным аналитиком и уметь показать свой уровень на интервью – это два разных навыка. Первый развивается за счет рабочих задач. Второй почти никто специально не тренирует.
Поэтому даже опытный аналитик, который на работе тащит сложные проекты, приходит на собес и выглядит слабее, чем он есть на самом деле. А в фидбеке ему просто скажут «мы решили продолжить с другим кандидатом».
Я собрал в одно видео все, что обычно рассказываю по этой теме:
🔸 Как устроена воронка найма и в каких пяти точках вы можете терять оффер;
🔸 Почему привычная подготовка не дает результата и какие четыре ошибки заваливают даже сильных аналитиков;
🔸 Как собеседование выглядит со стороны интервьюера: что он пытается понять за час и почему правильного ответа недостаточно;
🔸 Как выстроить подготовку в систему из четырех шагов вместо того, чтобы учить все подряд;
🔸 И реальные кейсы, где это помогло найти слабое место и дойти до оффера.
🔗 Смотреть по ссылке: https://www.youtube.com/watch?v=yxjvGnrG0ao
—
14 сентября стартует новый поток моего интенсива по подготовке к собеседованиям. Поэтому сразу скажу: да, выход этого видео с ним связан.
Но сам гайд я специально сделал полноценным. Даже если вы не собираетесь идти на интенсив, по нему можно самостоятельно разобрать свою воронку, найти слабое место и перестроить подготовку.
А если после видео захотите посмотреть на свою ситуацию со стороны, в конце видео можно оставить заявку на бесплатное 15-минутное знакомство. Разберем, где именно сейчас ломается ваш поиск и как я могу помочь. | 4 529 |
| 15 |  +8💍 Я женился! 🥳
Как продуктовый аналитик, я, конечно, не мог спокойно жениться.
Сначала мне казалось, что свадьба устроена просто. Нужно выбрать красивую площадку, еду, декор, ведущего и не забыть прийти. Самая сложная часть, выбрать человека, с которым хочешь прожить жизнь, была уже позади.
Потом я понял, что свадьба очень похожа на запуск полноценного продукта без багов с первого раза. Тут есть привлечение, онбординг, CJM, сегментация пользователей, техподдержка, операционка и огромное количество странных пограничных кейсов.
📍Сначала появляется лендинг. Называется он «свадебный сайт-приглашение». На нем нужно объяснить Value Proposition: где, когда и зачем мы всех зовем. А еще что надеть. Иначе на фотографиях получится визуальный A/B-тест между «Дачная эстетика XX века» и «Я просто нашел что-то в шкафу».
📍Потом начинается регистрация. Казалось бы, что может быть сложного: имя, приедете ли, что пьете. Но довольно быстро начинается Enterprise UX:
-> А можно выбрать «Буду, но пока не уверен»?
-> А если я с +1, но +1 ещё не знает, что он +1?
-> А если я не пью, но на всякий случай выберу вино?
-> А если я пью все, можно поставить multi-select?
📍Дальше логистика. Нужно понять, кто откуда едет, кто точно едет, кто «скорее всего», кто «напомните мне за неделю», кто поедет сам, но потом всё равно спросит, где автобус. С расселением примерно то же самое.
📍А рассадка уже напоминает рекомендательную систему. Только вместо «похожие товары» у тебя задача подобрать людей, которые смогут просидеть рядом пять часов и не устроить инцидент на проде. Нужно учитывать родственников, друзей, интровертов, экстравертов, тех, кто знает вообще всех, и тех, кто пришел впервые и пока не до конца понимает, во что вписался.
📍 Декор выполняет роль UI. Если переборщить с цветами, пользователю негде поставить салат. Если переборщить со свечами, получится не романтика, а нагрузочное тестирование пожарной безопасности. Если сделать слишком много желтого, невеста может не принять релиз (а она в прошлом QA).
📍Программа вечера отвечает за Retention. Сначала welcome. Потом церемония, еда, активности, танцы. Главная задача: не перегреть пользователей в начале и не потерять аудиторию до торта.
📍Ведущий работает как Customer Success Manager. Он проводит пользователей по сценарию, разруливает баги, не дает никому захватить микрофон на 40 минут и вовремя возвращает всех в Core Flow.
📍Фотограф в этой системе выступает аналитиком поведения пользователей. Он фиксирует события, ловит ключевые конверсии, собирает данные по воронке эмоций, а потом отдает отчет примерно такого вида: «Вот здесь вы счастливые. А вот здесь кто-то уже нашел бар».
📍И, конечно, есть стейкхолдеры. Родители, гости, подрядчики и мы сами. У каждого свой Roadmap, свои Must-Have и свои скрытые ожидания, которые почему-то всплывают за неделю до релиза.
В какой-то момент понимаешь, что свадьба вообще не похожа на «один красивый день». Это кросс-функциональный запуск большой Agile-командой, которую ты сам же и собираешь.
Высокая эмоциональная ставка, ограниченный бюджет, жесткий дедлайн и нулевая возможность перенести релиз на следующий спринт.
И самое смешное, что в конце тебе уже совсем не нужна идеально работающая система. Хочется только, чтобы всем было уютно, красиво и вкусно.
После свадьбы провели с женой ретроспективу.
Критичных багов не выявлено.
Релиз признан успешным 🎉 | 5 913 |
| 16 | 🎲 Разбор задачи про три броска кубика
Напомню формулировку: кубик бросают три раза, какова вероятность, что дважды выпадет одно и то же число.
Правильный ответ – 5/12. Или 4/9? Может, 11/36? Или вообще 5/18?
На самом деле ни один из них. Правильный ответ – сначала уточнить условие, и только потом считать. Вероятность зависит от того, что именно имелось в виду.
Всего возможных исходов: 6³ = 216.
1) Ровно два одинаковых, третий отличается
-> Какое число повторится? Любое от 1 до 6 → 6 вариантов
-> В каких двух бросках? 3 пары позиций: (1,2), (1,3), (2,3) → 3
-> Что выпало в третьем? Любое из оставшихся 5 чисел → 5
6 × 3 × 5 = 90 → 90/216 = 5/12
2) Хотя бы два одинаковых (три тоже подходят)
Проще посчитать от обратного.
Все три разные: 6 × 5 × 4 = 120 (первый бросок – 6 вариантов, второй – 5, третий – 4). 120/216 = 5/9
Значит, хотя бы два одинаковых: 1 − 5/9 = 4/9
3) Ровно два одинаковых подряд, а третий отличается
Все как в первом случае, только повторяющиеся числа могут стоять лишь на соседних позициях: (1,2) или (2,3). Отсюда 2 вместо 3.
6 × 2 × 5 = 60 → 60/216 = 5/18
4) Хотя бы два одинаковых подряд
-> Вероятность совпадения бросков 1 и 2 – 1/6.
-> Совпадения бросков 2 и 3 – тоже 1/6.
-> Но случаи, когда совпали все три, мы посчитали дважды. Их вероятность – 1/36.
Итого: 1/6 + 1/6 − 1/36 = 11/36
—
В этом и весь смысл задачи.
Можно идеально знать теорвер, увидеть знакомую конструкцию и за 30 секунд получить красивый ответ. Но если вы решили не ту задачу, ценность решения нулевая.
И на собеседовании вам об этом могут даже не сказать. Просто поставят минус за секцию.
Так же и в работе: сначала убедитесь, что правильно поняли вопрос. И только потом решайте. | 4 024 |
| 17 | 🎲 Популярная задача с собеса: кубик бросают три раза
Меня не было на канале почти две недели. За это время в моей жизни произошло одно важное событие. Расскажу о нем через пару дней, когда будут фотографии,)
А пока возвращаемся к подготовке к осеннему сезону найма. Держите задачку, которую довольно часто дают на собеседованиях:
Кубик бросают три раза. Какова вероятность, что дважды выпадет одно и то же число?
Все. Больше вводных нет. Обычно задача звучит именно так.
Прежде чем считать, перечитайте условие еще раз. Если что-то в нем показалось вам неоднозначным – напишите об этом в комментариях.
В четверг разберу задачу и расскажу, почему на ней сыпятся даже те, кто прекрасно знает теорвер.
А пока присылайте свои варианты решения в комментариях 👇 | 3 718 |
| 18 | 🐢 Эта фраза на финале может стоить вам оффера
Когда я ушел из найма, то все равно продолжал ходить по собесам. Посматривал рынок и был открыт к действительно интересным предложениям.
Однажды я дошел до финала в международном стартапе, который мне понравился. В конце меня спросили:
– Ты же не торопишься?
– Не тороплюсь, – на свою голову ответил я.
– Просто позиция новая, хотим посмотреть еще кандидатов...
Вернулись ко мне лишь через три (!) месяца. И с отказом. Как я потом узнал изнутри, не сошлись по деньгам на этапе внутреннего согласования. Другого кандидата они тоже не нашли, а позицию позже и вовсе упразднили.
С тех пор я слышал много похожих историй. Для компании фраза «я не тороплюсь» очень удобна. Вам же она может стоить оффера. Потому что вы добровольно отдаете единственное, что создает давление на компанию на финале – свой дедлайн.
Дальше ваш процесс легко теряет приоритет. У нанимающего появляются другие кандидаты и дела, меняется бюджет, вакансию ставят на паузу, уходит человек, который вас продвигал.
За «хотим посмотреть еще кандидатов» обычно стоит одно из трех:
1️⃣ Вакансию правда только открыли. Такое бывает. Но рынок обычно понятен заранее, особенно на стандартном профиле. Затяжное «хотим еще посмотреть» чаще означает не нехватку кандидатов, а страх нанимающего принять решение.
2️⃣ Вы не дотягиваете до ожиданий. Самый частый сценарий. Вас в принципе готовы взять, но хочется проверить: вдруг найдется кто-то дешевле и/или сильнее. А вы пока в резерве: найдем лучше – возьмем его, не найдем – вернемся к вам.
3️⃣ Дело не в вас. Внутренний кандидат, согласование бюджета, перестройка команды, отпуск нанимающего, заморозка вакансии. Хороший признак – пауза привязана к дате. Плохой – «ну, посмотрим и вернемся».
Чтобы понять, что происходит, спросите напрямую:
– Сколько кандидатов сейчас на финальном этапе?
– К какой дате вы планируете принять решение?
– Чего вам не хватает в моей кандидатуре?
Если назвали конкретные слабые зоны, то хотя бы понятно, чего ждут. А если содержательных сомнений нет, но и срок никто назвать не может, значит причина скорее всего не в вас.
Вместо «я не тороплюсь» лучше сказать: «У меня есть параллельные собесы, по одному из них жду решение через неделю-полторы. Вы мне интересны, поэтому было бы здорово определиться примерно в эти сроки».
Это не ультиматум. Вы не требуете оффер завтра. Вы обозначаете, что не готовы ждать бессрочно.
Но чтобы это работало, есть два важных условия:
🔸 Дедлайн должен быть настоящим. Зафиксируйте срок и придерживайтесь его. Блефовать или нет уже дело ваше. Если нет других собесов, то это отличный повод их запустить. Дошли до финала здесь, дойдете и в другом месте.
🔸 Будьте готовы к риску. Могут ответить: «Раз не готовы ждать, значит, не судьба». Но спросите себя, что вы теряете. Позицию, которую вам дали бы только при условии, что за месяц не найдется кто-то получше?
—
«Хотим посмотреть еще кандидатов» – это не отказ. Но и не оффер. Это неопределенность. И она работает против вас ровно до тех пор, пока вы соглашаетесь находиться в ней без дедлайна.
А к вам возвращались с ответом после такой фразы? Сколько пришлось ждать? | 4 803 |
| 19 | ❄️ Разбор задачи с собеса про заморозку подписки
Формулировку задачи оставил постом выше, поэтому сразу к разбору.
Главная ошибка – услышать «проверить гипотезу» и сразу побежать в A/B.
Эксперимент здесь может оказаться дорогим решением в лоб. Чтобы увидеть не только краткосрочный эффект на выручку, но и последствия для удержания и LTV, его придется вести достаточно долго. При этом ошибка с решением убрать заморозку потенциально стоит дороже, чем ошибка с решением ее оставить.
Сначала нужно понять, что именно мы пытаемся измерить.
Продакт утверждает: «Без заморозки эти пользователи просто продолжали бы платить».
Проблема в том, что это контрфакт. Мы не знаем, что произошло бы с тем же пользователем без заморозки. Вариантов минимум три:
-> продолжил бы платить – тогда заморозка каннибализирует выручку;
-> отменил бы подписку совсем – тогда заморозка спасает будущую выручку;
-> отменил бы и вернулся позже – промежуточный сценарий.
В более широком смысле наличие заморозки может влиять еще и на решение оформить подписку в целом.
Поэтому «заморозкой пользуются 8%» и «средний срок – 2 месяца» сами по себе ничего не доказывают.
До эксперимента нужно провести ресерч.
Первый вопрос – в какой момент пользователь выбирает заморозку?
Если большинство сначала идут отменять подписку, а затем выбирают паузу вместо отмены – это аргумент в пользу того, что механика работает как удержание.
Если же люди сами находят заморозку в настройках и регулярно используют ее как способ не платить за периоды простоя – это уже сильнее похоже на каннибализацию.
Дальше посмотрел бы, что происходит с пользователями после разморозки: какая доля продолжает платить, сколько из них реально возвращаются в продукт, а не просто забывают отменить подписку, какая доля отменяет ее после разморозки и как часто пользователи замораживают подписку повторно.
Можно также попробовать подобрать похожих пользователей через matching / PSM и сравнить метрики тех, кто пользовался и не пользовался заморозкой. Это не даст полноценной причинной оценки, но поможет понять направление и примерный масштаб эффекта.
Если ресерча недостаточно для принятия решения, можно переходить к A/B.
Control – текущая механика. Treatment – заморозки нет.
И ключевая ошибка здесь – смотреть только на краткосрочные метрики.
Без заморозки выручка на коротком горизонте, скорее всего, вырастет. Но если пользователи начнут чаще отменять подписку и хуже возвращаться, на длинном горизонте эффект может стать отрицательным.
Поэтому основной вопрос – что происходит с выручкой на достаточно длинном горизонте. Будем смотреть Revenue, Retention, реактивации и отмены на горизонте 3+ месяцев, а на их основе оценивать долгосрочный эффект на LTV.
При этом финальное решение необязательно будет бинарным.
Самая интересная рекомендация – перенести заморозку во flow отмены. Тогда кнопку видят именно те, кто уже собирается уходить, а не все пользователи подряд.
И задача превращается из: «Нужна ли нам заморозка?» в: «Кому она спасает подписку, а кому просто дает возможность временно не платить?»
—
Именно это и проверяют на собесе: не только умеете ли вы задизайнить A/B, но и как вы мыслите: видите ли риски и ограничения, умеете ли выбрать оптимальный способ проверки гипотез.
А если хотите больше подобных разборов продуктовых кейсов на канале – поддержите пост огоньком 🔥 Это моя любимая рубрика.) | 3 883 |
| 20 | ❄️ Популярная задача с собесов на заморозку подписки
Есть задачи, которые кочуют из компании в компанию. Эта одна из них. И несмотря на кажущуюся простоту, на ней регулярно сыпятся кандидаты:
Вы продуктовый аналитик в подписочном сервисе с ежемесячной оплатой.
В управлении подпиской есть функция «заморозки». Вместо отмены пользователь может поставить подписку на паузу на срок до трех месяцев. Списаний в это время нет, доступ к сервису приостанавливается. После окончания заморозки подписка автоматически возобновляется. При желании пользователь может восстановить ее раньше.
К вам приходит продакт и говорит:
«Давайте уберем заморозку. Без нее эти пользователи просто продолжали бы платить. Мы сами сделали кнопку "не плати нам" и теперь режем себе выручку».
В подтверждение он приносит две цифры:
-> заморозкой пользуются 8% активных подписчиков;
-> средний срок заморозки – 2 месяца.
Вопрос: как вы будете проверять гипотезу продакта?
Небольшая просьба: подумайте сначала, каких данных вам не хватает и какие вопросы вы бы задали продакту. Я дам доп. вводные в комментариях.
На реальном собеседовании именно этот момент часто отличает сильный ответ от среднего. Кандидат, который сразу начинает предлагать решения, обычно проигрывает тому, кто сначала выяснил, какую проблему мы действительно решаем.
В понедельник я предложу свой вариант решения: покажу, как я двигаюсь по ней сверху вниз, где спрятана главная ловушка и по каким критериям интервьюер оценивает ответ.
А пока делитесь своими мыслями в комментариях 👇 | 3 993 |
