Мини-истории

Арман запустил fintech-приложение для микрокредитов в Алматы. Первые 3 месяца DAU росло: 500, 1200, 3000 пользователей. Команда праздновала — графики роста выглядели впечатляюще на встречах с инвесторами. Но Арман не смотрел на Retention — а он был 8% на D30. Новые пользователи регистрировались, брали один кредит и больше не возвращались. Через 3 месяца рост остановился. CAC вырос до 4500 тенге, а LTV не превышал 3200 тенге — юнит-экономика была отрицательной. Инвесторы отказали в раунде, увидев кривую Retention. Арман пересобрал воронку: добавил персональный онбординг с объяснением условий, push-уведомления о сроках платежей, программу лояльности для повторных клиентов и автоматические предложения по кредитному лимиту. Retention вырос до 35%, LTV увеличился в 3 раза до 9600 тенге, и продукт вышел на самоокупаемость через 4 месяца.

Дана работала продактом в proptech-стартапе, который помогал арендаторам искать квартиры в Астане. Команда была уверена, что главная проблема — поиск по фильтрам. Потратили 3 месяца на «умный фильтр» с 20 параметрами. Запустили — конверсия 0.3%. Никто не пользовался фильтрами. Дана решила разобраться и провела 50 глубинных интервью с арендаторами в Астане за 3 недели. Выяснилось: главная боль — не поиск, а доверие. Арендаторы боялись мошенников, фейковых объявлений и предоплат на Kaspi без гарантий. Команда развернулась: вместо фильтров сделали верификацию арендодателей (фото паспорта + видео квартиры) и безопасную сделку через эскроу. Конверсия выросла до 4.2%, а NPS подскочил с 15 до 52.

Марат делал приложение для заказа воды в Караганде. Казалось очевидным: люди хотят заказывать воду. Но рост застопорился на 200 пользователях. Марат изучил JTBD и провёл 15 интервью по методу «переключения» (Switch Interview). Выяснилось: люди не «заказывают воду» — они «обеспечивают семью чистой водой без лишних хлопот». Конкуренты — не другие доставки, а кулеры в офисе, бутыль от соседа на рынке и обычный фильтр из «Технодома». Марат перестроил предложение: подписка на воду с автодоставкой (не нужно помнить и заказывать), бесплатный кулер, напоминание о замене. Позиционирование сменилось с «доставка воды» на «забудь о воде навсегда — мы позаботимся». MAU вырос в 5 раз за квартал, а средний чек — на 40%.

Аиша работала PM в edtech-стартапе. У команды был бэклог из 40 фич, и каждый стейкхолдер считал свою идею самой важной. CEO хотел геймификацию, CTO — AI-тьютора, маркетинг — реферальную программу. Бюджета хватало на 2-3 фичи в квартал. Аиша внедрила систему быстрой проверки гипотез: сформулировала 12 гипотез в формате «Мы верим, что [X] приведёт к [Y], потому что [Z]». Каждую оценила по ICE, затем ТОП-5 проверила за 2 недели: fake door test (кнопка без функционала), опросы в Instagram, A/B-тесты заголовков. Результат: геймификация дала +2% к retention (не стоит того), AI-тьютор — +18% к completion rate (бинго!), реферальная программа — +25% к регистрациям (тоже хорошо). Команда сфокусировалась на AI-тьюторе и рефералке. Через квартал — Retention D30 вырос с 12% до 28%.

Тимур хотел запустить маркетплейс по аренде спецтехники в Казахстане. Бизнес-план был красивый: TAM 50 млрд тенге, 3% комиссия, выход на прибыль через 18 месяцев. Инвестор был готов дать 15 млн тенге на MVP. Но Тимур решил сначала провалидировать спрос. За 200 000 тенге он сделал лендинг на Tilda, запустил рекламу в Instagram и Google (бюджет 150 000 тенге на 2 недели), и создал WhatsApp-бот для приёма заявок. Результаты: 340 кликов на лендинг, 12 заявок, из них реальных — 3. И все три хотели купить технику, а не арендовать. Гипотеза об аренде не подтвердилась. Тимур пивотнул: вместо маркетплейса аренды сделал каталог б/у спецтехники с рассрочкой через Kaspi. За 3 месяца — 45 сделок, оборот 120 млн тенге. Сэкономил 15 млн тенге и 6 месяцев на ненужном MVP.

Болат основал SaaS для автоматизации ресторанов в Алматы. Первые 6 месяцев он лично ходил по ресторанам и продавал. Из 100 встреч — 8 клиентов. MRR: 400 000 тенге. Инвестор сказал: «Медленно растёшь». Болат проанализировал: почему одни рестораны покупают за неделю, а другие — никогда? Оказалось, покупали рестораны, у которых уже был POS-терминал от iiko, но не было аналитики. Болат сузил сегмент: только рестораны с iiko, без аналитики, оборот от 10 млн тенге/мес. Стратегия: интеграция с iiko (не замена, а надстройка), бесплатный пробный месяц, ROI-калькулятор на лендинге. Каналы: партнёрство с iiko-интеграторами + Telegram-канал для рестораторов КЗ. Через 12 месяцев: 85 клиентов, MRR 5.2 млн тенге, churn 3%/мес. Следующий шаг — экспансия в Астану и Шымкент.

Айгерим работала дизайнером в стартапе по доставке продуктов. Приложение выглядело красиво — минималистичный дизайн, анимации, тёмная тема. Проблема: конверсия из установки в первый заказ — 8%. Пользователи скачивали и удаляли. Айгерим предложила создать персоны. Провела 20 интервью и обнаружила: 70% пользователей — женщины 30-45 лет, мамы, которые заказывают продукты с телефона одной рукой, пока держат ребёнка. Им нужны большие кнопки, быстрый повтор заказа и список покупок, а не красивые анимации. Айгерим создала 3 персоны (Динара-мама, Ерлан-холостяк, Гульнар-бабушка) и перестроила UX: большие тач-зоны, «Повторить прошлый заказ» на главном экране, голосовой поиск продуктов, упрощённый чекаут до 2 кликов. Конверсия выросла до 24%. Динара-мама стала главной персоной, и все продуктовые решения теперь проходят «тест Динары»: сможет ли она оформить заказ за 30 секунд одной рукой?

Нурлан пришёл скрам-мастером в финтех-стартап в Алматы. Ситуация: команда из 8 человек, спринты по 2 недели, но за последние 3 месяца ни один спринт не завершён на 100%. Velocity скачет от 15 до 45 story points. Разработчики жалуются на нечёткие требования, PM — на «вечные вопросы» от команды. Нурлан провёл ретро и нашёл корневую причину: User Stories были написаны в формате «Сделать экран оплаты» — без Acceptance Criteria, без Definition of Done, без edge cases. Каждая задача превращалась в дискуссию на 30 минут. Нурлан ввёл стандарт: каждая Story — формат «Как/Хочу/Чтобы» + AC в Given-When-Then + DoD чеклист + дизайн в Figma. Ввёл Story Refinement за 2 дня до спринта. Сделал шаблон в Notion. Через 2 спринта: velocity стабилизировался на 30±3 SP, ни одного «Что тут имелось в виду?» на daily, спринты закрываются на 90-95%. Команда стала счастливее.

Жанар — Product Owner в govtech-проекте в Астане. Каждую неделю: 5 митингов с заказчиком, 2 грумминга, 1 планирование, отчёт для руководства. На создание документации уходило 60% рабочего времени: ТЗ, User Stories, протоколы встреч, отчёты. Жанар начала использовать AI-инструменты: ChatGPT для генерации User Stories (с последующей доработкой), Otter.ai для протоколов встреч, Notion AI для структурирования бэклога, Midjourney для быстрых мокапов. Но первый месяц был провальным — AI генерировал generic тексты, не учитывающие контекст проекта. Жанар создала библиотеку промптов: шаблон для ТЗ с контекстом проекта, шаблон для AC с примерами из предыдущих спринтов, шаблон для протоколов. Результат: время на документацию сократилось с 24 до 8 часов в неделю. Освободившееся время Жанар потратила на CustDev — провела 15 интервью с пользователями eGov и нашла 3 критических бага в UX, которые не видели тестировщики.

Кайрат создал приложение для записи к врачам в Алматы — аналог DocDoc. Первая версия: каталог клиник, рейтинги врачей, онлайн-запись. Через 6 месяцев — 2000 MAU, но Retention D30 всего 5%. Люди записывались один раз и забывали о приложении. Кайрат попробовал всё: push-уведомления (retention +1%), программу лояльности (+2%), блог о здоровье (+0.5%). PMF не наступал. Инвесторы нервничали. Тогда Кайрат вернулся к основам — провёл 30 интервью с пользователями, которые УШЛИ из приложения. Обнаружил паттерн: люди приходили не «записаться к врачу», а «понять, что со мной не так, и к какому врачу идти». Проблема была в навигации по симптомам, а не в записи. Кайрат добавил чат-бот «Симптом-чекер» — пользователь описывает симптомы, бот рекомендует специализацию и конкретных врачей. Retention D30 вырос до 22%, а MAU — до 15 000 за 4 месяца. PMF наступил, когда Кайрат перестал решать свою проблему и начал решать проблему пользователя.

Самат руководил growth-командой в e-commerce стартапе из Шымкента. KPI на квартал: увеличить число регистраций в 3 раза. Самат запустил агрессивную рекламную кампанию в Instagram и TikTok: розыгрыш iPhone за регистрацию. За месяц: 15 000 новых регистраций (рост в 5 раз!). Самат получил бонус. Но через 2 месяца стало ясно: из 15 000 новых пользователей заказ сделали 120 человек (конверсия 0.8% вместо обычных 12%). 95% зарегистрировались только ради розыгрыша. CAC вырос с 800 до 3200 тенге, LTV новых пользователей — 200 тенге. Инвестиции в рекламу — 4.8 млн тенге — не окупились. Самат усвоил урок: теперь его KPI — не регистрации, а «активные покупатели с 2+ заказами за 30 дней». Метрика тщеславия (vanity metric) чуть не убила юнит-экономику продукта.

Мадина работала UX-дизайнером в маркетплейсе. Конверсия «корзина → оплата» была 18% — в 2 раза ниже рыночного бенчмарка. PM считал, что проблема в ассортименте. Маркетинг думал, что в цене. Мадина провела юзабилити-тестирование с 8 пользователями (запись экрана + think aloud). Выяснилось: 1. 40% отваливались на шаге «ввод адреса» — форма требовала точный индекс, а пользователи не знали свой 2. 25% путались в выборе доставки — 5 вариантов без объяснения разницы 3. 15% не доверяли оплате — не было знакомых брендов (Kaspi Pay) Мадина упростила: убрала индекс (2GIS API определяет автоматически), оставила 2 варианта доставки с чёткими сроками и ценами, добавила оплату через Kaspi QR на первое место. Плюс добавила прогресс-бар «3 шага до заказа». Конверсия выросла с 18% до 41% за 2 недели. Это принесло дополнительно 12 млн тенге выручки в первый месяц.

Нуркен возглавил продажи в SaaS-стартапе, который делал систему управления складом для МСБ в Казахстане. Первые 4 месяца команда пыталась продавать через холодные звонки — обзвонили 800 компаний из базы 2GIS. Конверсия: 800 звонков → 45 встреч → 3 клиента. CAC составлял 1.2 млн тенге при ARPU 80 000 тенге/мес — окупаемость клиента через 15 месяцев. Нуркен проанализировал воронку и обнаружил паттерн: все 3 клиента пришли через рекомендации существующих пользователей бета-версии. Холодные звонки не работали, потому что собственники МСБ в Казахстане не доверяют незнакомцам по телефону — они принимают решения через «своих». Нуркен перестроил стратегию: вместо холодных звонков запустил «Клуб рестораторов Астаны» — ежемесячные встречи на 20-30 владельцев бизнеса в коворкинге. Формат: кейс от текущего клиента (30 мин) + нетворкинг с бешбармаком и баурсаками. На мероприятия звал действующих клиентов — они рассказывали, как система сэкономила им 500 000 тенге/мес на потерях товара. Добавил реферальную программу: клиент приводит клиента — оба получают месяц бесплатно. Запустил кейс-стади в Telegram-канале «Бизнес КЗ» (45 000 подписчиков). Через 6 месяцев: 42 клиента, MRR 3.4 млн тенге, CAC снизился до 180 000 тенге, 65% новых клиентов приходили по рекомендации. Цикл сделки сократился с 45 до 12 дней.

Ернар основал платформу для онлайн-бухгалтерии МСБ в Казахстане. Начинал как product-led: бесплатная регистрация, триал 14 дней, апсейл в платный план. За год — 1200 регистраций, 85 платящих клиентов, MRR 1.7 млн тенге. Конверсия из триала в оплату — 7%. Проблема: бухгалтеры КЗ не привыкли к self-service SaaS. Они регистрировались, видели интерфейс, не понимали как мигрировать данные из 1С — и уходили. Онбординговые письма никто не читал. Ернар нанял 2 менеджеров по продажам и перестроил воронку: каждый новый пользователь получал звонок в течение 2 часов после регистрации. Менеджер проводил демо на 30 минут, помогал импортировать данные, настраивал отчёты под конкретного бухгалтера. Стоимость: 2 менеджера = 800 000 тенге/мес зарплата. Но конверсия из триала выросла с 7% до 28%. Средний чек увеличился на 40% — менеджеры продавали годовую подписку вместо помесячной (скидка 20%, но гарантированный cash flow). За 6 месяцев: 220 платящих клиентов, MRR 5.5 млн тенге. CAC через sales-led: 145 000 тенге (дешевле PLG, потому что конверсия в 4 раза выше). LTV/CAC = 4.8. Урок: Ернар не отказался от PLG полностью — мелкие ИП (до 3 сотрудников) по-прежнему конвертятся через self-service. Но ТОО с оборотом от 5 млн тенге/мес требуют human touch.

Бекзат работал в стартапе, который делал платформу для управления командировками. Основной клиент — МСБ, средний чек 120 000 тенге/мес. CEO поставил задачу: выйти на enterprise — нефтегазовые компании с бюджетами от 2 млн тенге/мес. Бекзат составил список из 15 target accounts: ТенгизШеврОйл, КазМунайГаз, NCOC. Начал с LinkedIn — нашёл Head of Procurement в «КМГ-Сервис». Первое сообщение проигнорировали. Второе — тоже. На третье (через 3 недели, со ссылкой на статью про оптимизацию тревел-расходов) — получил ответ. Первая встреча — через 2 месяца. На встрече: 5 человек со стороны клиента (закупки, IT, бухгалтерия, юристы, руководитель HR). Каждый задавал свои вопросы. Бекзат понял: enterprise — это не один buyer, а 5 стейкхолдеров с разными мотивациями. Дальше: пилот на 3 месяца для 50 сотрудников (бесплатно), интеграция с 1С и SAP (2 месяца разработки), согласование SLA и договора с юристами (45 дней), проверка безопасности IT-отделом (аудит инфраструктуры). Итого от первого касания до подписания — 9 месяцев. Контракт: 2.5 млн тенге/мес на 2 года = 60 млн тенге. Один клиент = больше, чем все 85 МСБ-клиентов вместе. Бекзат задокументировал playbook: multi-threading (работай со всеми стейкхолдерами параллельно), champion внутри компании (HR-директор стала «адвокатом»), бесплатный пилот как инструмент снижения риска для клиента.

Жансая работала единственным маркетологом в стартапе — приложении для поиска скидок и акций в Алматы (аналог Pepper/Скидочник). Бюджет на маркетинг — 0 тенге. CEO сказал: «Вырасти органически или найди деньги сама». Жансая начала с анализа: откуда приходят текущие 3000 пользователей? 60% — из WhatsApp-групп. Жансая поняла: казахстанцы делятся скидками в чатах. Это — виральный loop. Стратегия: сделать шеринг максимально лёгким. Добавила кнопку «Поделиться в WhatsApp» прямо на карточку скидки (раньше был только «копировать ссылку»). Ссылка генерировала красивый превью с ценой и фото. Добавила реферальную механику: «Пригласи друга — получи доступ к секретным скидкам от Sulpak, Magnum и Technodom». Запустила Telegram-канал «Скидки Алматы» — публиковала 10-15 лучших акций в день. Через 2 месяца — 25 000 подписчиков. Каждый пост содержал ссылку на приложение. Написала 15 гостевых постов для Telegram-каналов: «Лайфхаки КЗ» (80 000 подписчиков), «Мамы Алматы» (35 000), «Студенты КЗ» (20 000). Бартер: упоминание их канала в приложении в обмен на пост. Договорилась с 10 Instagram-магазинами: они публикуют свои акции через приложение, взамен — продвижение в рассылке на 50 000 пользователей. Через 8 месяцев: 105 000 установок, DAU 18 000, 0 тенге на рекламу. K-factor (виральность): 1.3 — каждый пользователь приводил 1.3 новых. Жансая стала Head of Growth.

Диас присоединился к B2B SaaS для автоматизации логистики. Продукт хороший, но о нём никто не знал — 50 посетителей на сайте в месяц. Бюджет на контент: 500 000 тенге/мес (его зарплата + фрилансеры). Диас начал с исследования: взял логи звонков sales-команды за 3 месяца (120 записей). Выписал ТОП-20 вопросов, которые задают потенциальные клиенты. Каждый вопрос стал основой для статьи. Запустил блог на сайте: 2 статьи в неделю. Формат: практические гайды для логистов КЗ. Примеры: «Как рассчитать стоимость маршрута Алматы–Атырау», «5 ошибок при выборе TMS в Казахстане», «Как сэкономить 2 млн тенге/мес на холостых пробегах». SEO-оптимизация под запросы на русском. Добавил Telegram-канал «Логистика КЗ» — экспертный контент + инфографика + новости отрасли. Через 4 месяца — 8 000 подписчиков. Запустил email-рассылку: еженедельный дайджест для 2 500 подписчиков. Ключевой ход: серия интервью с клиентами — 10 кейс-стади по формату «Проблема → Решение → Результат в цифрах». Каждый кейс — 2000 слов с реальными скриншотами и цитатами директоров. Кейс «Как ТК Абсолют сократила холостой пробег на 35%» набрал 12 000 просмотров и привёл 8 лидов. Через 10 месяцев: 4 500 уникальных посетителей на сайте в месяц (рост в 90 раз), 35% лидов приходят через контент (inbound), CAC через контент — 85 000 тенге vs 350 000 через холодные звонки.

Алтынай отвечала за монетизацию edtech-платформы для подготовки к ЕНТ (Единое Национальное Тестирование). Платформа 6 месяцев работала бесплатно, набрала 12 000 пользователей. Пришло время включать монетизацию. Первая цена: 5 000 тенге/мес — скопировали у конкурента. Конверсия в оплату: 1.2%. Слишком мало. Команда решила, что цена высокая. Вторая попытка: 2 500 тенге/мес. Конверсия: 1.5%. Почти не изменилась — значит, дело не в цене. Алтынай провела 20 интервью с пользователями, которые НЕ заплатили. Выяснилось: они не понимали, за что платят. Бесплатная версия давала 80% функционала — зачем платить за оставшиеся 20%? Алтынай перестроила тарифную сетку: бесплатная версия — только 3 пробных теста. Платная — полный доступ + персональная аналитика + видеоразборы. Три тарифа: «Базовый» (3 900 тенге/мес — тесты), «Стандарт» (6 900 тенге/мес — тесты + аналитика), «Премиум» (9 900 тенге/мес — всё + менторство). Эксперимент с якорной ценой: «Премиум» за 9 900 тенге сделал «Стандарт» за 6 900 визуально выгодным. 60% платящих выбирали «Стандарт». Добавила годовой тариф со скидкой 30% — конверсия в годовую подписку 40% (cash flow!). Запустила «семейный тариф»: 2 ребёнка за 10 000 тенге вместо 13 800 — рост ARPU на 25%. Через 3 месяца экспериментов: конверсия в оплату — 8.5%, ARPU — 5 800 тенге/мес, MRR — 4.2 млн тенге. Всё потому, что Алтынай не просто «поставила цену», а провела 7 итераций.

