Константин Берлинский - Как создать стартап

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 проекта, какой ОК.

●

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

●

Использование методологии 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 каждому фактору и по общему баллу выбираем, что проверять. Ура! Я интуитивно сделал именно так при выборе идей для курса. Еще это отличный способ разрешения споров вместо голосования, которое входит в клинч при равенстве голосов и непонятках, чей голос весомее.