Голосуем за идеи

По поводу выбора идеи для проверки на курсе. Чтобы не впасть в analysis paralysis, поступим по-научному. Загнал все идеи в гугл спредшит. Добавил колонки с важными свойствами идей. Вдохновлялся прекрасным шаблоном инвестиционной презентации от Илья Королев из ФРИИ (ссылка в конце). Субъективно расставил оценки. Отсортировал по общему баллу и вуаля (я у мамы инженер)!

Предлагаю выбирать из ТОП 10 идей, набравших больший балл:

1 АрендаПодСобытия

2 РезервацияЗала

3 ЗаписьНаПрием

4 ЛучшаяЦена

5 ЛкТуриста

6 ПодариМне

7 ТиндерСоветник

8 ЗаявкаНаПокупку

9 Английский

10 Профориентация

Опрос будет только в ТГ: t.me/ProdManWay/49

А на ФБ опроса не будет, т.к. гражданин Цукерберг полагает, что на любой вопрос в жизни есть только 2 ответа или даже один (42). Товарищ Дуров же более тертый калач и в ТГ опросы состоят из 10 опций.

График распределения оценок довольно гладкий, в среднем разрыв между соседними идеями 0-2 балла, ТОП проект набрал 62 (из 65 возможных), а минимальная оценка 23. До столкновения с реальностью все проекты выглядят плюс-минус ОК. Представляю, как сложно работать в инвест. фондах на входящей воронке и судить венчурные конкурсы!

Буду весьма благодарен, если у кого-либо из тех, кто профессионально оценивает бизнес-идеи, найдется время обсудить ТОП 10 и посоветовать, какую прорабатывать следующие 2 мес. Лучше это сделать до 24_00 ВС 23 июня по скайпу/тлф или встретиться лично за обедом (я оплачу счет).

Ссылка на гугл спредшит со всеми идеями и проставленными баллами:

https://drive.google.com/open…

Ссылка на шаблон инвестиционной презентации ФРИИ: https://drive.google.com/open…

Анализ идей

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

Проблема всё та же – выбор идеи, которую буду прорабатывать в процессе курса продукт менеджмента. Вспомнил про свой старый пост, где по наводке Любови Симоновой сделал инфографику, какой продукт считается ОК. На пересечении: а) денежной ниши б) острой боли и в) легкого решения проблемы. Пост найти не смог, поиск в ФБ полный отстой.

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

Добавил в таблицу с идеями колонки "Боль" и "Часто". Проставил оценки, но картина не сильно прояснилась.

В результате, как это принято в России, воспользовался нечестным конкурентным преимуществом. Написал куче людей из френдов на ФБ и у некоторых нашлось время поговорить. Суров и краток был трекер из ВШЭ – "Я не понимаю искусственных задач" и отказался комментировать идеи. Решения должны вытекать из экспертизы и общения с клиентами, а не браться из головы и кабинетного анализа. Это-то понятно, а делать-то что? Да и время поджимает…

К счастью, откликнулся биздев из Яндекса. Я попросил у него 15-20 минут "мне только спросить", а промучил его почти час. ТОП 10 идей разбил в пух и прах. Более менее, ОК две идеи.

Список отстойных идей из ТОП 10:

1) БотАдминов (№21) – В Яндексе есть такой чат бот, узнать, например, чья машина с номером Х перегородила выезд. У крутых компаний проблема решена (вики, шарепоинт портал, тупо телефон суппорта), а некрутые слишком бедные, чтобы позволить новое решение.

2) Английский(№2) – Рынок созрел и Скайенг всех нагнул, с "обычными" курсами типа ЛингуаЛео ловить нечего, только если есть что-то такое же прорывное как Скай.

3) Компмастер (№1) – Есть Авито, Профи.ру и др.

4) ТиндерЗащитник (№16) и ТиндерСоветник (№18) – Дейтинг не его профиль, но явно тяжело будет делать интеграцию с тем же Тиндером и вряд ли удастся выцепить фото и переписку из их мобаппов наружу.

5) ШарингСмарта (№4) – Гугл диск стоит копейки, майнинг и рассылка спама с чужих девайсов более интересно, но есть юридические проблемы.

6) АрендаПодСобытие (№58) и РезервацияЗала (№61) – У таких сервисов (ERP) главная проблема – владельцы заведений всегда ставят "Свободен" в статус бронирования. Клиент им звонит, ему говорят, что:

а) именно на его дату вдруг занято, а есть другая дата (в системе что-то напутали) и

б) предлагают провести оплату вне системы

В случае (а) клиент говорит что в сервисе работают мудаки и уходит. В случае (б) заработок сервиса равен нулю.

7) ЛкТуриста (№5) – Нет острой проблемы, узкая ниша, редкие транзакции клиента. Более менее ОК если сможешь сделать агрегатор скидок или решить проблемы в других сегментах в тревеле – командировочные сотрудники, бизнес-поездки, движуха вокруг эвентов.

