Кто о чём, а я опять про качество сервиса. Тема Customer Development подробно и детально описана во множестве источников. Я же хочу взглянуть на тему через призму ITSM и DevOps практик, а также попытаться вынести идеи CusDev за рамки IT и культуры стартапов, применив к другим видам и направлениям бизнеса.
Классическая теория
Википедия говорит нам что развитие клиента (англ. Customer development) (сокращенно – custdev) — это тестирование идеи или прототипа будущего продукта на потенциальных потребителях.
На практике это означает переход от продуктового мышления (мы запилим крутой продукт, он точно выстрелит) к мышлению удовлетворения потребностей (клиенту нужна аналитика, мы её дадим).
Развитие продукта в рамках идеологии (по-другому у меня не получается этот термин назвать) CusDev происходит итерационно, через проверку гипотез. Например:
- Компании финансового сектора хотели бы иметь биржевую аналитику
- Поиск компании финансового сектора
- Обсуждение реальных потребностей конкретной компании в биржевой аналитике
- Применение результатов 3 на продукте
- Повторить с п. 1
То есть цепочка гипотеза – поиск клиента – тестирование гипотезы – применение – новая гипотеза. Очень похоже на общенаучный подход, не находите? Гипотеза – эксперимент – открытие – новая гипотеза.
А что говорит ITIL
В практиках ITIL v3 за развитие клиента, если так можно говорить, отвечает процесс BRM – Business Reletionship Management. Основной целью BRM декларируется установление позитивных отношений с заказчиками. Данный процесс отвечает за идентификацию потребностей существующих и потенциальных заказчиков и обеспечивает (контролирует) внедрение соответствующих услуг для удовлетворения выявленных потребностей.
Очевидна разница между классическим CusDev и BRM связанная с тем что в рамках идеологии CusDev мы сначала выдвигаем гипотезы сами, а потом проверяем их на клиентах, а BRM предполагает что мы сначала спрашиваем клиентов что им надо, а потом пытаемся наилучшим образом удовлетворить их потребности.
Пару слов про DevOps
Как бы я ни любил строгое упорядочивание и процессный подход с его регламентацией, прозрачностью и контролируемостью, но будущее всё же похоже не за стандартизацией, а за гибкостью и способностью к адаптации. В этом плане DevOps как набор практик и, в первую очередь, культура и идеология, соответствует современным вызовам намного лучше. Взять хотя бы важный термин в рамках DevOps – Definition of Done (определение окончания внедрения). DevOps определяет точку окончания внедрения продукта (проекта, услуги) как момент, в который потребитель начинает получать пользу от внедрённого изменения.
В целом, если пытаться найти аналог CusDev в практиках DevOps, то в той или иной степени ниточки CusDev торчат во всех подходах, которые пропагандирует DevOps, а именно:
- Клиент готов платить только за то, что приносит пользу
- Готовность к изменениям в любой момент времени
- Подстраивать продукт под клиента, а не натягивать клиента на продукт
- Максимально оперативная работа с обратной связью от клиентов
Как это должно работать на самом деле
CusDev прекрасный подход сам по себе, т.к. в первую очередь исключает ситуацию при которой очередная кучка техно-гиков закроется в гараже на полгода и будут пилить свой продукт с BigData и нейросетями, а в итоге им будут пользоваться только они сами. Или отдел маркетинга придумает новый продукт, компания вложит средства в разработку и наладку производственной линии, а клиентов не найдётся. Или вдруг окажется что «современный, инновационный и прогрессивный» продукт уже имеет в том или ином виде аналоги на рынке, и конкретно вот эти потребности клиента уже закрыты.
Подводя итог написанному выше, а также исходя из собственного опыта общения с представителями бизнеса и «продажи» своих проектов потенциальным инвесторам, могу сделать следующие выводы:
- Заказчик будет платить только за те продукты\услуги, которые:
- Помогают заработать
- Помогают не потерять (управление рисками)
- Приносят удовольствие (игры, сфера развлечений)
- Позволяют предъявить доминантность (премиум-продукты, участие в рейтингах, приобретение популярности, соцсети и т.д.)
- Покупая продукт, клиент покупает не инструмент, а результат его деятельности (мы не покупаем дрель, мы покупаем дырку в стене)
- Клиент будет удовлетворён тогда и только тогда, когда результат как минимум не ниже уровня ожиданий. Важный вывод: управление ожиданиями (маркетинг и PR) — не менее важная часть работы с клиентом, наряду с изучением потребностей.
- При общении с клиентом следует уделять наибольшее внимание удовлетворению потребностей клиента, а не характеристикам продукта. То, что с помощью дрели можно будет размешивать тесто или ворочать шампуры над мангалом не гарантирует, что вы продадите её профессиональному строителю.
- И, самое важное, любой CusDev, даже в зачаточном состоянии, намного лучше его отсутствия.
Напоследок хочется вспомнить историю стартапа Juicero, который очень громко стартовал, а потом за через после релиза продукта резко провалился. И я думаю, что в данном конкретном случае речь как раз шла про полное отсутствие вовлечения целевых потребителей на этапе тестирования идеи. Идея-то сама по себе может и неплохая, но клиенты её не поняли.