Почему в заказной разработке нужно применять методологию Customer Development

Принципы и преимущества методики Customer Development для оценки перспектив продукта и формирования правильных ожиданий.

Дата публикации: 10.02.2016  

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

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

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

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

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

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

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

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

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

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

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

    Customer Development и Lean Startup

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

    Cusdev как цикл

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

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

    Комментирование и размещение ссылок запрещено.

    Комментарии закрыты.