Нет сомнений, что вы слышали о Trello — как-никак, у него уже более 16 миллионов пользователей. Каково это – разработать, запустить и продвигать такой массовый продукт? Как правильно приоритизировать фичи продукта со столь широким спектром вариантов использования? Как проводить монетизацию по принципу ценности для потребителя? Об этом и о многом другом соучредитель сервиса Intercom поговорил с исполнительным директором Trello Майклом Прайором. А мы, компания-локализатор Alconost, все это перевели.
Публикуем перевод без сокращений и изменений, а если у вас совсем нет времени, вот вам пять ключевых выводов:
1. Без грамотной маркетинговой стратегии даже хороший продукт, выпущенный в правильное время, может провалиться.
2. Внедрение новых абстрактных фич в горизонтальный продукт сопряжено с большими затратами, потому что вам придётся научить людей пользоваться ими.
3. Майкл не считает шаблоны правильным способом ознакомления новых пользователей с Trello. Напротив, он поддерживает идею реальных сценариев использования, предложенных сообществом пользователей.
4. Продвижение горизонтального продукта сложно, но существуют определённые сценарии использования с отложенным эффектом, например, использование Trello сотрудниками отдела HR для адаптации новых сотрудников. В таком случае каждый новый сотрудник получает бесплатный урок по использованию продукта.
5. Важно получать деньги за свой продукт, но фиксированные цены не позволяют извлечь максимальную выгоду. Ваши цены должны отражать пользу, которую пользователи извлекают из вашего продукта.
А теперь подробнее и с самого начала.
Дес Трейнор: Майкл, добро пожаловать на шоу. Не могли бы вы рассказать о вашем карьерном пути? Fog Creek: известен всем. Stack Overflow: известен всем. Trello: известен всем. Вы просто выдаёте хит за хитом.
Майкл Прайор: Ну, вы не упомянули все ошибки, которые мы совершили за все эти годы.
Дес: Всё по законам жанра.
Майкл: В далёком 2000 году я и сооснователь компании Джоэл Спольски работали в Нью-Йорке в стартапе под названием Juneau. Это был бесплатный сервис электронной почты, который должен был тогда составить конкуренцию AOL. В то время программист в Нью-Йорке мог работать только в двух местах: в банке или рекламном агентстве. Обычных софтверных компаний в городе просто не было.
Именно поэтому мы решили такую компанию создать. На тот момент ни у кого не было никаких продуктовых идей. Компания должна была быть просто местом, где трудятся разработчики, и у нас на этот счёт было много мнений и мыслей. Джоэл много писал об этом на протяжении многих лет на его сайте joelonsoftware.
За эти годы мы попробовали многие вещи на разных проектах. Конечно, Stack Overflow и Trello появились значительно позже, уже после того, как мы набили немало шишек и научились не повторять своих ошибок. Да, процесс был определённо долгим.
Уроки, извлечённые из запусков предыдущих продуктов
Дес: Из предыдущих продуктов у вас были FogBugz, Copilot и CityDesk. Насколько эти продукты отличались по своему масштабу от Trello и Stack Overflow?
Майкл: Ну, FogBugz достаточно крупный продукт. Мы его продаём; мы до сих пор его развиваем. Он был создан, когда JIRA ещё не было и в помине, и долгое время они шли ноздря в ноздрю. Благодаря определённым шагам, которые за все эти годы предпринял Atlassian в отношении маркетинга и цен, им удалось неплохо подняться, но и мы создали на базе FogBugz хороший стабильный бизнес.
FogBugz до сих пор остаётся одним из ключевых проектов компании.
Другие продукты, такие как CityDesk, просто вышли не в то время. Если вы вспомните 2000 год, то вспомните и то, что быть блогером тогда было непросто. Блогов практически не существовало. Вы могли установить на сервере какие-то скрипты, но для этого нужен был доступ к командной строке, люди просто не знали, что это такое. Мы написали приложение, которое должно было стать удобной CMS для блогеров, так мы планировали решить проблемы пользователей. А потом оказалось, что всё это гораздо удобней и эффективней делать при помощи SaaS.
Ещё один хороший пример — CoPilot. Его мы сделали, чтобы помочь самим себе устанавливать FogBugz на компьютеры клиентов. В определённый момент, где-то в 2006-2007 году, процесс установки стал реально сложным. Мы постоянно говорили про себя: “Эх, хорошо было бы посмотреть, что на том компьютере.” Совместный доступ к экрану тогда был довольно сложной задачей, но мы её решили, создав CoPilot. Он так никогда и не превратился в большой и серьёзный продукт, потому что мы пытались продавать его не тем людям. Мы предлагали его сотрудникам служб поддержки пользователей, а не собственно пользователям. Продукт был хорош, время было выбрано правильно, но позиционирование нас подвело.
Когда мы сделали Stack Overflow, сам сайт с вопросами и ответами, мы сказали: “Слушайте, это реально круто, людям нравится. А может нам продать это кому-то ещё?” Ведь именно этим мы занимались 10 лет до этого. А потом мы поговорили с несколькими инвесторами, и оказалось, что идея была так себе.
Это как если бы Facebook заявил: “У нас получилось в одном университете, поэтому давайте продадим наш софт другим компаниям, пусть все пользуются.” В Stack Overflow важны были именно пользователи, сеть профессионалов, а не программный продукт. И — о чудо! — через пару недель было уже штук 50 клонов.
Дес: Вы упомянули, что с CoPilot вы не попали в рынок. Вы учитывали такие моменты, когда развивали Trello?
Майкл: Конечно. Когда мы делали Trello, мы с самого начала решили делать горизонтальный продукт с максимальным рыночным охватом. Идея была довольно рискованной. Такие инструменты делать реально тяжело, но такую уж цель мы перед собой поставили, и она в корне отличалась от того, чего мы хотели добиться с FogBugz.
Дес: Вы недавно высказались на страницах Hacker News на тему того, чем в вашем понимании является Trello. Мне показалось, что вы не хотели загонять это определение в рамки инструмента для управления проектами. Можете пояснить? У нас тут недавно был Джейсон Фрид, и он примерно то же самое рассказывал про Basecamp.
My answer to "What is Trello? I don't get it." pic.twitter.com/vUj37XwUlx
— Michael Pryor (@michaelpryor) 22 января 2016 г.
Майкл: Многие разработчики продуктов, предназначенных для управления задачами, подходят к процессу с точки зрения того, что нужно просто посмотреть на рабочие процессы, определиться с понятиями, построить вокруг этого некую структуру данных, а затем и веб-приложение, и всё – люди сами заполнят это всё данными. Мы их положим в базу, а потом будем говорить им, что с этими данными делать.
Вспомните Asana, JIRA, даже FogBugz или Salesforce. Они все обладают этой встроенной грамматикой. Например, есть лиды и клиенты. Когда вы впервые начинаете пользоваться такими продуктами, это грамматику нужно понять и принять. В случае с Asana эти понятия более общие, на уровне заданий и вех. Это один из способов решения проблемы, и он подходит людям с очень системным, структурированным .
В случае с Trello мы ориентировались скорее на то, как мы пользуемся Excel. Когда вы открываете новую таблицу, она пуста, верно? Вы начинаете вводить данные, и вам нужно указывать Excel, какие именно данные вы вводите – проценты, суммы в определённой валюте, формулы, отношения между ячейками и так далее. Вы вводите данные и параллельно создаёте модель. В Excel нет семантической модели. Вы её предоставляете сами. Вы говорите: “Это столбец. Вот тут будет диаграмма, она будет связывать эти две переменные.” Это как конструктор Lego.
Мы в работе над Trello ориентировались на те же принципы. Лучшая метафора для Trello – стикеры на доске. Это всем понятно. Trello сразу подкупает наглядностью. Вам не нужно учить новые для вас понятия.
Также важно понимать, что карточки в Trello – это карточки, а не задачи. Microsoft сделала клон Trello под названием Planner, и там у них задачи. Это само по себе не ошибка, но они подходят к процессу с точки зрения “я сейчас задам структуру, а потом попрошу людей заполнить её данными.” Этот подход хорошо работает для очень узкой аудитории, но если вы хотите обеспечить продукту наибольший охват, вам нужно подстраиваться под привычные людям методы работы и давать им возможность использовать ваш продукт для переосмысливания структуры лежащих перед ними задач.
Дес: Когда вы делаете горизонтальный продукт, вы, вероятно, думаете что-то вроде “А может, кто-то будет использовать это для планирования свадьбы или ремонта в доме?” С какими самыми необычными сценариями использования вам доводилось сталкиваться?
Майкл: Да, пример со свадьбой довольно забавный, потому что когда смотришь на продукты конкурентов, то там на эту тему обязательно есть заметки в корпоративном блоге. “Распланируйте свою свадьбу в JIRA.” Всё это лишь попытка сказать, что продукт предназначен для очень широкой аудитории.
Был один случай, очень давно, и он нас довольно сильно удивил. В Бразилии проходили акции протеста, и их участники использовали Trello для внутренней координации.
Или ещё пример из недавнего прошлого: когда случился теракт в Бельгии, люди использовали Trello, чтобы найти выживших и пострадавших. Они собирали информацию по крупицам из разных новостных источников и хранили её в нашем продукте в удобном виде. Всё, что мы могли сказать в тот момент: “Ух ты, а ведь люди реально оценили удобство продукта и пользуются им для координации такого огромного количества людей из разных городов и стран.”
Когда я думаю о Trello, я думаю о нём как о месте, где все мыслят одинаковыми категориями. Поэтому у вас в офисе стоит та белая доска с маркерами. Все собираются, и вы говорите: “Короче, вот текущий статус проекта.” Это не лично мой взгляд на статус проекта. Это не ваш взгляд на статус проекта. Мы все видим одно и то же. Именно это отличает Trello от массы других похожих инструментов. Мы не фокусируемся на конкретных людях, мы фокусируемся на всей команде – ну как если бы вы все потерялись в лесу, то захотели бы иметь при себе карту или GPS-навигатор. Вы бы вместе посмотрели на него, и все бы поняли, где вы находитесь и куда нужно идти. Именно так мы видим то, как пользователи работают с Trello.
Когда продукт предназначен для всех, что же вы разрабатываете?
Дес: Мне нравится то пространство для манёвров, которое открывается перед тобой после того, как ты решаешь не фокусироваться на какой-то конкретной вертикали. С одной стороны, это приводит к взрывному росту, которого вы бы никогда не увидели, если бы назвали Trello системой мониторинга задач и управления проектами для стартапов.
С другой стороны, как вы приоритизируете фичи? Делаете только то, что полезно для всех? Как вы удерживаетесь от соблазна в первую очередь выкатить фичу для большой группы корпоративных пользователей, которые обещают массово оформить платиновую подписку по тройному тарифу, как только этот функционал станет доступен?
Майкл: Отличный вопрос. Мы изначально ожидали, что многие фичи, о которых нас будут просить, будут типично программистскими – потому что именно разработчики являлись ядром нашей аудитории. Это был Stack Overflow, это была компания Fog Creek Software. Люди, знавшие нас, сказали бы: “Ух, здорово. А можете добавить все все эти фишки из Канбана, все эти эти дорожки, как в бассейне, и ещё диаграммы Ганта?” Когда вы делаете массовый продукт, всё это просто не имеет смысла. Мы не занимались разработкой инструмента для Канбана. Мы делали инструмент для разработки ПО с применением гибких методологий.
Мы с самого начала знали, что если появятся запросы пользователей на новый функционал, нам нужно будет сесть и докопаться до сути их проблемы. Что они пытаются решить, запрашивая у нас новую фичу?
Например, пользователь просит добавить в карточки стори поинты, а сверху хочет видеть сумму стори поинтов, чтобы иметь возможность оценить размер бэклога или размер спринта. Тот же самый запрос может прийти и от специалиста по продажам, который сформулирует это иначе: “Да, я использовал Trello для оценки моего пайплайна, и на каждой карточке у меня была проставлена стоимость сделки. Поэтому я хотел, чтобы колонки показывали мне сумму всех сделок.” Суть фичи в том, чтобы добавлять число в карточку, а сверху каждого столбца выводить сумму или среднее значение.
В случае с горизонтальным позиционированием нужно понимать варианты использования продукта. Тут важно уметь внимательно выслушать пользователя и проанализировать возможность реализации такого функционала до того, как вы начнёте разрабатывать новую фичу. Возвращаясь к моим словам насчёт понятий – когда вы добавляете в продукт абстрактные концепции, готовьтесь к тому, что придётся попотеть, потому что вам придётся тщательно разъяснить эти концепции пользователям.
Возьмём пример из Trello. Мы сделали штуку под названием Коллекции, и позволили пользователям объединять в коллекции свои доски. Это абстрактная концепция. Это не какая-то конкретная вещь, эта фича до сих пор даже не полностью реализована, потому что вы пока не можете видеть на самом деле коллекции. Она не представляет какой-то осязаемой, конкретной ценности для пользователя, как остальные фичи в Trello. Но она действительно позволяет группировать доски в некоторые наборы, и при этом людям нужно это осознать это – точнее, мы должны обучить людей этому.
Процесс адаптации для всех пользователей
Дес: Когда пользователь впервые регистрируется и заходит в Trello, то, как и в случае с Excel, он видит только пустой экран и пустые списки. Карточек просто нет. Как вы помогаете им разобраться с системой?
Майкл: Хороший вопрос. Над этим-то мы сейчас и работаем. Тут всё дело в том, кто именно зашёл в систему, правильно? Если я буду при первом старте показывать вам пример планирования свадьбы, а вы только что отпраздновали 20-летие семейной жизни, то пример окажется явно неудачным.
В этой ситуации сложно выбрать нужный пример и использовать его для конкретной категории пользователей. Мы сейчас работаем над адаптационной воронкой, которая позволит определить, какие примеры наиболее релевантны для пользователя, и показать их в самом начале работы с системой.
Нас постоянно спрашивают: “Почему у вас нет готовых шаблонов?” Отчасти потому, что из шаблона довольно сложно почерпнуть действительно полезную информацию. Да, можно назвать списки по-другому, но как только дело доходит до карточек и данных – тут пользователь должен вводить всё сам.
Интересно то, что за досками часто стоят целые истории. В сети полно статей на тему “Я использовал Trello, чтобы сделать X.” Содержание статей обычно сводится к чему-то вроде “Вот как я всё настроил, и вот как это у меня работало.” Мы начали понимать, что это очень важный момент.
Мы также провели немало мероприятий, на которых пользователи рассказывали, как они использовали Trello, чтобы решать задачи в своих компаниях. Людям такой формат очень нравится. Им нравится слушать реальных пользователей, которые делятся реальным опытом использования Trello для решения реальных проблем.
В будущем, я думаю, мы найдём способ рассказывать о таком опыте прямо из продукта. Вместо того, чтобы просто показывать список отобранных досок, мы позволим сообществу рассказать о лучших способах применения Trello.
Дес: Когда вы говорили о разных сценариях применения продукта, предусматривали ли вы разные наборы фич для разных категорий пользователей?
Майкл: Это тоже всегда было проблемой. Если вы предлагаете максимально горизонтальный продукт, как вы будете загонять людей в рамки жёсткой функциональной вертикали?
Допустим, они хотят спланировать свадьбу или создать доску для разработки софта, для отслеживания статусов кандидатов в отделе HR, или календарь для отдела маркетинга. Для таких специальных досок мы решили добавить дополнительный слой, который мы назвали Power-Ups (Улучшения). У нас есть весьма продвинутые фичи в Trello, но они стоят как бы особняком. Их можно задействовать на конкретных досках. Таким образом, если вы впервые попадаете в Trello, вам не нужно вникать в эти дополнительные детали – вы просто изучаете базовые доски, карточки и списки, а уже потом, по мере надобности, можете подключить более продвинутые фичи продукта.
Хорошим примером будет улучшенный календарь. Если вы проставляете в карточках сроки выполнения, их можно увидеть в режиме календаря. Или, например, у нас есть интеграция с Intercom. Т.е. среди этих дополнительных фич есть как интеграции с другими продуктами, так и внутренние улучшения, делающие работу более эффективной.
Буквально недавно мы сделали все эти улучшения совершенно бесплатными. Раньше нужно было платить, а теперь вы можете свободно включать их на каждой из своих досок. Более того, если вы разработчик, вы можете делать свои расширения и делиться ими с 16-миллионной аудиторией Trello. Это просто огромное количество людей. Но если вам нужно активировать больше определённого количества расширений, вы можете купить апгрейд до коммерческой версии продукта.
Продолжение следует...
Автор:
