Цель запуска — создать «минимально привлекательный продукт» (Minimum Loveable Product, MLP). Этот придуманный Кэт Нуун термин отражает стремление подготовить продукт, который будет не только решать проблемы пользователей, но и устанавливать с ними эмоциональную связь.
Нуун пишет:
Что, если мы начнем выпускать «минимально привлекательные продукты»? Продукты, которые объединяют наименьшее возможное количество признаков, которые позволяют любить и принимать себя и которые, несмотря на свою неидеальность, решают проблемы пользователей?
Это не означает, что вы должны разрабатывать монолитный продукт или тратить годы на то, чтобы довести его до совершенства. Если хотите, можете выпускать по продукту хоть каждый день.
Но, как заметил Бен Бёрт, знаменитый звукорежиссер «Звездных войн», описывая съемочный процесс: «Фильмы не выпускают в прокат, они сбегают сами».
Внимание к проблемам целевой аудитории. Обозначенные дедлайны. Требования к качеству. Эти естественные факторы подталкивают вас создавать и улучшать продукт до тех пор, пока тот сам не сбежит от вас. Именно в этом секрет успеха «минимально привлекательных продуктов».
Быть «директором всего»
Запуск продукта означает, что отныне вы несете ответственность за все. Вы «директор всего» продукта. Вы должны знать, как он работает, из каких частей состоит, какие у него есть проблемы, что делать следующим. Ваша ответственность не заканчивается, как только продукт готов к запуску (или уже запущен).
У каждого из нас свой способ контролировать задачи. Доски в Trello. Стикеры Post-It. Wiki-справочники по проектам. Неважно, каким инструментом пользуетесь вы. Постройте ясные отношения со своей командой. Расскажите им, качество какого уровня вы ждете. Убедитесь, что они понимают, что вы от них ждете. И не забудьте убедиться, что каждый занимается тем, чем должен.
Кэт Нуун рассказала мне, что она и сооснователь компании используют общий доступ к спискам Wunderlist, чтобы отслеживать все, что должен сделать перед запуском небольшой стартап (рис. 9.1).
Рис. 9.1. Команда Кэт Нуун использует меняющиеся в режиме реального времени списки Wunderlist, чтобы не забыть даже о мелких, но важных задачах
Весь менеджмент мы ведем здесь. Этот инструмент проще, чем многие другие. Не поймите меня неправильно, у нас есть и документы, описывающие функционал, и понимание того, что нужно сделать, и все остальное. Но мы не хотим тратить на менеджмент слишком много сил.
Мы убедились на собственном опыте, что зачастую чем проще процесс, тем лучше качество. Мы используем хештеги, которые обозначают, к какой задаче относится та или иная запись, к какой папке она принадлежит, кто ответственен за задачу. Wunderlist отлично подходит для этого, так как неважно, сколько человек участвует в проекте, — всегда должен быть кто-то один, кто видит процесс целиком, от начала разработки до запуска.
Кейтлин Фридсон, дизайнер мобильных продуктов компании Care.com, использовала сочетание Jira
[200] и общих документов в Google Docs. За задачами в Jira могут следить все участники процесса (рис. 9.2), и для каждой из них есть ссылка на документ, в котором подробно описывается каждая функция (рис. 9.3).
Рис. 9.2. При запуске продуктов Care.com Кейтлин Фридсон использует комбинацию Jira и Google Docs
Рис. 9.3. Кейтлин Фридсон использует Google Docs, чтобы глубже изучить пользовательские сценарии
Jira нужна мне для создания пользовательских историй (к каждой задаче можно добавить описание из нескольких абзацев), там удобно отслеживать их изменение. Но еще больше мне нравится использовать Jira в сочетании с Google Docs. Так я могу вносить изменения в режиме реального времени: если что-то в задаче устаревает, я оставляю комментарий об этом и затем обновляю описание. А команда разработчиков может отслеживать все изменения и не упускать ничего из виду.
Но как подготовить свою команду к тому, что произойдет потом? Предугадать вопросы журналистов, отшлифовать скрипты продаж, собрать все ресурсы в одном месте? Доработать лендинговую страницу или поправить цены? Внести небольшие изменения в видео о запуске продукта?
Все это зависит от вас; даже если у отделов маркетинга, продаж и разработки есть свое мнение по каждому вопросу, все они будут ждать вашего решения.
«Думаю, у вас должно быть достаточно энергии, чтобы во всем разобраться и исправить самостоятельно, — говорит Грэм Дженкин, продуктовый дизайнер в AngelList, онлайн-платформе, где стартапы могут привлечь инвестиции или нанять людей в команду. — Это требует времени и сил, но, если вы хотите, чтобы качество продукта было на приемлемом уровне, вам придется этим заниматься. Это тяжелый труд. Но не думаю, что есть способ избежать его».
Когда запуск произойдет, а вы хорошенько отметите это событие — кстати, уверяю, вам точно стоит его отпраздновать, — за чем стоит следить? Над чем подумать? Что проанализировать?
Тимони Уэст и Кайл Бреггер — они создавали продукты для Foursquare, Flickr и Elepath — независимо друг от друга рассказали мне секрет успешного запуска: отслеживать обращения в техподдержку.
Неважно, отвечаете вы на письма сами или это делает команда специалистов (или и то и другое), убедитесь, что как минимум проверяются все каналы обратной связи.
Да, это совсем малопривлекательно и отнимает массу времени. Но это самый простой и быстрый способ проникнуть в мысли пользователей после запуска. Поставьте себя на их место: разве не круто пообщаться с человеком, который придумал классную функцию или продукт, который вы используете?
Более того, анализ сообщений в поддержку поможет выявить ошибки в продукте и понять, что озадачивает пользователей.
Тимони Уэст говорит:
Служба поддержки пользователей — самый важный отдел в любой компании. Я видел так много крошечных, узкоспециализированных приложений, которые казались совершенно нежизнеспособными, но при этом процветали, потому что их клиенты были уверены, что в любой ситуации могут положиться на техподдержку. С другой стороны, если я опубликую в Twitter жалобу на компанию, упомянув ее, а мне не ответят, я буду знать: они видели это и предпочли проигнорировать меня.