Ермек создал приложение для учёта личных финансов, адаптированное под Казахстан — автоматический импорт транзакций из Kaspi, категоризация расходов, бюджеты. За год freemium-модель привлекла 45 000 пользователей. Проблема: только 800 человек (1.8%) платили за Premium (2 990 тенге/мес). Ермек проанализировал поведение платящих vs бесплатных. Платящие: открывали приложение 5+ раз в неделю, использовали категории и бюджеты. Бесплатные: заходили 1-2 раза, смотрели общий баланс и закрывали. Гипотеза: бесплатные пользователи не видят ценности, потому что не настроили приложение. Ермек ввёл «Activation Milestone» — пользователь должен создать первый бюджет в течение 3 дней после регистрации. Механика: на второй день push-уведомление «Куда ушли 47 000 тенге на прошлой неделе? Создай бюджет и узнай». Персонализация — реальная сумма расходов из Kaspi. На третий день — «Твой бюджет на еду: 120 000 тенге. Хочешь сэкономить 20 000? Включи лимиты». Для конвертации в Premium: paywall на 4-м месяце использования. До этого — полный функционал. Логика: к 4 месяцу пользователь привык и не хочет терять данные. Предложение: «Продолжи за 2 990 тенге/мес или потеряй историю за 4 месяца». Добавили годовой тариф за 24 900 тенге (экономия 31%). Результат: Activation rate вырос с 15% до 52%. Конверсия в Premium — с 1.8% до 6.5%. MRR: с 2.4 млн до 8.8 млн тенге за 5 месяцев. Retention D90 для активированных пользователей — 48% vs 8% для неактивированных.

Дарига работала PO в страховой компании. Задача: за квартал запустить мобильное КАСКО с онлайн-оформлением. Проблема: за 2 месяца команда не могла договориться о MVP. Андеррайтеры хотели калькулятор с 30 параметрами, маркетинг — «простую кнопку купить», IT — интеграцию со всеми системами, юристы — 15-страничный договор на экране. 4 совещания по 3 часа = 12 часов обсуждений и 0 решений. Дарига предложила Design Sprint — 5 дней по методологии Google Ventures. Понедельник: собрала всех стейкхолдеров (8 человек). Упражнение «Как мы можем...» (HMW notes) — каждый написал свои проблемы на стикерах. 47 стикеров. Проголосовали точками — ТОП-5 проблем. Вторник: каждый участник нарисовал свое решение (Crazy 8s). 8 набросков за 8 минут. Молча. Без споров. Лучшие идеи отобрали голосованием. Среда: построили storyboard — путь пользователя от «хочу КАСКО» до «полис на почте». 8 экранов. Четверг: дизайнер сделал кликабельный прототип в Figma за 6 часов. Не идеальный, но тестируемый. Пятница: провели тестирование с 5 реальными автовладельцами из Астаны. Нашли 3 критические проблемы: (1) калькулятор пугал — нужен был «быстрый расчёт по гос.номеру», (2) 15-страничный договор — никто не читает, нужен «краткий обзор условий», (3) оплата — только Kaspi Pay и Halyk. Результат: за 5 дней = решение, на которое без спринта ушло бы 2 месяца. MVP запустили вовремя. За первый месяц — 340 оформленных полисов, конверсия лендинг → оплата — 12%.

Адиль руководил продуктом в логистической компании. Роадмап на квартал был готов: 3 больших фичи, утверждённые CEO. Но Адиль чувствовал, что фичи выбраны «от головы», а не от пользователей. Он предложил провести Opportunity Solution Tree (OST) воркшоп перед началом квартала. Участники: PO, 2 разработчика, дизайнер, аналитик, представитель поддержки. Формат: 4 часа, офлайн, стикеры на стене. Шаг 1 — Desired Outcome: команда зафиксировала метрику «увеличить количество повторных заказов на 30%». Не фичи, а результат. Шаг 2 — Opportunities: каждый участник рассказал инсайты из своей работы. Поддержка: «Клиенты звонят 5 раз спросить статус груза — трекинг не работает нормально». Аналитик: «40% клиентов не возвращаются после первого заказа — drop-off на этапе повторного оформления». Разработчик: «API перевозчика падает 3 раза в неделю». Шаг 3 — Solutions: для каждой Opportunity команда сгенерировала 3-5 решений. Приоритизировали через RICE. Результат: 2 из 3 фич CEO были заменены. Вместо «красивого дашборда для директора» (Reach: низкий, Impact: средний) сделали: (1) real-time трекинг с push-уведомлениями (снизил звонки в поддержку на 60%), (2) «повтор заказа в 1 клик» (повторные заказы +45%). CEO сначала был недоволен, но через квартал увидел метрики и признал: «Данные убедительнее моей интуиции». Адиль теперь проводит OST-сессии каждый квартал. Правило: «Никаких фич в роадмапе без привязки к Outcome и Opportunity».

Асхат получил эпик: «Личный кабинет клиента» для B2B SaaS платформы управления автопарком. Дедлайн — 2 месяца. Команда оценила «на глаз»: 3-4 месяца. CEO сказал: «2 месяца, не обсуждается — клиент ждёт». Асхат собрал команду и применил технику User Story Mapping. На стене разложил путь клиента: регистрация → дашборд → управление автомобилями → аналитика → отчёты → настройки. Каждый шаг — столбец. Каждая функция внутри шага — строка. Получилось 47 User Stories. Асхат провёл горизонтальную линию — «Walking Skeleton»: минимальный набор для первого MVP. Над чертой — 18 Stories (must have), под чертой — 29 Stories (nice to have). Дальше: каждую Story разбил по принципу INVEST. Пример: «Как менеджер автопарка, хочу видеть дашборд» → (1) «Виджет: количество автомобилей», (2) «Виджет: средний пробег за месяц», (3) «Виджет: расходы на топливо», (4) «Фильтр по периоду». Каждая — независимая, тестируемая, релизабельная. Оценка через Planning Poker: 18 MVP-Stories = 85 Story Points. Velocity команды — 45 SP за спринт. 2 спринта = 90 SP. Укладываемся! Через 4 недели выпустили Walking Skeleton: личный кабинет с базовым дашбордом, списком авто и 3 отчётами. Клиент увидел и сказал: «Уже можно пользоваться, остальное добавим позже». Nice-to-have Stories ушли в следующий квартал. Оставшиеся 29 Stories расприоритизировали: 12 — следующий квартал, 10 — backlog, 7 — удалили (клиенту не нужны).

