Полюбите проблему, а не ваше решение

Сегодня мы решили предложить вам перевод статьи чудесного Ash Maurya, в которой он подробно рассказывает, почему создал Lean Canvas и почему это так важно — понимать, какие проблемы есть у пользователей вашего продукта.

Меня часто спрашивают о самых распространенных ошибках и заблуждениях предпринимателей. Под номером один в моем списке — влюбленность в свое собственное решение. Я уже как-то раз называл это “Заблуждением новатора”.

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

Препарируйте реальность до самых фундаментальных основ, используйте в рассуждении базовые принципы… и тогда вы получите аргументацию ваших идей.
Элон Маск

Как вы увидите позже, “заблуждение новатора” — очень хитрый тролль! Он поднимает свою уродливую голову как во время генерации идей, так и во время работы над их развитием. Поэтому на каждом вашем шаге старайтесь докопаться до сути проблемы, прежде чем реализовывать ваше решение — это поможет вам понять многие основополагающие вещи.

Большая идея

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

Вся ваша энергия должна быть направлена на понимание сути самой проблемы, всей ее глубины и сложности. А вовсе не на создание вашего решения!

Так как же найти “действительно большую” проблему?

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

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

Эта фокусировка на поиск соответствия “проблемы-решения” — ключевое изменение мышления, которое я заложил в основу Lean Canvas, когда создавал его, трансформируя Business Model Canvas.

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

Отсутствие проблем в вашей бизнес-модели — это проблема.

Lean Canvas — это не улучшенная версия Business Model Canvas, это просто другой шаблон. И хотя я поменял всего 4 блока, даже простое добавление блока с Проблемами помогает изменить ход мысли на этапе создания решения, что может в корне поменять всю бизнес-модель продукта.

Подводный камень: большинство больших идей сосредоточены вокруг решения.

Противоядие: Полюбите проблему, а не ваше решение.

Постоянно разрастающийся бэклог

Давайте рассмотрим уже существующий проект с большим количеством клиентов. Так как клиентов много, то и пожеланий от них тоже много. К кому стоит прислушиваться? Какие фичи стоит делать, а какие нет?

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

Это не работа клиентов — знать, чего они хотят.
Стив Джобс

Наилучший способ приоритезации пожеланий клиентов — понимание ключевой проблемы, которая заставила поместить этот пожелание на первое место. Где они были в этот момент? Что они делали? Зачем?

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

Вот пример запросов от клиентов нашего продукта LEANSTACK:

Фича 1: я бы хотел иметь возможность экспортировать Lean Canvas как PDF.

Фича 2: я бы хотел иметь возможность изменить цвет на Lean Canvas.

Фича 3: я бы хотел иметь возможность менять шрифты на Lean Canvas.

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

Как только вы понимаете задачи, стоящие перед клиентами, становится понятно, как сделать “лучше”.

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

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

Противоядие: Полюбите проблему, а не ваше решение.

Проклятие специализации

По мере роста любого продукта, все начинает идти не так, как планировалось. Для выявления и определения приоритетности проблем мы полагаемся на метрики. Хорошие метрики помогают выявить несостыковки и узкие места в нашей бизнес-модели. Но если попросить команду найти способы улучшить метрики с низкими показателями, то вы рискуете получить огромное количество задач в вашем бэклоге.

Вот еще один пример из жизни нашей команды LEANSTACK.

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

  • наш дизайнер предложил упростить сценарий создания Lean Canvas
  • разработчики предложили добавить новые фичи в сценарий создания
  • а маркетологи предложили сделать рассылку, которой бы клиенты могли пользоваться при создании Lean Canvas

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

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

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

Подводный камень: метрики могут лишь сказать вам, ЧТО вы делаете не так. Но не скажут ПОЧЕМУ. И ваша команда найдет “кучу хорошие идеи”, чтобы исправить непонятно что.

Противоядие: Полюбите проблему, а не ваше решение.

Избегая провала

Никому не нравиться проваливаться, но когда я думаю о желании избежать неудачи, я часто вспоминаю “Автостопом по Галактике”:

Полет — это искусство, а точнее сказать, навык. Весь фокус в том, чтобы научиться швырять свое тело в земную поверхность и при этом промахиваться… Безусловно, вся сложность во втором этапе — в промахивании.
Дуглас Адамс

Мы тратим так много времени, пытаясь избегать ошибок, что не осознаем: Чтобы совершить прорыв, сначала нужно провалиться!

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

Прорывы часто скрыты внутри неудачных экспериментов.

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

  1. Исключите риск большой ошибки за счет проведения маленьких и быстрых дополнительных экспериментов
  2. Исключите слово “провал” из вашего лексикона. Я предпочитаю термин “неожиданные результаты”
  3. Пытайтесь понять, почему вы получили эти “неожиданные результаты”
Разворот бизнес-модели, не основанный на знаниях, это ошибочная стратегия формата “а давай посмотрим, что получится”.

Подводный камень: избегая ошибок, мы только задерживаем настоящий прорыв.

Противоядие: Полюбите проблему, а не ваше решение.

One more thing… ©

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

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