Почему в заказной разработке нужно применять методологию Customer Development10.02.2016 12:18

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

В то же время стартапы успешно используют методики, позволяющие ясно видеть перспективы продукта и формировать правильные ожидания. Одна из таких методик называется Customer Development. И сейчас мы рассмотрим, как можно ее применять в заказной разработке.

За чем приходят заказчики?

Заказчик приходит за решением своей проблемы. Сделать сайт — не проблема, как и рекламная кампания. Проблемой может быть потеря охвата рынка, потому что конкуренты вовсю выходят в онлайн и развивают базу лояльных клиентов.

Проблема нашей отрасли в том, что студии/агентства не нарастили консалтинговую экспертизу на таком уровне, чтобы клиент обращался к ним с проблемой. Поэтому заказчик вынужден искать решение проблемы самостоятельно, а к разработчикам приходить уже с конкретными требованиями. Это влечет за собой снятие ответственности с разработчика (плюс для разработчиков) и завышенные ожидания заказчика (минус для всех).

Типы проблем заказчиков

С какими ситуациями приходится сталкиваться разработчикам:

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

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

3. Успешный продукт. Здесь все чувствуют твердую почву и хотят зарабатывать больше. Самый опасный тип проблемы, потому что успешность продукта часто бывает индикатором достигнутого потолка, а не перспективной ниши. И анализировать такую ситуацию нужно очень осторожно.

И тут кроется очень приятная особенность описываемой методологии. Customer Development позволяет рассматривать любой продукт в контексте рынка, безотносительно причин его текущего положения. То есть мы как бы говорим — не важно, что было до текущего момента, посмотрим, что нас ждет дальше.

Customer Development и Lean Startup

Тут важно оговориться, что мы разграничиваем понятия кастдев и бережливый стартап. Несмотря на то, что lean startup родился из методологии Customer Development и является ее важной смысловой частью, кастдев подразумевает именно развитие клиентской базы: в количественном выражении, в структурном, в интенсивности взаимодействия.

Lean же учит нас менеджерить этот процесс и сокращать издержки там, где они не оказывают положительного влияния на целевой показатель.

То есть ответы на вопросы «что делать и зачем» мы ищем, применяя customer development, а «как делать» — lean.

Этапы цикла: видение

Вообще в оригинале и многих переложениях вы увидите такие этапы как: Discovery, Validation и Development. Мне лично кажется это трудно воспринимаемым, поэтому адаптации ради я использую свою интерпретацию подхода, которая логично укладывается в формат заказной разработки и забирает из оригинала самую мякотку.

Видение — это первоначальный взгляд на концепцию продукта, ее описание и обоснование. Видение может составляться до обращения к разработчикам, но лучше, чтобы разработчики составили этот документ за 1–2 встречи с заказчиком. Таким образом, у команды формируется идея продукта.

Составляя видение необходимо ответить на вопросы:

1. Что будет делать наш продукт?

2. Кто аудитория продукта, какие у них проблемы и как мы будем дистрибутировать продукт?

3. Как продукт будет зарабатывать?

4. Кто конкуренты нашего продукта?

5. Какие преимущества и недостатки нашего продукта в сравнении с конкурентами?

6. Экономика продукта и условия ее сходимости.

Думаю, многие узнали здесь свой бриф на разработку. Так и есть, видение может как дополнять бриф, так и заменять его полностью.

Мы рекомендуем составлять видение продукта из следующих документов:

1. Составляющие бизнеса компании — канва бизнес-модели Остервальдера

2. Сегментация аудитории продукта

3. Сравнительный анализ конкурентов

4. Экономика продукта по методу Красинского

Составляя видение, обратите внимание на слабые стороны вашего продукта. Например, компания «N» продает стройматериалы и продвигает продукт, ориентированный на строительные бригады, которые используют его для формирования сметы на проект. Это узкий рынок, в котором легко достичь потолка и трудно заслужить лояльность отдельно взятой бригады. И тут мы применяем старый предпринимательский принцип: наши слабости — это наши возможности роста. Зададим себе вопрос: кто еще может пользоваться услугами компании «N» и почему до сих пор не пользуется? Непосредственные заказчики строительных работ, которые не разбираются в тематике и испытывают трудности с формированием запроса.

Возможности роста становятся гипотезами. Примем за возможность переориентацию продукта на неопытную аудиторию с целью помочь преодолеть порог входа.

Ваша гипотеза должна отвечать на вопрос по следующей схеме: кому будет полезно, что, по какой причине. Запомните эту формулу, она нам еще пригодится.

В нашем примере: не разбирающимся в строительной тематике людям будет полезен инструмент формирования сметы/проекта, потому что они испытывают потребность в строительных работах, но боятся масштаба работ и не знают сколько это может стоить.

Не имеет значения, начинаете ли вы разработку нового продукта или развиваете существующий — вы должны составить видение продукта в контексте рынка, посмотреть на него в целом. Не изучайте статьи »50 идей для а/б тестов» и не ломайте голову в какой цвет покрасить кнопку. Смотрите на продукт и его пользователей со стороны и вы найдете идеи для поиска «голубого океана» или «фиолетовой коровы». В случае заказной разработки потребуется время клиента и ресурсы на изучение данных веб-метрик, составление воронки, изучение конкурентов.

Составленная картина продукта со сформулированными гипотезами роста и ожидаемыми ключевыми показателями оформляется в виде документа и принимается как план действий.

Этапы цикла: проверка гипотез

Полученные на первом этапе гипотезы необходимо проверить.

Действовать мы будем в рамках lean startup и проверять идеи до разработки.

Для проверки каждой гипотезы мы ищем респондентов из целевой аудитории этой гипотезы (вопрос «кто») и строим с ними диалог по плану:

1. Как вы справляетесь с этой проблемой? (вопрос «по какой причине»)

2. Как они видят решение этой проблемы?

3. Как бы вы использовали этот функционал? (вопрос «что»)

4. Станет ли это решением проблемы?

Сколько респондентов опрашивать — не менее 10.

После проведения опроса вы можете подтвердить ваши гипотезы или скорректировать их.

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

Этапы цикла: MVP и оценка спроса

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

Фактически этот этап включает стандартный цикл разработки: прототипирование, дизайн, верстка, программирование, запуск. И его отличие лишь в требованиях к функционалу. Прорабатывая конкретные гипотезы роста, мы избавляем себя и заказчика от необходимости нагромождать функционал или копировать с конкурентов.

Для формирования требований к MVP мы используем матрицу потребностей, которую можно модифицировать как вам угодно, — располагать по вертикали проблемы клиентов, например. Главное, что мы сохраняем суть подхода — ранжируем важные факторы по вертикали и точки взаимодействия по горизонтали. В левом верхнем углу собирается наше MVP.

Каков необходимый минимум при создании минимально необходимого продукта?

Строгих правил нет. Здесь полагайтесь на принципы Lean Startup и бизнес-процессы заказчика. Не забывайте, что функционал должен быть расширяемым.

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

Cusdev как цикл

Можно было подумать, что на последнем этапе все заканчивается, однако это только одна итерация цикла Customer Development. После оценки спроса необходимо вернуться к первому этапу и скорректировать видение, развить его на основании данных, которые мы получили в ходе работы. Процесс формирования видения продукта непрерывен и это то, за что ценят продакт-менеджеров — они являются носителями видения и генерируют идеи, направленные на развитие продукта.

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

Полный текст статьи читайте на CMS Magazine