Alina Pro IT
Канал
7
подписчиков
5
ссылок
Бирюзовый профессионально-уютный канал про Product Management, про Startup'ы и про IT в целом
2️⃣ Факт #2: бизнес крайне недоволен
Бизнесу не понравилось все, что он увидел на приемке MVP. Критике подверглось все: скорость, реализация, внешний вид всей функциональности.
“Работать с этим невозможно”, - таков был вердикт в сухом остатке.
Стоит пояснить, почему провал достиг именно такого масштаба. При первичном тестировании продукта, которое обычно проводят разработчики или тестировщики (но не представители бизнеса), можно столкнуться с различными проблемами: неработающая функциональность (это “блокеры”), некорректно работающая основная функциональность (критические ошибки), проблемы с менее важной функциональностью (это так называемые "мажоры"). В хорошо отлаженном IT-процессе за начальную приемку обычно отвечают автотесты или ручные QA-специалисты, которые сверяют реализацию с требованиями. В таких условиях вероятность того, что блокеры и критикалы дойдут до бизнес-приемки, ниже.
В нашем случае, из-за отсутствия полноценных требований (а следовательно, и понимания, как должна работать конкретная функциональность), критические и серьезные проблемы были выявлены, в том числе, и на стадии бизнес-приемки. Только основатель компании понимал, как именно всё должно работать.
В конечном счете, приемка MVP основателем провалилась: продукт был признан неработоспособным (хотя все-таки поработал какое-то время в таком состоянии), результатом работы аутсорс-команды бизнес был недоволен и от дальнейшего сотрудничества с ней отказался.
3️⃣Удивительно, но...
Факт #3: аутсорс-команда осталась в выигрыше
Хотя сотрудничество и не продлилось, все обязательства перед этой командой были выполнены: аутсорс-разработчики получили оплату в полном объеме, как только бизнес “принял” функциональность.
4️⃣ Факт #4: полностью переписанный код
Можно ли сказать, что код аутсорс-команды совсем не работал? Нет. Несмотря на множество проблем в коде, с которыми не хотел мириться бизнес, первый клиент появился, и началась проверка бизнес-идеи.
Забегая вперед, скажу, что код, написанный внешней командой разработки, был полностью переписан in-house командой впоследствии, но это мы обсудим в следующей главе.
🔚 Выводы
Опыт создания первой версии продукта дал понимание, что для достижения поставленных целей, нужна своя собственная команда разработки с прозрачными процессами и профессиональными требованиями. Одних только знаний о рынке ставок (хотя и обширных) оказалось недостаточно.
Хорошо продуманная бизнес-идея — это важный элемент в создании успешного продукта. Но не достаточный. Грамотная реализация и команда компетентных специалистов — еще одна ключевая часть. Хотя и это не гарантирует успех на 100%, но гармоничное сочетание технической экспертизы и знания предметной области значительно увеличивает шансы на достижение поставленных целей.
А специально для тех, кто дочитал и это, здесь я подготовила RoadMap следующих глав, чтобы вы понимали, а что еще захватывающего вас ждет.
❤️Ставьте лайки и подписывайтесь.
Обнимаю! На связи.
#TheStartUp
Бизнесу не понравилось все, что он увидел на приемке MVP. Критике подверглось все: скорость, реализация, внешний вид всей функциональности.
“Работать с этим невозможно”, - таков был вердикт в сухом остатке.
Стоит пояснить, почему провал достиг именно такого масштаба. При первичном тестировании продукта, которое обычно проводят разработчики или тестировщики (но не представители бизнеса), можно столкнуться с различными проблемами: неработающая функциональность (это “блокеры”), некорректно работающая основная функциональность (критические ошибки), проблемы с менее важной функциональностью (это так называемые "мажоры"). В хорошо отлаженном IT-процессе за начальную приемку обычно отвечают автотесты или ручные QA-специалисты, которые сверяют реализацию с требованиями. В таких условиях вероятность того, что блокеры и критикалы дойдут до бизнес-приемки, ниже.
В нашем случае, из-за отсутствия полноценных требований (а следовательно, и понимания, как должна работать конкретная функциональность), критические и серьезные проблемы были выявлены, в том числе, и на стадии бизнес-приемки. Только основатель компании понимал, как именно всё должно работать.
В конечном счете, приемка MVP основателем провалилась: продукт был признан неработоспособным (хотя все-таки поработал какое-то время в таком состоянии), результатом работы аутсорс-команды бизнес был недоволен и от дальнейшего сотрудничества с ней отказался.
3️⃣Удивительно, но...
Факт #3: аутсорс-команда осталась в выигрыше
Хотя сотрудничество и не продлилось, все обязательства перед этой командой были выполнены: аутсорс-разработчики получили оплату в полном объеме, как только бизнес “принял” функциональность.
4️⃣ Факт #4: полностью переписанный код
Можно ли сказать, что код аутсорс-команды совсем не работал? Нет. Несмотря на множество проблем в коде, с которыми не хотел мириться бизнес, первый клиент появился, и началась проверка бизнес-идеи.
Забегая вперед, скажу, что код, написанный внешней командой разработки, был полностью переписан in-house командой впоследствии, но это мы обсудим в следующей главе.
🔚 Выводы
Опыт создания первой версии продукта дал понимание, что для достижения поставленных целей, нужна своя собственная команда разработки с прозрачными процессами и профессиональными требованиями. Одних только знаний о рынке ставок (хотя и обширных) оказалось недостаточно.
Хорошо продуманная бизнес-идея — это важный элемент в создании успешного продукта. Но не достаточный. Грамотная реализация и команда компетентных специалистов — еще одна ключевая часть. Хотя и это не гарантирует успех на 100%, но гармоничное сочетание технической экспертизы и знания предметной области значительно увеличивает шансы на достижение поставленных целей.
А специально для тех, кто дочитал и это, здесь я подготовила RoadMap следующих глав, чтобы вы понимали, а что еще захватывающего вас ждет.
❤️Ставьте лайки и подписывайтесь.
Обнимаю! На связи.
#TheStartUp
GitHub
The StartUp: History • morozovskayaalina
Обреченный на успех StartUp
Глава 2. От идеи к MVP
В этой главе я расскажу про процесс запуска MVP в The StartUp с аутсорс-командой разработки: как и кем готовились продуктовые требования, как велась передача этих требований, как проходила приемка и какие получились результаты.
Важно подчеркнуть один ключевой момент: для основателя стартапа не существовало понятия минимально жизнеспособного продукта (MVP) в привычном смысле. Для него аббревиатура MVP всегда ассоциировалась с "Most Valuable Player" — самым ценным игроком команды. Бизнес стремился к созданию полноценной и серьезной первой версии продукта, исключая любые полумеры. Для удобства в статье я буду использовать термин MVP, подразумевая первую полноценную версию продукта.
Что же получите вы, дорогие читатели? Ответ на вопрос: может ли хорошая идея стать успешным продуктом с первого раза?
💁 Команда The StartUp
Внутренняя команда на момент запуска MVP состояла из основателя и операционной команды - молодых ребят, вчерашних студентов, нанятых на позиции аналитиков. Часть этой операционной команды и станет первой продуктовой командой компании.
Было решено запускать MVP по следующему процессу: внутренняя команда подготовит продуктовые требования, передаст аутсорс-команде разработки, команда разработки изолированно напишет весь код и передаст продукт на приемку. Этот процесс напоминал классическую модель Waterfall.
📄 Первая продуктовая документация
Продуктовая документация, подготовленная импровизированной командой без продактов, аналитиков и дизайнеров, представляла собой схематичные мокапы и верхнеуровневые описания того, как должен работать продукт. Вся информация для документации была получена путем интервьюирования основателя, который рассказал, что и как нужно сделать, чтобы VIP-клиенты могли ставить ставки на большие суммы.
Документация, подготовленная со слов основателя, была передана команде разработки и команда отправилась писать код. Процесс не предполагал постоянную коммуникацию с внешней командой в процессе разработки.
🧑💻 Внешняя команда разработки
Общение между внутренней продуктовой командой и командой разработки велось и ограничивалось контактированием с одним человеком, чья функциональность была схожа с обязанностями СТО (Технического директора). Общение ограничивалось передачей схематичных требований, созвонами по точечным проблемам и обсуждениями финансовых вопросов.
Процесс в команде разработки для продакта, чаще всего, это черный ящик. Процесс в команде разработки на аутсорсе — это черный ящик в плаще невидимке. Мы могли бы спекулировать на тему процессов внутри команды разработки на аутсорсе, могли бы гадать и предполагать кто именно писал код и какой квалификацией обладали разработчики, но вместо этого мы будем опираться на факты.
1️⃣ Факт #1: блокеры на первой приемке
После изолированной разработки операционной команде предстояло провести первичную приемку продукта и передать эстафету бизнесу. Операционная команда в распоряжение получила MVP продукта, который представлял из себя операторскую и клиентскую части. Операторы могли управлять запросами клиентов, вести чат и управлять спортивными событиями, а клиенты - делать ставки и общаться с операторами.
Процесс приемки включал тестирование пользовательских сценариев, фиксацию ошибок в Google-документе и передачу этих ошибок разработчикам для исправления.
В каждом пользовательском сценарии, при первом же взаимодействии с функциональностью, находились фатальные проблемы, превращающие функциональность в нерабочую. Результаты первой приемки намекали, что в аутсорс-команде разработчики не проверяли, как работает их код, а QA-специалистов либо не было вовсе, либо их квалификация оставляла желать лучшего.
После нескольких итераций исправления проблем продукт выглядел рабочим: очевидные пользовательские сценарии работали без видимых проблем. Было принято решение устроить приемку с участием бизнеса, потому что, кроме прочего, сроки реализации, согласованные бизнесом и командой разработки, уже прошли. Бизнесу нужен был результат.
ПРОДОЛЖЕНИЕ НИЖЕ 👇
#TheStartUp
Глава 2. От идеи к MVP
В этой главе я расскажу про процесс запуска MVP в The StartUp с аутсорс-командой разработки: как и кем готовились продуктовые требования, как велась передача этих требований, как проходила приемка и какие получились результаты.
Важно подчеркнуть один ключевой момент: для основателя стартапа не существовало понятия минимально жизнеспособного продукта (MVP) в привычном смысле. Для него аббревиатура MVP всегда ассоциировалась с "Most Valuable Player" — самым ценным игроком команды. Бизнес стремился к созданию полноценной и серьезной первой версии продукта, исключая любые полумеры. Для удобства в статье я буду использовать термин MVP, подразумевая первую полноценную версию продукта.
Что же получите вы, дорогие читатели? Ответ на вопрос: может ли хорошая идея стать успешным продуктом с первого раза?
💁 Команда The StartUp
Внутренняя команда на момент запуска MVP состояла из основателя и операционной команды - молодых ребят, вчерашних студентов, нанятых на позиции аналитиков. Часть этой операционной команды и станет первой продуктовой командой компании.
Было решено запускать MVP по следующему процессу: внутренняя команда подготовит продуктовые требования, передаст аутсорс-команде разработки, команда разработки изолированно напишет весь код и передаст продукт на приемку. Этот процесс напоминал классическую модель Waterfall.
📄 Первая продуктовая документация
Продуктовая документация, подготовленная импровизированной командой без продактов, аналитиков и дизайнеров, представляла собой схематичные мокапы и верхнеуровневые описания того, как должен работать продукт. Вся информация для документации была получена путем интервьюирования основателя, который рассказал, что и как нужно сделать, чтобы VIP-клиенты могли ставить ставки на большие суммы.
Документация, подготовленная со слов основателя, была передана команде разработки и команда отправилась писать код. Процесс не предполагал постоянную коммуникацию с внешней командой в процессе разработки.
🧑💻 Внешняя команда разработки
Общение между внутренней продуктовой командой и командой разработки велось и ограничивалось контактированием с одним человеком, чья функциональность была схожа с обязанностями СТО (Технического директора). Общение ограничивалось передачей схематичных требований, созвонами по точечным проблемам и обсуждениями финансовых вопросов.
Процесс в команде разработки для продакта, чаще всего, это черный ящик. Процесс в команде разработки на аутсорсе — это черный ящик в плаще невидимке. Мы могли бы спекулировать на тему процессов внутри команды разработки на аутсорсе, могли бы гадать и предполагать кто именно писал код и какой квалификацией обладали разработчики, но вместо этого мы будем опираться на факты.
1️⃣ Факт #1: блокеры на первой приемке
После изолированной разработки операционной команде предстояло провести первичную приемку продукта и передать эстафету бизнесу. Операционная команда в распоряжение получила MVP продукта, который представлял из себя операторскую и клиентскую части. Операторы могли управлять запросами клиентов, вести чат и управлять спортивными событиями, а клиенты - делать ставки и общаться с операторами.
Процесс приемки включал тестирование пользовательских сценариев, фиксацию ошибок в Google-документе и передачу этих ошибок разработчикам для исправления.
В каждом пользовательском сценарии, при первом же взаимодействии с функциональностью, находились фатальные проблемы, превращающие функциональность в нерабочую. Результаты первой приемки намекали, что в аутсорс-команде разработчики не проверяли, как работает их код, а QA-специалистов либо не было вовсе, либо их квалификация оставляла желать лучшего.
После нескольких итераций исправления проблем продукт выглядел рабочим: очевидные пользовательские сценарии работали без видимых проблем. Было принято решение устроить приемку с участием бизнеса, потому что, кроме прочего, сроки реализации, согласованные бизнесом и командой разработки, уже прошли. Бизнесу нужен был результат.
ПРОДОЛЖЕНИЕ НИЖЕ 👇
#TheStartUp
Всем привет!
Вторая глава из цикла "Обреченный на успех StartUp" уже доступна в Телеграфе.
Приятного чтения!
Ниже продублирую статью, чтобы было удобно поставить лайки 🙈
Вторая глава из цикла "Обреченный на успех StartUp" уже доступна в Телеграфе.
Приятного чтения!
Ниже продублирую статью, чтобы было удобно поставить лайки 🙈
Telegraph
Обреченный на успех StartUp
Глава 2. От идеи к MVP В этой главе я расскажу про процесс запуска MVP в The StartUp с аутсорс-командой разработки: как и кем готовились продуктовые требования, как велась передача этих требований, как проходила приемка и какие получились результаты. Важно…
🧨 Каналы привлечения клиентов
The StartUp не нуждался в массовом маркетинге. В текущей модели бизнеса компания делала ставку на качество крупных клиентов, но не на количество. Привлечение клиентов основывалось на личных связях. Основатель сам выполнял роль маркетолога, и каждый клиент был знаком с ним лично. Это был подход P2P (people-to-people, не путать с peer to peer), где отношения с клиентами строились на доверии и личном контакте.
💸 Основные расходы и доходы
Запуск The StartUp безусловно требовал серьёзных инвестиций. Основными расходами были:
- Поддержка крупной и высококвалифицированной IT-команды.
- Банкролл для выплаты выигрышей клиентам.
Финансовую безопасность обеспечивал сторонний инвестор, который стабильно поддерживал проект.
The StartUp стремился зарабатывать не только на хеджировании ставок на безрисковые рынки, но и, как любой букмекер, на марже с каждой ставки.
💯 Неочевидное преимущество
Ключевым конкурентным преимуществом The StartUp были связи и опыт основателя, которые позволяли компании:
- находить крупных клиентов, делающих VIP-ставки;
- привлекать значительные инвестиции, обеспечивающие стабильную работу проекта;
- переставлять крупные ставки на других букмекерских площадках, что давало возможность предлагать VIP-клиентам по-настоящему эксклюзивные условия для ставок — условия, которые не могли предложить другие участники рынка.
🔚 Заключение первой главы нашей эпопеи
Как видите, стартап The StartUp был основан на идее, которая казалась достойной. Отличная бизнес-модель, серьёзная подготовка, мощные связи и точное понимание потребностей VIP-клиентов — всё это создавало ощущение неизбежного успеха.
В следующих главах мы продолжим разбирать каждый шаг развития The StartUp и погрузимся в процессы, которые выстраивались в IT и операционной команде. Мы рассмотрим принятые решения и их влияние на дальнейший ход событий.
А специально для тех, кто дочитал, здесь я подготовила RoadMap следующих глав, чтобы вы понимали, а что еще захватывающего вас ждет.
❤️Ставьте лайки и подписывайтесь.
Обнимаю! На связи.
#TheStartUp
The StartUp не нуждался в массовом маркетинге. В текущей модели бизнеса компания делала ставку на качество крупных клиентов, но не на количество. Привлечение клиентов основывалось на личных связях. Основатель сам выполнял роль маркетолога, и каждый клиент был знаком с ним лично. Это был подход P2P (people-to-people, не путать с peer to peer), где отношения с клиентами строились на доверии и личном контакте.
💸 Основные расходы и доходы
Запуск The StartUp безусловно требовал серьёзных инвестиций. Основными расходами были:
- Поддержка крупной и высококвалифицированной IT-команды.
- Банкролл для выплаты выигрышей клиентам.
Финансовую безопасность обеспечивал сторонний инвестор, который стабильно поддерживал проект.
The StartUp стремился зарабатывать не только на хеджировании ставок на безрисковые рынки, но и, как любой букмекер, на марже с каждой ставки.
💯 Неочевидное преимущество
Ключевым конкурентным преимуществом The StartUp были связи и опыт основателя, которые позволяли компании:
- находить крупных клиентов, делающих VIP-ставки;
- привлекать значительные инвестиции, обеспечивающие стабильную работу проекта;
- переставлять крупные ставки на других букмекерских площадках, что давало возможность предлагать VIP-клиентам по-настоящему эксклюзивные условия для ставок — условия, которые не могли предложить другие участники рынка.
🔚 Заключение первой главы нашей эпопеи
Как видите, стартап The StartUp был основан на идее, которая казалась достойной. Отличная бизнес-модель, серьёзная подготовка, мощные связи и точное понимание потребностей VIP-клиентов — всё это создавало ощущение неизбежного успеха.
В следующих главах мы продолжим разбирать каждый шаг развития The StartUp и погрузимся в процессы, которые выстраивались в IT и операционной команде. Мы рассмотрим принятые решения и их влияние на дальнейший ход событий.
А специально для тех, кто дочитал, здесь я подготовила RoadMap следующих глав, чтобы вы понимали, а что еще захватывающего вас ждет.
❤️Ставьте лайки и подписывайтесь.
Обнимаю! На связи.
#TheStartUp
Полная версия статьи еще и тут 🤓
Обреченный на успех StartUp
Глава 1. Как все начиналось
Этой статьей мы начинаем цикл рассказов о стартапе, который для анонимности будем называть The StartUp.
Этот стартап был обречен на успех: у него было всё необходимое для этого, а возможно, даже больше.
Все повествование ведётся от моего лица, лица продакта. А если быть точнее — от лица Шивы, который делал разные дела. В разное время (а иногда и параллельно) я занималась операционной деятельностью, проводила демонстрации нашего продукта, переводила с «инвесторского» языка на IT-командный и обратно, писала PRD, ревьювила FR и дизайны, проводила кик-офы, составляла обучающую документацию для операционного отдела и клиентов, запускала внутренние продукты с командой внешних подрядчиков.
Этот цикл будет посвящён целой жизни — бесценной эпохе The StartUp.
Я расскажу вам, как всё начиналось, как развивалось и настраивалось, какие процессы были успешно внедрены, а какие — не очень.
Что получите вы, мои дорогие читатели? Опыт работы в стартапе без смс и регистрации, а точнее — без каких-либо рисков. Пристегните ремни, вас ждёт история о больших деньгах, высоких ставках и неожиданных поворотах.
В этой статье мы разберем идею The StartUp по косточкам, используя стандартный подход Lean Canvas (о, боже!). Проанализируем всё, что было у проекта на старте.
По моему мнению, The StartUp — это каноническая идея успешного стартапа. Кажется, что продумано было вообще всё (или почти всё?).
✨Идея
The StartUp зародился из идеи крупного в прошлом покерного игрока, который хотел совершить революцию в мире беттинга. Его замысел состоял в создании платформы для VIP-ставок, где состоятельные люди могли бы играть по-крупному.
Основной проблемой, которую решал The StartUp, было неудобство, с которым сталкивались VIP-игроки при размещении крупных ставок. До запуска стартапа крупные игроки ставили миллионы (и это не преувеличение) через мессенджеры, такие как Skype, WhatsApp и даже ICQ (вспомнили этот звук? уже свело old-скулы?). Это было, мягко говоря, далеко от того уровня VIP-обслуживания, которое ожидали такие клиенты.
🙍♀️🙍♂️Целевые сегменты
The StartUp ориентировался на два ключевых сегмента клиентов:
- Богатые бизнесмены — владельцы крупных компаний и инвесторы, желающие ставить крупные суммы.
- Профессиональные игроки — эксперты, делающие ставки только на тщательно проанализированные рынки с честными, по их модели, коэффициентами.
⭐Уникальность и бизнес модель
Уникальное предложение продукта заключалось в отсутствии лимитов на суммы ставок. В то время как другие букмекеры склонны иметь безлимит Шредингера (заявляется, что лимита нет, а практике – это неожиданные ограничениям после выигрыша). Однако основатель имел связи в крупных букмекерских конторах, что позволяло хеджировать ставки у других букмекеров, тем самым диверсифицируя риски.
Например, при ставке в 100 тысяч долларов, компания могла переставить эту же ставку на аналогичный рынок в другой конторе. В случае проигрыша клиента (и выигрыша компании) компания выплачивала букмекерской конторе сумму выигрыша клиента, а в случае выигрыша клиента (проигрыша компании) — выплачивала клиенту за счет выигрыша на переставленной ставке.
Бизнес-модель была несколько сложнее, чем просто хеджирование ставок на аналогичные рынки. Когда ставил профессиональный игрок, операционный отдел не только переставлял ставки, но и делал ставки на смежные рынки. То есть профессионалы были “аналитикам”, благодаря которым в большинстве случае можно было выявить гипотетически безрисковую ставку. Таким образом, ставка на один исход от профессионального игрока приводила к ряду ставок на “безрисковые” смежные рынки, что увеличивало доход.
ПРОДОЛЖЕНИЕ НИЖЕ 👇
Обреченный на успех StartUp
Глава 1. Как все начиналось
Этой статьей мы начинаем цикл рассказов о стартапе, который для анонимности будем называть The StartUp.
Этот стартап был обречен на успех: у него было всё необходимое для этого, а возможно, даже больше.
Все повествование ведётся от моего лица, лица продакта. А если быть точнее — от лица Шивы, который делал разные дела. В разное время (а иногда и параллельно) я занималась операционной деятельностью, проводила демонстрации нашего продукта, переводила с «инвесторского» языка на IT-командный и обратно, писала PRD, ревьювила FR и дизайны, проводила кик-офы, составляла обучающую документацию для операционного отдела и клиентов, запускала внутренние продукты с командой внешних подрядчиков.
Этот цикл будет посвящён целой жизни — бесценной эпохе The StartUp.
Я расскажу вам, как всё начиналось, как развивалось и настраивалось, какие процессы были успешно внедрены, а какие — не очень.
Что получите вы, мои дорогие читатели? Опыт работы в стартапе без смс и регистрации, а точнее — без каких-либо рисков. Пристегните ремни, вас ждёт история о больших деньгах, высоких ставках и неожиданных поворотах.
В этой статье мы разберем идею The StartUp по косточкам, используя стандартный подход Lean Canvas (о, боже!). Проанализируем всё, что было у проекта на старте.
По моему мнению, The StartUp — это каноническая идея успешного стартапа. Кажется, что продумано было вообще всё (или почти всё?).
✨Идея
The StartUp зародился из идеи крупного в прошлом покерного игрока, который хотел совершить революцию в мире беттинга. Его замысел состоял в создании платформы для VIP-ставок, где состоятельные люди могли бы играть по-крупному.
Основной проблемой, которую решал The StartUp, было неудобство, с которым сталкивались VIP-игроки при размещении крупных ставок. До запуска стартапа крупные игроки ставили миллионы (и это не преувеличение) через мессенджеры, такие как Skype, WhatsApp и даже ICQ (вспомнили этот звук? уже свело old-скулы?). Это было, мягко говоря, далеко от того уровня VIP-обслуживания, которое ожидали такие клиенты.
🙍♀️🙍♂️Целевые сегменты
The StartUp ориентировался на два ключевых сегмента клиентов:
- Богатые бизнесмены — владельцы крупных компаний и инвесторы, желающие ставить крупные суммы.
- Профессиональные игроки — эксперты, делающие ставки только на тщательно проанализированные рынки с честными, по их модели, коэффициентами.
⭐Уникальность и бизнес модель
Уникальное предложение продукта заключалось в отсутствии лимитов на суммы ставок. В то время как другие букмекеры склонны иметь безлимит Шредингера (заявляется, что лимита нет, а практике – это неожиданные ограничениям после выигрыша). Однако основатель имел связи в крупных букмекерских конторах, что позволяло хеджировать ставки у других букмекеров, тем самым диверсифицируя риски.
Например, при ставке в 100 тысяч долларов, компания могла переставить эту же ставку на аналогичный рынок в другой конторе. В случае проигрыша клиента (и выигрыша компании) компания выплачивала букмекерской конторе сумму выигрыша клиента, а в случае выигрыша клиента (проигрыша компании) — выплачивала клиенту за счет выигрыша на переставленной ставке.
Бизнес-модель была несколько сложнее, чем просто хеджирование ставок на аналогичные рынки. Когда ставил профессиональный игрок, операционный отдел не только переставлял ставки, но и делал ставки на смежные рынки. То есть профессионалы были “аналитикам”, благодаря которым в большинстве случае можно было выявить гипотетически безрисковую ставку. Таким образом, ставка на один исход от профессионального игрока приводила к ряду ставок на “безрисковые” смежные рынки, что увеличивало доход.
ПРОДОЛЖЕНИЕ НИЖЕ 👇
Первая глава из цикла "Обреченный на успех StartUp" уже в телеграфе, а если неудобно в телеграфе, то можно ниже прямо тут прочитать отредактированную версию.
Здесь будет храниться и обновляться RoadMap следующих глав, чтобы вы понимали, а что еще захватывающего вас ждет.
Приятного чтения 🤗
https://telegra.ph/Obrechennyj-na-uspeh-StartUp-09-08
Здесь будет храниться и обновляться RoadMap следующих глав, чтобы вы понимали, а что еще захватывающего вас ждет.
Приятного чтения 🤗
https://telegra.ph/Obrechennyj-na-uspeh-StartUp-09-08
Всем привет!
Написала тут лонгрид про эффективные (и не очень!) компании и оптимизацию.
Интересный факт: я поработала и в корпорации, и в богатом стартапе и в совсем крошечном и могу сказать, что везде есть свои плюсы и минусы (спасибо, кэп!).
Если хочется спокойной жизни и работы с 9 до 18:00, но при этом не очень понимать, что и для чего вы делаете, то корпорация - прекрасный выбор 🤗
Если хочется не спать ночами, работать по выходным и быть ответственным за все, то тогда стартап - это то, что вас устроит 😂
https://telegra.ph/Kak-uyutnye-startapy-prevrashchayutsya-v-nepovorotlivye-korporacii-ili-zachem-eshche-mozhet-ponadobitsya-PRD-09-06
Следующая на очереди статья - идеальная идея стартапа 🫡
Написала тут лонгрид про эффективные (и не очень!) компании и оптимизацию.
Интересный факт: я поработала и в корпорации, и в богатом стартапе и в совсем крошечном и могу сказать, что везде есть свои плюсы и минусы (спасибо, кэп!).
Если хочется спокойной жизни и работы с 9 до 18:00, но при этом не очень понимать, что и для чего вы делаете, то корпорация - прекрасный выбор 🤗
Если хочется не спать ночами, работать по выходным и быть ответственным за все, то тогда стартап - это то, что вас устроит 😂
https://telegra.ph/Kak-uyutnye-startapy-prevrashchayutsya-v-nepovorotlivye-korporacii-ili-zachem-eshche-mozhet-ponadobitsya-PRD-09-06
Следующая на очереди статья - идеальная идея стартапа 🫡
Telegraph
Как уютные стартапы превращаются в неповоротливые корпорации, или зачем еще может понадобиться PRD
In a nutshell Все счастливые семьи похожи друг на друга, каждая несчастливая семья несчастлива по-своему. Эта знаменитая фраза Льва Толстого подходит и к корпоративной среде. Все успешные компании похожи: они гибкие, быстрые, и каждый сотрудник понимает свою…
Alina Pro IT pinned «Приветствую тебя, дорогой друг, в нашем уютном бирюзовом стартапе канале про IT. Меня зовут Алина, и я здесь хочу делиться с вами полезной информацией из мира IT и продуктового менеджмента. Вместе мы будем разбираться в тонкостях Product Management и обсуждать…»
Приветствую тебя, дорогой друг, в нашем уютном бирюзовом стартапе канале про IT.
Меня зовут Алина, и я здесь хочу делиться с вами полезной информацией из мира IT и продуктового менеджмента.
Вместе мы будем разбираться в тонкостях Product Management и обсуждать интересные стартапы — как свои, так и чужие.
Расскажу 3 факта о себе:
1. Я закончила факультет прикладной математики и информатики вышки
2. Работала в вип-беттинговом стартапе продактом
3. Сейчас продолжаю заниматься продуктовой разработкой в своем стартапе, мечтаю о бирюзовой (Teal) компании.
Присоединяйтесь, оставайтесь и давайте разбираться в IT вместе 🤗
Меня зовут Алина, и я здесь хочу делиться с вами полезной информацией из мира IT и продуктового менеджмента.
Вместе мы будем разбираться в тонкостях Product Management и обсуждать интересные стартапы — как свои, так и чужие.
Расскажу 3 факта о себе:
1. Я закончила факультет прикладной математики и информатики вышки
2. Работала в вип-беттинговом стартапе продактом
3. Сейчас продолжаю заниматься продуктовой разработкой в своем стартапе, мечтаю о бирюзовой (Teal) компании.
Присоединяйтесь, оставайтесь и давайте разбираться в IT вместе 🤗
