Итак, допустим, ваш основатель стартапа — человек с большим опытом работы в бизнесе, возможно, даже с дипломом магистра делового администрирования. Он, скорее всего, отлично осведомлен о рисках, связанных с выбором правильной бизнес-модели. Такие люди обычно сосредоточиваются на уникальном ценностном предложении (УТП), ценообразовании, каналах продаж и расходах. И все это, безусловно, реальные риски как неотъемлемая часть оценки жизнеспособности бизнеса. Однако мне часто приходилось, и до сих пор приходится, терпеливо объяснять этим людям, что, хотя это действительно настоящие риски, на данном этапе они преимущественно теоретические. Затем я пытаюсь обратить их внимание на то, что, по моему опыту, является самой большой причиной неудач стартапов и новых продуктов.
Вы, вероятно, думаете, что я говорю о рыночном риске — когда новый продукт призван решить проблему, не слишком волнующую потребителей? Это весьма и весьма реальный риск, который, конечно же, вносит лепту в провалы и неудачи, но я утверждаю, что он, как правило, не самый страшный.
Тут я вынужден сделать две важные оговорки.
Во-первых, нужно сказать, что большинство команд, с которыми я встречаюсь, трудятся вовсе не над решением новых проблем. Обычно они работают над давними проблемами на устоявшихся рынках. Стартап же отличается своим подходом к решению проблемы, чаще всего — и все чаще еще и агрессивнее — тем, что применяет для этого доступные новейшие технологии, причем инновационным способом.
Во-вторых, если рынок действительно новый, то сегодня в нашем распоряжении имеются такие эффективные методики для подтверждения спроса, о каких прежде никто и мечтать не смел. И если вы их не используете, значит, по-прежнему действуете на свой страх и риск. Вот это вопиющая ошибка, потому что методы, о которых идет речь, дешево обходятся с точки зрения как денежных, так и временных затрат, так что оправдания тем, кто их не использует, просто нет.
По моему убеждению, основной риск большинства работ — это риск ценности. В концепции стартапа он проявляется в свете риска, связанного с решением, — с поиском решения, привлекательного для клиентов. Того, что ваши потребители пожелают купить и использовать.
Сделать это обычно довольно сложно, но важно понимать, что для того, чтобы убедить кого-то использовать новый продукт, недостаточно того, чтобы он был сопоставим со старым (это иногда называют паритетом функциональных возможностей) — он должен быть явно и существенно лучше. А это очень высокая планка.
Если же вам приходилось разрабатывать концепцию, вы знаете, что собственно о решении в ней идет очень мало речи. Официальное и логическое обоснование этого состоит в том, что слишком легко влюбиться в свой подход и преждевременно на нем зациклиться. Справедливости ради надо признать, что это реальная и весьма частая проблема команд. Я наблюдаю в них подобное поведение. Но более негативным последствием такого скудного отображения решения в концепции становится то, что это «играет» на природной склонности многих людей сосредоточиваться на тех рисках, с которыми они чувствуют себя комфортнее, а реальное решение оставлять на потом, как «упражнение для разработчиков». Вместо того чтобы перекладывать поиск верного решения на кого-то другого или откладывать, мы должны признать, что исследование продукта — это важнейшая ключевая компетенция любого стартапа.
Если вы способны найти решение, которое очень нравится потребителям, вам будет под силу справиться и с рисками, связанными с монетизацией и масштабированием. А без такого решения вся остальная работа будет проделана напрасно. Так что в чем бы ни выражался ваш ограниченный ресурс — в деньгах или внимании менеджмента, — необходимо убедиться, что вы используете свое время в первую очередь на то, чтобы найти решение-хит. Сначала устраните этот риск, а затем можно сосредоточиться и на других.
Не стоит тратить время на тестирование оптимизации ценообразования, инструменты продаж, маркетинговые программы и программы снижения расходов до тех пор, пока не найден действительно ценный продукт.
Методики планирования
ОБЗОР
Определив задачи в рамках исследования продукта, можно приступать к поиску и выработке решений. Если предстоит очень сложное исследование, обычно полезно иметь тот или иной способ «пристреляться» и спланировать свою деятельность.
В этом разделе я опишу две свои любимые методики для планирования на этапе исследования продукта. Первая простая («Карта истории»), вторая довольно сложная (программа по выявлению новых потребителей), но обе весьма полезные и эффективные.
Мне бы очень не хотелось, чтобы вы отказывались от какой-то методики только потому, что она требует большого труда. Я, например, постоянно говорю продуктовым командам, что если бы они могли выбрать только одну методику из двух вышеназванных, то это должна была бы быть именно вторая, гораздо более сложная. Действительно, она требует много времени и усилий, особенно от продакт-менеджера, но это мой любимый прогнозный индикатор будущего успеха продукта. И я убежден, что большей частью своего карьерного успеха обязан именно этой методике.
Глава 38. «Карта истории»
«Карта истории» (Story mapping) — одна из самых полезных методик из всех, что я знаю. По сути, это методика для формулирования задач и планирования, но она полезна и для выработки новых идей. А еще «Карта истории» используется при создании прототипов и представляет собой отличный инструмент менеджера продукта для коммуникаций со своей командой и заинтересованными сторонами. Кроме того, с помощью этой методики можно управлять собственной профессиональной деятельностью и организовывать ее. И наконец, стоит отметить, что «Карта истории» может пригодиться на протяжении всего процесса исследования продукта и его поставки на рынок. Думаю, вы согласитесь, что это огромные преимущества. Но лучшее в ней — простота.
Нужно сказать, этот метод вырос на почве всеобщего разочарования в типичном безыскусном бэклоге пользовательских историй. В бэклоге отсутствует контекст — это просто список историй в порядке приоритетности. Откуда команде знать, как одна история вписывается в общую картину? И как вообще можно определить приоритеты при таком уровне детализации, притом что отсутствует контекст? Какой набор историй можно считать значимой вехой или релизом? Джеффа Паттона, одного из первых идеологов Agile, все это так раздражало и разочаровывало, что он решил адаптировать некоторые проверенные методы UX-дизайна к концепциям Agile и в итоге предложил такой инструмент, как пользовательские карты истории.
«Карты истории» представляют собой двумерные карты, на которых по горизонтали слева направо в порядке выполнения отображены ключевые пользовательские действия (или, как их еще называют, активность пользователя). Так что, если основных видов пользовательских действий, скажем, десять, они будут перечислены сверху вниз слева направо, как правило, в том порядке, в каком вы будете ими заниматься — или хотя бы в том, в каком бы вы их перечислили, если бы кому-нибудь описывали эту систему.