Мейрам руководил продуктом в стартапе — маркетплейсе услуг для дома (аналог «Профи» для КЗ): сантехники, электрики, уборка. Техническая команда оценила MVP в 6 месяцев: приложение для клиентов, приложение для мастеров, админ-панель, платёжная система, система рейтингов, чат, push-уведомления, карта мастеров. Бюджет горел — инвестор дал деньги на 4 месяца. Мейрам применил технику «Что можно убрать и продукт всё ещё работает?». Шаг 1: определил «одно действие» — клиент находит мастера и связывается с ним. Всё остальное — nice to have. Шаг 2: что НЕ нужно для этого действия? — Приложение для мастеров? Не нужно — мастера получают заявки в WhatsApp. — Платёжная система? Не нужна — клиент платит мастеру напрямую через Kaspi. — Чат? Не нужен — WhatsApp. — Карта? Не нужна — выбор по районам города. — Push-уведомления? Не нужны — SMS через Mobizon (3 тенге/SMS). MVP: лендинг на Tilda + Google Forms для заявки + Telegram-бот для модерации + Google Sheets как CRM + WhatsApp для связи. Разработка: 0 строк кода, 3 недели настройки. Запустили в 5 районах Алматы. За 3 недели: 180 заявок, 45 выполненных заказов, NPS 62. Мастера довольны — заказы приходят бесплатно. Клиенты довольны — мастер приходит за 2 часа. Только после валидации Мейрам начал разработку приложения — но уже с данными: какие категории услуг самые популярные (сантехника — 35%, электрика — 25%, уборка — 20%), средний чек (8 000 тенге), конверсия заявки в заказ (25%). 6 месяцев MVP → 6 недель no-code MVP. Сэкономлено: 12 млн тенге на разработке и 4 месяца времени.

Томирис работала PO в healthtech-стартапе — платформе телемедицины. После запуска бета-версии на 5 000 пользователей, юрист компании провёл аудит и обнаружил 12 нарушений Закона РК «О персональных данных и их защите» (от 21 мая 2013 года, №94-V). Критические нарушения: (1) согласие на обработку данных было «зарыто» в Terms of Service — пользователь не давал явного согласия, (2) медицинские данные (диагнозы, анализы) хранились на серверах AWS в Ирландии — закон требует хранения на территории РК, (3) нет механизма удаления данных по запросу пользователя, (4) данные передавались аналитическим сервисам (Google Analytics, Amplitude) без анонимизации. Штраф за нарушение: до 10 млн тенге для юридических лиц. Плюс риск отзыва лицензии на медицинскую деятельность. Томирис составила план на 6 недель: Неделя 1-2: Миграция данных на казахстанский хостинг (PS.kz и Selectel.kz). Стоимость: 250 000 тенге/мес вместо $150/мес на AWS. Производительность упала на 15% — пришлось оптимизировать. Неделя 3: Переработка consent flow — явное согласие перед каждой категорией данных: «Я согласен на обработку моих медицинских данных для...» с чекбоксами. Добавлен Privacy Dashboard — пользователь видит какие данные собраны и может удалить. Неделя 4: Анонимизация для аналитики — замена Amplitude на self-hosted Posthog, данные остаются в КЗ. Неделя 5-6: Документация: политика обработки данных, регламент реагирования на утечки (инцидент-менеджмент), обучение команды. После внедрения: прошли аудит уполномоченного органа (Комитет по информационной безопасности МЦРИАП) без замечаний. Бонус: NPS вырос на 8 пунктов — пользователи оценили прозрачность обработки данных.

Рустем руководил продуктом в fintech-стартапе — сервисе P2P-кредитования. Платформа работала 8 месяцев, 3 000 активных пользователей, объём выданных кредитов — 800 млн тенге. Всё шло хорошо, пока не пришло письмо от АРРФР (Агентство по регулированию и развитию финансового рынка). АРРФР указал: деятельность по P2P-кредитованию подлежит лицензированию (Закон РК «О микрофинансовой деятельности»). Без лицензии — штраф до 15 млн тенге и прекращение деятельности. Дедлайн на устранение: 3 месяца. Рустем мог бы паниковать, но выбрал системный подход. Шаг 1: нанял юриста, специализирующегося на финансовом праве КЗ (Aequitas Law Firm). Стоимость: 2 млн тенге за сопровождение. Шаг 2: GAP-анализ — что есть vs что требует регулятор: — KYC (Know Your Customer): был упрощённый (только ИИН). Нужен: фото паспорта + селфи + проверка через «Электронное правительство». — AML (Anti-Money Laundering): не было совсем. Нужен: мониторинг транзакций, проверка по спискам санкций, отчётность в финансовую разведку. — Резервирование: не было. Нужно: формировать резервы на возможные потери по кредитам (5-15% портфеля). — Отчётность: ежемесячные отчёты в АРРФР по форме. Шаг 3: приоритизация. Рустем выделил 2 потока: (1) продуктовые изменения (KYC, AML — 6 недель разработки), (2) юридические (лицензия, документы — параллельно). Ключевое решение: вместо собственной KYC/AML-системы интегрировались с провайдером Verigram.kz (казахстанский сервис верификации) — 150 тенге за проверку, но зато за 2 недели вместо 3 месяцев. Результат: лицензия получена за 2.5 месяца. Конверсия регистрации упала на 30% из-за KYC (ожидаемо), но качество заёмщиков выросло — дефолт-рейт снизился с 12% до 4%. Экономия на дефолтах за год: 45 млн тенге.