Честно говоря, это был мой любимый проект из всех. Так тяжело его выкидывать! Я подумал, ну вот, я часто самостоятельно путешествую. Последняя поездка по Европе была на 9 суток, 8 городов, 4 отеля. Планирование поездки и покупки заняли у меня 2 дня фуллтайм. Уйму всего купить, билеты, брони, прочитать отзывы об отелях, сохранить в телефон для офлайн доступа карты, инфу об отелях, адреса и маршруты транспорта. Важен тайминг – надо вовремя выйти из отеля на очередной этап путешествия. Вечером каждого дня в поездке написать пост с впечатлениями и выложить фоточки во все соц. сети. Вот бы мне сэкономили время и хотя бы закачали в мобапп все карты и билеты и дали готовый шаблон для путешествия, какие города посетить за неделю по разным регионам Европы.

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

В 2х словах – экономика проекта не сходится. Лучший продукт не всегда означает хороший бизнес. Самостоятельно путешествуют 1%, узнают о вашем продукте 1% из них, воспользуются – 1% из вторых, а даже если воспользуются, то в следующий раз вернутся в приложение при следующем отпуске через 6-12 мес если вспомнят (CAC намного больше LTV, Retention в жопе, масштабируем убытки – ахиллесова пята B2C проектов). Основную прибыль зарабатывают первые в цепочке путешествия – отели и авиакомпании. Вторые в очереди агрегаторы и метапоисковики (букинг, скайсканер) откусывают от пирога немного. Приложение планировщик отпуска – третье в очереди и будет довольствоваться крохами от того, что не доели первая и вторая категории.

Какие проекты более-менее ОК по мнению биздева из YNDX:

1) ЗаявкаНаПокупку (№49) – Может сработать, особенно для трудно сравниваемых, но дорогих товаров "Хочу трешку в ЗАО за 16млн" или "Куплю подержанный джип не дороже 3х лямов". С точным определением товара хуже "Дайте самый дешевый iPhone XS Max 512GB Silver". Плюсы – большой чек. Проблемы тоже есть – у того же Циана или БН есть разделы на сайте "Оставьте заявку на покупку недвиги", но в полудохлом состоянии, видимо на все заявки спамят все АН без разбора. Короче, надо исследовать тему и особенно, клиентов, готовы ли они к такому сценарию "отложенной покупки".

2) УберКодревью (№71) – В целом ОК, но это B2B, длинный цикл сделки, сложно продать, есть проблемы с приватностью данных, если инхаус, наверно ок, надо поспрашивать тех же техлидов и руководство ИТ-компаний будет ли у них на это бюджет. Крутым компаниям проще пинать разрабов, ставить процесс кодревью или нанять доп архитекторов для ревью. А у мелких компаний и фриланса нет денег, т.к. они потому и мелкие и бедные что идут и ищут на подработке фрилансеров.

Это мой второй по любимости проект. Просто меня дико бесит, когда в команде кодят "на отвали", т.е. формально это компилится, работает, но ужасно написано, трудно поддерживается, с кучей ошибок и кода "и так сойдет" – магические константы, хардкод, копипаст, SELECT * там, где нужно тянуть мало данных с бэка на фронт и т.д. Самому ревьюить обычно нет времени, своих задач хватает. Т.е. я думал, что тема огонь. Особенно круто, если ПМ на стендапе будет видеть статус косяков, всплывших на ревью и в прямом эфире пропесочивать разрабов. Или внешний клиент, заказавший разработку индусам из аутсорса будет видеть качество кода на уровне "из 100 косяков исправлено 2" и принимать соотв. решения.

В процессе исследования рынка по проблеме наткнулся на сайт pullrequestDotcom. Оказывается, "Убер для техлидов" (Codereview as a service) уже сделали. В мае 2017 проект был на продуктханте, они были в батче YC S17 и подняли 12.7M $ инвестиций. Ура! Я придумал проект, который прошел бы в YC! Но щас, похоже, сайт дохлый. Хотя CEO еще в феврале 2019 искал разрабов в команду. Не знаю, сдохли ли они или просто сайт тупит при доступе из РФ. Прайсинг у них, конечно, офигеть! 300$/мес за 1 дева и ревью 5тыс строк кода. А за команду из 5 разрабов 3500$ мес. Проще еще одного разраба нанять. Хотя, это цифры для США, там наверно это дешево.

Итого: выхожу к руководству курсов с предложением работать над ЗаявкаНаПокупку (№49) и возможно УберКодревью (№71) – копикэт проекты в целом тоже ОК для других юрисдикций и я точно его придумал сам:)

Дальше будет опрос про эти 2 проекта, какой ОК.

Занятие 2. Гипотезы

● 

Определение гипотезы

● 

Использование методологии SMART

● 

Циклы HADI как способ ускорения развития продукта

● 

Игра «HADI циклы»

Чему научитесь:

● 

