Привет, я Сергей, продакт из Лиги Ставок. Год назад я возглавил команду, которая уже несколько лет развивала систему триггерных коммуникаций в наших международных проектах. Это была тяжеловесная платформа, изначально созданная для интернет-магазинов — и это сразу чувствовалось. Любое мелкое изменение превращалось в сложный процесс с кучей долгих согласований, переписок, созвонов с менеджерами платформы.
После недавнего обновления основного сайта наш Product Owner завел множество задач на редизайн или переработку одной из сделанных механик. Все они отправились в backlog, но одна из них выделялась особо — создание нового Колеса фортуны.
Привет, Хабр!
Сегодня я расскажу, как с помощью Liquibase, GitLab и немного Python настроить прозрачный, безопасный и удобный процесс миграций для ClickHouse кластера .
Недавно мы в Лиге Ставок обновили наш основной сайт. Изменения кардинальные. По сути мы выкинули старый, и на его место выпустили новый продукт. Можно сказать, мы убили устоявшуюся годами привычку пользователя и предложили ему сформировать новый паттерн использования. Как это отразилось на метриках? Стало лучше? Хуже? Сейчас расскажу.
Привет, Хабр! Меня зовут Роман Мирошин, я ведущий системный аналитик в компании «Лига Ставок». Сегодня расскажу историю о том, как наша команда запускала новогодний раздел.
Работа тестировщика кажется простой только на первый взгляд. На практике даже опытные Manual QA специалисты совершают ошибки, которые могут стоить команде времени, денег и репутации. В этой статье мы рассмотрим 10 ошибок, которых стоит избегать.
В прошлой статье мы обсудили, как подход “сначала данные, потом решение” помогает продуктовым командам принимать обоснованные решения и избегать ошибок. Сегодня мы продолжим эту тему и углубимся в процесс проверки гипотез. Разберёмся, какие этапы включает этот процесс, как тестировать идеи без сложной разработки, и как фреймворк Jobs-to-be-Done (JTBD)помогает находить новые возможности для развития продукта.
Что такое гипотеза и зачем её проверять?
Гипотеза — это предположение о том, что определённое действие приведёт к определённому результату. В мире продуктов это может выглядеть так:
“Если мы предложим персонализированные рекомендации ставок, то увеличим конверсию в повторные ставки на 15%, потому что пользователи будут чаще видеть интересные для них события”.
Зачем проверять гипотезы? Всё просто: интуиция — не лучший советчик, когда речь идёт о развитии продукта. Ошибочные предположения могут стоить времени, денег и даже репутации. Проверяя гипотезы, вы минимизируете риски и находите решения, которые действительно работают.
Как помогает JTBD в поиске гипотез?
Фреймворк Jobs-to-be-Done (JTBD) предлагает смотреть на продукт не через призму функций или интерфейса, а через “работы”, которые пользователь хочет выполнить. Суть подхода в следующем:
Люди “нанимают” продукт, чтобы решить конкретную задачу или выполнить “работу”.
Применение JTBD помогает глубже понять мотивацию пользователя и формулировать гипотезы, которые решают реальные задачи.
Пример в контексте ставок:
• Пользователь “нанимает” букмекерскую платформу, чтобы почувствовать азарт, развлечься или использовать свои знания в спорте.
Технологии в финансовой сфере распространяются с большой скоростью, это заметил каждый. Стикеры на телефон вместо пластиковых карт, оплата в пару кликов, мгновенные переводы средств — удобные для пользователей вещи являются результатом оптимизации финансовых операций. Кто же такой финтех и как он делает жизнь бизнесов разнообразнее, а повседневные активности людей удобнее? Давайте разбираться.
Коллеги недавно прислали в чат фотографию, где одной из команд вручают приз за 299 проверенных гипотез за год.
Все неловко призадумались...
Во времена господства data driven, компании запускают сотни тестов чтобы полагаться на данные при принятии решения, стараясь тем самым быть более осознанными. Проблема в том, что если не учитывать тонкости во время тестов, то все ваше время на них может быть потрачено зря и решения которые вы примите на самом деле окажутся ничем не подкреплены. Проводя собесы аналитиков к нам в команду, я выявил топ 5 упущений, которые существуют на их текущей работе или они их допустили при выполнении задания.
Успешная реферальная программа может обеспечивать 20-30% от всех привлекаемых в продукт пользователей
Мы с командой в 20 раз вырастили реферальный канал привлечения новых пользователей.
Статья будет полезна тем, кто работает с привлечением новых пользователей: продактам, маркетологам и предпринимателям.
В этой статье я поделюсь, как мы с командой в реальности по шагам разрабатывали продукт на основе метода Lean Startup
Как часто вы задумываетесь над тем, выбрали ли вы правильную метрику? Мы с командой часто задаем себе вопрос «почему?». Чтобы добраться до сути, обычно нужно задать его 3-5 раз.
Привет, меня зовут Максим, я Product Owner направления Social в Лиге Ставок. Недавно я прочитал книгу Нира Эйаля «Hooked. На крючке. Как создавать продукты, формирующие привычки». После прочтения я смог взглянуть на свой продукт под новым углом и порефлексировать над бэклогом.
В этой статье я хочу рассказать о концепции. Возможно, этот фреймворк натолкнет вас на новые мысли.
Статья не претендует на научность, а просто рассказывает, как бывает в жизни, когда уже прошел все курсы, проверил разные гипотезы, но все еще получаешь новый опыт. На моем примере вы увидите как не нужно «впиваться» в конкретную фичу и биться с ней до конца, отпускать — это нормально, ошибки — это нормально.
В этой статье я хочу поделиться процессом адаптации и онбординга для новых разработчиков в нашей компании.
Что такое Agile? Как гибкие подходы могут помочь в работе, бизнесе или даже в обычной жизни? В этой статье вы узнаете, что Agile-принципам можно следовать даже при приготовлении новогоднего оливье. Будет полезно всем, кто хотя бы раз сталкивался с таким непростым делом, как подготовка новогоднего стола!
Статья будет полезна тем, кто стремится сделать свои продукты более социальными и задумывается над внедрением площадки для общения между пользователями.
Меня зовут Омарков Виктор и в Лиге Ставок я product owner. Продукт, над которым мы работаем с командой — это платежи. Все транзакции (депозиты/выводы), которые делает пользователь, проходят через нас. Наша команда является своеобразным банком внутри компании. Когда я пришел в компанию, меня ждал большой пул технических задач по переезду на новую микросервисную архитектуру, но натура продакта требовала зарабатывать деньги на продукте.
Передо мной встал вопрос: «Как просто и быстро заработать на платежах, не продавая данные о пользователе?».
Знакома ли вам ситуация, когда несколько команд, работающих над одним продуктом мешают друг другу и делают одно и тоже? Или наоборот, команды бегут в разные стороны, не имея единой точки синхронизации и не понимая общей цели?
Давайте разберемся как решить эту проблему на кейсе Лиги Ставок.