Сабина руководила разработкой мобильного приложения для крупного банка в Астане. 7 стейкхолдеров — каждый со своим видением: директор розничного бизнеса хотел «как Kaspi», CTO настаивал на микросервисах, юристы требовали согласование каждого экрана, маркетинг хотел интеграцию с Instagram, комплаенс блокировал любую фичу с данными, поддержка просила встроенный чат, а CEO «просто хотел чтобы быстрее». Каждую неделю — совещание на 2 часа, где 7 человек спорили о приоритетах. За 2 месяца — 3 раза менялся скоуп спринта. Команда деморализована, velocity упал на 40%. Сабина применила систему управления стейкхолдерами: Шаг 1: Stakeholder Map. Классифицировала каждого по модели Power/Interest: CEO — высокая власть, низкий интерес в деталях (manage closely, но не грузи деталями). Юристы — высокая власть, высокий интерес (вовлекай активно). Маркетинг — низкая власть, высокий интерес (информируй, но решения — не за ними). Шаг 2: Individual meetings. Вместо общего совещания — индивидуальные 30-минутные встречи с каждым стейкхолдером раз в 2 недели. На каждой — показывала прогресс именно по их запросам и собирала обратную связь. Шаг 3: Decision Log. Завела Notion-документ: каждое решение — кто принял, почему, когда. Когда стейкхолдер пытался отменить решение — открывала лог: «Мы это обсудили 15 января, вот ваше подтверждение». Шаг 4: Роадмап в формате «Now / Next / Later». CEO видит общую картину, не вникая в детали. Разработчики видят конкретные Stories. Юристы видят, когда их согласование нужно. Шаг 5: Общее совещание сократила до 30 минут раз в месяц — только статус и блокеры. Детали — в индивидуальных встречах. Результат: velocity вернулся к норме (+55% за месяц), 0 изменений скоупа за следующие 3 спринта, приложение запущено в срок. CEO сказал: «Наконец-то порядок».

Алмас возглавил продуктовый отдел в e-commerce компании с 3 продуктовыми командами (мобайл, веб, логистика). Проблема: каждая команда работала автономно, приоритеты не совпадали с бизнес-целями. Мобайл делал «красивый редизайн» (CEO попросил), веб оптимизировал SEO (маркетинг попросил), логистика — внутренний инструмент (CTO попросил). Никто не работал на главную цель бизнеса — рост выручки на 50% за год. Алмас внедрил OKR (Objectives and Key Results) за 2 недели: Неделя 1: Стратегическая сессия с CEO и директорами. Определили Company OKR на квартал: — Objective: «Стать №1 маркетплейсом электроники в Казахстане» — KR1: Увеличить GMV с 500 до 750 млн тенге/мес — KR2: Довести NPS до 55 (сейчас 38) — KR3: Снизить стоимость доставки до 800 тенге/заказ (сейчас 1 400) Неделя 2: Каждая команда сформулировала свои OKR, привязанные к Company OKR: — Мобайл: «Увеличить конверсию в первый заказ с 8% до 15%» (влияет на KR1) — Веб: «Увеличить органический трафик с 50K до 120K визитов/мес» (влияет на KR1) — Логистика: «Запустить доставку за 2 часа в Алматы» (влияет на KR2 и KR3) Формат: еженедельный OKR check-in на 15 минут (каждая команда — 5 мин). Светофор: зелёный (on track), жёлтый (at risk), красный (off track). Все видят прогресс всех. Первый квартал — сложно: команды сопротивлялись («мы и так знаем что делать»). Мобайл-команда отказалась от красивого редизайна в пользу оптимизации онбординга — конверсия выросла с 8% до 13.5%. Через квартал: GMV — 680 млн тенге (не 750, но рост 36%), NPS — 47 (рост с 38), стоимость доставки — 950 тенге (улучшение на 32%). Не все KR достигнуты на 100%, но фокус дал результат: рост выручки +28% vs +8% в предыдущем квартале (без OKR). Алмас: «OKR работают не потому, что все KR достигаются. Они работают потому, что все знают, куда бежим».