Корректно ставить цели. Тестировать гипотезы. Ускорять развитие продукта.

Посетил 2ое занятие курса по продукт менеджменту. Тема: Гипотезы, HADI-циклы, SMART.

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

Тема, на самом деле, огонь. Гипотезы – это самая мякотка работы продакта, исследование реального мира. От занятия я ждал магии, неожиданных и неочевидных открытий и не побоюсь этого слова, гроусхакинга.

Что же было рассказано.

Теория: цели должны быть SMART, т.е. определенными, измеримыми, достижимыми, релевантными (это самое важное – иметь смысл, отвечать на вопросы "зачем я это делаю", "чтобы что") и ограниченными по времени.

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

Придумали гипотезу, поменяли бизнес-процесс (перекрасили кнопку на лендинге) поменялась конверсия, поняли ОК это или нет.

Классическое определение стартапа про временную организацию, организованную для поиска масштабируемой бизнес-модели.

Странный слайд про 4 вида организаций: простая, сложная, неопределенная и хаотическая. Тут я, каюсь, вспылил и спросил, что за хрень происходит и как слайд связан с темой занятия – гипотезами. Еще в презу добавить GTD и 7 навыков высокоэффективных людей и бинго! Отдаем Тони Роббинсу и он соберет с этой презой стадионы. Вырулили в итоге на то, что из 4х типов компаний HADI подходит только типу 3 "неопределенные" (с чего это вдруг?), а к ним относятся стартапы и значит HADI+startups=love

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

Из простого, но полезного – метод приоритезации гипотез ICE (ICE score = Impact * Confidence * Ease – влияние * уверенность * простота). Ставим баллы 1..5 каждому фактору и по общему баллу выбираем, что проверять. Ура! Я интуитивно сделал именно так при выборе идей для курса. Еще это отличный способ разрешения споров вместо голосования, которое входит в клинч при равенстве голосов и непонятках, чей голос весомее.

Самое сложное для меня на занятии были не показанные инструменты по сбору метрик, а необходимость убеждать людей и договариваться в процессе выбора гипотез. Я говорил, что не надо крутить все ручки одновременно, давайте менять элементы сайта по одному и замерять конверсию. Был неправ. Оказалось, можно менять несколько элементов если они находятся на разных этапах процесса со своей конверсией. Нужно быть готовым часто ошибаться, что бьет по самооценке. Для общения нужны софт скилы, а у меня с этим большие напряги.

ОК ставить чуть завышенные цели. OKR методика (Objectives key results), не помню про что это.

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

Постулат 1: При прочих равных лучше оптимизировать начало воронки.

Опровержение: Пусть у нас 100 чел на входе воронки, а воронка состоит из 2х этапов с конверсией С1=20% и С2=20%.

На выходе воронки имеем: Х=100*0.2*0.2=4 чел.

Оптимизируем (в 2 раза поднимаем конверсию) начало воронки:

Х=100*0.4*0.2=8 чел.

Оптимизируем конец воронки:

Х=100*0.2*0.4=8 чел.

Вывод: ничего не изменилось.

В 1м случае юзеры отваливаются позже и проводят больше времени в сервисе и это типа хорошо. Хотя какая нам разница если доход не изменился, а скорее даже упал? Т.к. чем дальше клиент безуспешно прошел по воронке, тем больше ресурсов мы на него истратили. Если юзер ничего не купил, то лучше пусть он отвалится в начале и мы меньше ему примелькаемся и надоедим.

Я, например, очень злюсь на сервис, если долго выбираю товар, ввожу данные доставки, а на странице оплаты получаю сообщение "Товар закончился" или "Оплата налом" (а у меня с собой только карта), т.е. отваливаюсь в конце воронки. В этом случае я понимаю, что сайт делали мудаки, которые сожрали мое время и никогда больше не захожу к ним и другим не советую. Если клиент свалил в самом начале (на главном экране не заинтересовался списком продуктов) это ОК т.к. его заново можно активировать и привести на сайт через рекламу, у него нет отторжения к сервису из-за прошлого неудачного опыта.

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

Постулат 2: Сначала оптимизируй самую узкую часть воронки (см. Теория ограничений Голдратта (TOC)).

Опровержение: Пусть у нас 100 чел на входе воронки, а воронка состоит из 2х этапов с конверсией С1=30% и С2=10%.

На выходе воронки имеем: Х=100*0.3*0.1=3 чел.

Оптимизируем (в 2 раза поднимаем конверсию) узкого места:

Х=100*0.3*0.2=6 чел.

Оптимизируем широкое место:

Х=100*0.6*0.1=6 чел.

Вывод: ничего не изменилось.

С точки зрения математики имеет смысл расшивать узкое место т.к. поднять конверсию в 2 раза с 0.2 до 0.4 получится, а с 0.7 до 1.4 нет (КПД не может быть >100%). Но кто сказал, что первое сделать проще, чем второе? Можно стоит улучшать то, что получается, а не биться в стену?