Прочитал книгу Роба Фицпатрика «Спроси маму» («The mom test» Rob Fitzpatrick). На русском, похоже она нигде ещё не продается. На английском можно купить тут: momtestbook.com

Честно говоря, многого от книги не ждал. Ну, в самом деле, что можно сказать нового про CustDev, проблемные интервью и прочие lean штуковины? Говорим с клиентами, делаем то, что они хотят, вроде всё понятно. Однако, книга приятно удивила. Тема вспахана настолько глубоко, что после прочтения и некоторой практики можно самому читать тренинги и выступать в качестве спикера на конференциях типа LEAN Startup Russia. Кстати, именно на этой конференции я и получил эту книгу бесплатно, за что большой респект организаторам — ФРИИ? и LPGenerator?, а также Julia Ploskonosova? и Ilya Korolev?. PS: обзор конференции я написал тут.

Но сначала некоторое лирическое отступление.
CustDev решает важную проблему, связанную с тем, что программисты любят программировать и не любят говорить с пользователями продукта. Обычно, для решения этой проблемы в проектной команде присутствуют люди, специально заточенные под выяснение потребностей клиентов — системные аналитики. Они общаются с клиентами, пишут ТЗ (техническое задание), по ТЗ архитектор делает ТП (технический проект) — документ с декомпозицией модулей, описанием интерфейсов между системами, архитектурой решения. Менеджер проекта режет функциональность по итерациям, выставлял приоритеты, формирует команду и разработка начинается. Проблемы в этом случае возникали сразу же:
а) требования в ТЗ устаревали, а клиент запросто фонтанировал новыми идеями, менял ранее выставленные приоритеты.
б) решение допиливали по ходу, при внедрении, программисты принимали собственные решения (например, формат полей в БД и при валидации), поэтому требования нужно было синхронизировать (код-ТЗ-ТП) в обе стороны.
в) трудно соблюсти баланс интересов — для хорошего проектировании (в т.ч. по бюджету в проектах fixed price), планирования загрузки команды нужно большое детальное ТЗ в начале работы, а для быстрого багфикса, изменения приоритетов задач ТЗ не нужно, а нужна работа в Agile стиле.

Причины проблемы, почему разработчики не любят общаться с клиентами ведут к мифу о «гаражном программировании», который возник в году примерно 1975 и живуч до сих пор. Он заключается в идее о том, что любые 1-3 человека запершись от внешнего мира в гараже за 1-12 мес. создадут суперштуковину, которая завоюет весь мир и в один момент поместит их в первую десятку списка Форбс. Всё совершенно не так. В основе любой хорошей идеи, завоевавшей рынок, в первую очередь, стоит поиск платежеспособного клиента, который купит продукт и быстро и эффективно решит свою важную проблему. Высший пилотаж — клиент даст вам денег за несуществующий продукт до момента, как он будет сделан (см. краудфандинговые площадки Kickstarter?, Indiegogo? и прочий МММ?)
До практики CustDev таким большим прорывом в разработке ПО была Agile (XP, Scrum, Continious integration, всё, что шло в комплекте). Она решала предыдущую большую боль девелоперов — устаревание ТЗ, изменение приоритетов функций, задержки в поставке работоспособного продукта (или его части) клиенту.
До Agile крупным инсайтом стало TDD — оно решало проблему большого количества багов и нестыковки модулей между собой.
До TDD большим прорывом было активное развитие SourceControl систем — для решения проблем групповой разработки и бэкапа кода.
До этого появился UML, RUP, DesignPatterns — для проектирования ПО и избежания создания собственных велосипедов.
До этого стали широко использовать гайдлайны кода, реверс инжиниринг — для того, чтобы иметь возможность поддерживать ранее написанные системы

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

На этом, лирику закончим. Итак, инсайты от книги были и довольно существенные.

1) Важно понять, как работает рынок без вас в реальности, а не пытаться навязать рынку своё видение реальности
2) Важно прояснить все виды неопределенности в продукте — кол-во клиентов, их конверсию, откуда они узнают о товаре, как часто они его используют. По каждому вопросу нужно генерировать и проверять варианты решений — продуктовые гипотезы. Хороший темп — проверить 50+ гипотез за 3 месяца, т.е. постоянно все анализировать и общаться с клиентом.
3) Узнать клиентские сегменты важно, чтобы меньше тратить денег на рекламу, т.е. заточить рекламу на определенную группу людей, а не сжигать прорву денег, рекламируясь на ТВ и т.о. бомбя по площадям на широкий охват.
4) Больше слушать, меньше говорить с клиентом. Спрашивать о прошлом, а не о будущем. Говорить о их жизни, а не о своей идее. На прошлой работе шеф при разговоре с клиентом говорил волшебную фразу «ОК, услышал тебя» — это радикально повышает продуктивность разговора, если слушать, слышать и делать выводы на основе мнения клиента. PS: фраза «Я вас понял» — плохая, т.к. подразумевает, что ранее вы ничего не понимали.
5) Очень неприятный для многих инсайт. Спрашивать у клиента, каковы последствия ситуации, при возникновении проблемы (подразумевая, при отсутствии вашего решения). Каждый предприниматель мечтает в этот момент услышать, что без его решения у клиента закроются все чакры, он потеряет 1млн. $ и вообще, умрет в страшных мучениях :-). Как это не печально звучит но в 99.99% случаях мир обойдется без вашей гениальной идеи (сайта, мобаппа), также многое зависит от пофигизма ЦА. Живут же годами люди в Северной Корее без Аппстора и в ус не дуют. Осознание того, что идея не очень то и болезненна, резко снижает мотивацию команды, но лучше услышать это как можно раньше. Отдельная проблема — стокгольмский синдром предпринимателя, когда не взлетевшая идея годами пожирает его время и ресурсы — проект не развивается, но и не закрыт. Оффтоп — когда на питче нескольких своих идей (то, что их было несколько сразу, уже было проблемой), один ментор как дятел 10 раз подряд повторил фразу «Это не проблема!», с трудом удержался, чтобы не стукнуть ноутом ему по голове. Alisher Hasanov?, привет!
6) Надо любить плохие новости (продукт, реализованная функция не нужна), т.к. поиск правды, важнее комплиментов и это сэкономит силы в будущем, если не будешь делать ненужное.
7) Типичная ошибка в беседе с клиентом — не видя заинтересованности в продукте, начать давить и питчить (объяснять), какая классная у вас идея (врубать продавца). Моя любимая ошибка!
8) Надо спрашивать только тот вопрос, ответ на который не очевиден (его нельзя, например, нагуглить). Спрашивать «Заплатите ли вы Х денег, если это принесет вам 3*Х денег?» — плохой вопрос, т.к. он очевиден. Надо спрашивать «Сколько вы сейчас платите за решение?»
9) Не решать даже очень больную и массовую проблему, если у ЦА нет денег на решение.
10) Для каждой беседы иметь план — 3 самых важных вопроса для прояснения
11) Встреча считается удачной, если все понятно, что делать дальше:
а) Сделан план — взяты обязательства по времени следующей встречи,
б) По репутации — обещают представить руководству / другим экспертам,
в) По деньгам — сделали предзаказ или подписали договор о намерениях. Т.е. каждая новая встреча с одним и тем же клиентом должна быть продвижением по воронке продаж — от определения проблемы до покупки решения.
12) Высший пилотаж — провести проблемное интервью не назначая встречу, а во время простой беседы со случайным знакомым
13) Хорошие способы, сделать холодные звонки менее холодными — т.е. чтобы не ты искал клиентов / партнеров, а они тебя — вести блог, знакомства через третьих лиц, выступать на конференциях, спрашивать контакты у отраслевых экспертов, менторов, инвесторов
14) Отличный шаблон письма — запроса на поговорить — ВФСЗП:
а) Видение (мы пытаемся решить проблемы в такой-то области),
б) Формулировка (мы хотим понять как работает то-то),
в) Слабость (но мы в этом ничего не понимаем),
д) Значимость (зато вы в этом понимаете),
е) Просьба (давайте встретимся тогда-то)
15) Продолжать встречаться до тех пор, пока слышим что-то новое, иногда достаточно 3-5 встреч для проверки гипотезы. Оффтоп — слышал, что для LinguaLeo? провели 500+ встреч / 6+ мес., хотя может это общее число встреч для проверки всех гипотез, а не только для проверки исходной проблемы.
16) Сегментирование клиентов важно также потому, что не нужно будет реализовывать кучу функций, пытаясь угодить всем (а значит, никому). Чисто математически, средний балл в аппсторе у приложения будет выше, если у вас есть 100 отличных отзывов, чем 1000 как положительных, так и отрицательных. Хотя кажется, что чем больше клиентов (в том числе разных), тем больше денег, но это не так.
17) Сегменты клиентов это не только демография (наши клиенты женщины 30+ с детьми), но и другие характеристики — критики/обожатели продукта, бедные/богатые, активные комментаторы, оставляющие отклики в ФБ, сторах и молчуны, делить их по мотивам использования решения. Лучше работать в 1-м сегменте, а не распыляться. Самый лучший сегмент — богатые обожатели, до которых легко достучаться и которые дадут большие возможности развить с ними бизнес (например, активно покупают доп. услуги). Сегменты формировать по принципу «Кто-Где» (Кто эти люди / Где их можно найти).

Вот, как то так, знаю, что букв много – респект тем, кто осилил.