Назгуль руководила продуктом в govtech-компании, которая делала цифровые услуги для акиматов. Команда работала как «фабрика фич»: бизнес-аналитик писал ТЗ, дизайнер рисовал макеты, разработчики кодили. Никто не задавал вопрос «зачем?». Backlog вырос до 200 задач, приоритизация — по принципу «кто громче кричит». Назгуль прочитала «Inspired» Марти Кагана и поняла: у них feature team, а нужна empowered product team. Разница: feature team получает задачи, empowered team получает проблемы. Назгуль начала трансформацию: Шаг 1: Product Trio. Сформировала тройку: PO (она), Tech Lead, UX-дизайнер. Каждую неделю — совместный Discovery: анализ данных, интервью с пользователями, прототипирование. Раньше PO и дизайнер не разговаривали напрямую — всё через ТЗ. Шаг 2: Continuous Discovery. Вместо ежеквартального исследования — еженедельно 2-3 интервью с пользователями (15-20 минут каждое). Нашли: сотрудники акиматов тратят 2 часа в день на копирование данных между 3 системами, которые не интегрированы. Шаг 3: Outcome-based roadmap. Заменили роадмап «Фича A → Фича B → Фича C» на «Сократить время обработки заявления с 5 дней до 1 дня». Команда сама решала КАК достичь результата. Шаг 4: Dual Track Agile. Discovery и Delivery работают параллельно: пока команда разрабатывает решение из прошлого Discovery, Product Trio уже исследует следующую проблему. Сопротивление было: CTO считал, что «разработчикам нечего ходить на интервью», бизнес-аналитик — что её «заменяют». Назгуль провела серию воркшопов с книгой Кагана как основой. Через 6 месяцев: backlog сократился с 200 до 40 задач (остальные удалили или объединили). Время обработки заявлений — 1.5 дня (вместо 5). CSAT акимата вырос с 2.8 до 4.1 из 5. Команда стала счастливее — разработчики впервые видели пользователей и понимали, зачем пишут код.

Ануар работал скрам-мастером в edtech-компании в Караганде. Команда из 10 человек: 5 разработчиков, 2 QA, PO, дизайнер, аналитик. Спринты — 2 недели. Ретро проводились формально: каждый говорил «всё нормально», PO предлагал «работать лучше», на стикерах — одно и то же каждый спринт: «нечёткие требования», «мало времени на тестирование». Ничего не менялось. Velocity стагнировал на 28 SP. Баги в продакшене — 5-7 за спринт. Команда выгорала. Ануар перестроил ретро: Формат 1 — «Sailboat» (первые 4 ретро): Паруса (что нас двигает), Якоря (что тормозит), Рифы (риски впереди), Остров (куда хотим прийти). Визуально на доске в Miro. Люди начали открываться: «Мне неудобно спрашивать у PO — он всегда занят», «QA получает задачи за 2 часа до конца спринта». Формат 2 — «5 Whys» (для конкретных проблем): Почему баги в продакшене? → Потому что QA тестирует поздно. → Почему поздно? → Потому что разработчики сдают задачи в последний день. → Почему? → Потому что блокеры не эскалируются вовремя. → Решение: ежедневный sync PO + Tech Lead в 10:00 для разблокировки. Главное правило Ануара: «Каждое ретро = минимум 1 Action Item с владельцем и дедлайном». Не «улучшить коммуникацию», а «Асхат настроит автотесты на CI/CD до пятницы». Ануар завёл Notion-базу: все Action Items из ретро, статус (done/in progress/stuck), импакт. На каждом новом ретро — первые 10 минут: проверка предыдущих AI. Через 3 месяца (6 спринтов): Velocity вырос с 28 до 38 SP (+36%). Баги в продакшене: с 5-7 до 1-2 за спринт. eNPS команды: с 12 до 45. PO стал выделять 30 минут в день на вопросы команды (его Action Item из ретро №3). Ануар: «Ретро — не ритуал. Это единственная церемония, которая улучшает ВСЕ остальные процессы. Но только если из ретро выходят конкретные действия, а не абстрактные пожелания».

Бахыт устроился Product Owner в IT-компанию в Шымкенте, которая делала SaaS для автоматизации клиник. До этого он 3 года был аналитиком. Первый месяц — шок: от него ждали всего одновременно: писать User Stories, общаться с клиниками, проводить интервью, приоритизировать бэклог, участвовать в планировании, демо, ретро, и ещё «придумывать стратегию продукта». Бахыт работал по 12 часов, но ничего не успевал. Бэклог — хаос, команда ждёт Stories, CEO спрашивает «где стратегия?», клиенты жалуются в поддержку. Тогда Бахыт составил матрицу ответственности, разделив роли PO и PM: — PO (он): бэклог (приоритизация, Stories, AC), связь с командой разработки, груминг, планирование, приёмка. Фокус: ЧТО строим и КОГДА. — PM-функции (тоже он, но структурировано): discovery (интервью, гипотезы, анализ рынка), стратегия (roadmap, OKR), метрики. Фокус: ЗАЧЕМ строим и ДЛЯ КОГО. Бахыт выделил блоки времени: — Понедельник-среда утро: Discovery (интервью с клиниками, анализ данных) — Среда-четверг: Delivery (Stories, AC, груминг) — Пятница: Стратегия (метрики, roadmap, отчёт CEO) Перестал ходить на все встречи: делегировал технические обсуждения Tech Lead-у, ежедневные стендапы посещал 3 раза в неделю вместо 5. Внедрил систему «PO Office Hours»: каждый день с 14:00 до 15:00 — открытый час для вопросов команды. Вместо 20 сообщений в течение дня — 1 час сфокусированных ответов. Через 2 месяца: бэклог структурирован (3 эпика, 25 Stories с AC), velocity стабилен, провёл 15 интервью с врачами (нашёл главный инсайт: им нужна не CRM, а автоматическое заполнение медкарты по голосу). CEO получил квартальный roadmap с метриками. Бахыт: «PO — не человек, который делает всё. PO — человек, который решает, что делать, а что — нет. В том числе — что НЕ делать самому».