Евгений Плохой, Readdle: «Успешный запуск — только один из этапов работы над продуктом»

Евгений Плохой — продакт-менеджер компании-разработчика iOS- и macOS-приложений Readdle, ранее — сооснователь CapableBits. Продукты, которые создавались под его управлением, получили миллионы загрузок в App Store.

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

 

Чем занимается продакт-менеджер?

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

 

 

Либо тактически (деньги, конверсии), либо стратегически (удержание пользователей, сетевые эффекты) — то, что не всегда приносит прибыль здесь и сейчас, но в долгосрочной перспективе хорошо для нас, продукта и пользователей.

Мы работаем по OKR (objective, keys and results), и KPI команды отталкивается от текущих целей. В один период приоритетом может быть выручка, в другой — рост загрузок, в третий — удержание пользователей.

Все зависит от того, в какой области мы видим потенциальный кратный рост или возможность поддержать продукт на фоне изменений рынка.

 

Как фидбек влияет на улучшения?

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

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

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

Они ежедневно обрабатывают тысячи запросов, из которых передают нам два-четыре самых интересных, по их мнению.

Около 80% этих задач конвертируется в беклог, а некоторые попадают в следующий спринт.

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

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

 

 

 

 

Из чего состоит успешный продукт?

Все зависит от бизнес-модели продукта, стадии, на которой он находится, и еще миллиона разных составляющих. Для каждого конкретного продукта в каждый момент времени их может быть 3 или 33...

Это могут быть — пользователи, ценность и доход или команда, рынок и соответствие этому рынку.

 

 

У нас суперпрофессиональная команда, глубокая экспертиза и внутренняя система, с которой получается очень эффективно работать. Этот набор позволяет создавать сильные продукты.

 

Как в Readdle работают с ошибками?

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

Из относительно недавних промахов: мы разработали удобное решение по переносу файлов между мобильным устройством и десктопом — Docstransfer.

Логин был через QR-код — нужно просто зайти на docstransfer.com, навести камеру мобильного и считать код.

Это круто сработало для iPhone, но не для iPad, который довольно громоздкий и часто находится в чехле, закрывающем камеру. Мы сфокусировались на iPhone и не учли физические особенности iPad.

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

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

Часто проблемы возникают, когда Google или Microsoft вдруг что-то меняют в своих API — тогда нам нужно срочно «докручивать» что-то у себя.

 

 

Каждое обновление проверяет команда QA-инженеров, которые смотрят не только на технические проблемы, но и на пользовательский опыт.

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

И, конечно, следим за отзывами пользователей после обновления.

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

 

Какие у Readdle отношения с Apple?

Первое приложение Readdle — ReaddleDocs — появилось на iPhone еще до появления официального App Store. Когда Стив Джобс анонсировал App Store, приложение Readdle было в нем с первого дня его запуска, среди первых 500 приложений.

Но это не значит, что у нас какой-то особенный статус. У нас с Apple точно такие же отношения, как и у любого другого разработчика, который делает качественные и успешные продукты.

 

Как Readdle готовит релизы?

Мы никогда не выпускаем релиз, просто чтобы выпустить — в каждой версии очень много работы. Команда почтового клиента Spark практически каждый квартал показывает новые возможности, так как продукт активно развивается.

Documents и PDF Expert — более устоявшиеся продукты, и разработка новой функции может занимать много времени.

Из последнего классного и интересного — WiFi Transfer, отличный способ передачи и обмена информацией между телефоном и десктопом. За первые несколько месяцев пользователи передали уже миллионы файлов.

Условно, я мог бы выделить два основных подхода к релизам.

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

Второй: регулярное улучшение продукта на основании новых находок или отзывов пользователей.

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

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

 

Важны ли громкие релизы?

Я скептически отношусь к громким запускам. Раньше подходил к релизу как к некой финальной точке и концентрировался на ней. Но запуск всего продукта, его функции или версии — только один из этапов работы над ним.

 

 

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

Важный, но точно не финальный.

Вместе с одной командой мы делали текстовый квест Look Right с настоящими актерами и классной историей. Запуск был потрясающий — деньги на разработку мы вернули даже с небольшой прибылью, «покричали» везде, где было можно — и в прессе, и на Product Hunt.

Но уже через две недели загрузки пошли на спад, а издания, готовые написать о нас материал, закончились.

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

Удачный запуск? Безусловно. Но мы были сфокусированы на нем и забыли сделать продукт, который был бы успешен в течении длительного времени. Он до сих пор в App Store, у него отличные рейтинги, но очень мало трафика.

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

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

 

 

Мне нравятся истории Airbnb, Uber и активно развивающихся компании проката электробайков Bird и Lime. В свое время эти компании создали новые рынки. Интересно наблюдать, как они приходят к потребности рынка, развиваются и позиционируют продукты, справляются со сложностями.

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

 

Есть ли у «бесполезного» продукта шанс выжить?

Устранение «боли» — не обязательное условие для существования продукта. Он может не работать с болью, а просто приносить удовольствие или играть на эмоциях.

Многие суперуспешные компании, такие как Facebook, Instagram и Snapchat, построены на этом.

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

На этой ошибке зарабатывают многие iOS-продукты. Но Apple уже начал активно работать над этой проблемой и скоро устранит эту возможность.

 

Как реагировать на «нет» от потребителя?

«Нет» можно услышать, когда делаешь продукт для одного человека. Когда работаешь с миллионами людей, всегда найдутся те, кто будет пользоваться любой функцией, даже не самой удачной.

Даже если ты не знал о какой-то ценности внутри продукта, пользователи ее найдут и начнут использовать продукт так, как создатели и представить не могли.

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

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

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

 

Какие факапы может допустить продакт-менеджер?

 

 

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

Почти каждое свое выступление основатели успешных компаний начинают примерно так: «Сегодня я расскажу вам, как работать с клиентами/увеличивать продажи/строить/выводить продукт на рынок. Когда мы строили свою суперуспешную компанию Х, то делали все не так. Но теперь мы знаем, как правильно».

После пятого подобного вступления у меня появилась теория, что их успех во многом связан с тем, что они «делали все не так» в начале и учились на этом.

Каждое неправильное действие, каждое неудачное решение дает нам новую информацию, которая — если повезет — аккумулируется в успех.

 

Что происходит на рынке продакт-специалистов?

Есть крутые профессионалы, есть те, кто учится, есть и плохие специалисты. 

 

 

Проблем добавляет обилие некачественного контента о продакт-менеджменте и псевдоэкспертов, которых хватает в любой развивающейся отрасли.

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

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

Есть фреймворки, присвоившие себе звание «самого лучшего подхода», который только может выбрать продакт-менеджер — Customer Development, Product Market Fit, AARRR, Engagement Loops, data driven approach и другие.

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

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

 

Какую задачу выполняет ваш Telegram-канал «Плохой продукт»?

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

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

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

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

 

Что стоит смотреть и читать продакт-менеджеру?

Я бы рекомендовал начать с канала Y Combinator — смотрите его и переходите на каналы в подсказках. Я отсматриваю много профессионального контента на YouTube, в основном на скорости 2Х, чтобы сэкономить время.

Очень много качественного текстового контента в блогах и рассылках. Очень люблю блог Бена Томпсона — раз в неделю он бесплатно публикует большую статью с разбором стратегий, подписка на ежедневные обновления стоит $10.

Еще я читаю блоги Марко Армана, Сэма Альтмана, Бенедикта Эванса, Эндрю Чена и многих других.

Чтобы оставаться в курсе событий, подписался на рассылку от Launch Ticker — два раза в день в формате твита приходит рассылка с новостями IT-индустрии.

Интересен не столько сам факт, что кто-то «поднял» раунд $20-100 млн, сколько информация о том, что за компания, на каком рынке она работает, по какой бизнес модели.

Так проще отслеживать тренды, видеть развивающиеся рынки и находить много инсайтов. Еще есть А16Z Andreessen Horowitz — сайт успешного инвестфонда с интересным контентом.

 

Существует ли идеальный продукт?

Джефф Безос в интервью предложил метафору «непересекающиеся прямые Безоса»: одна прямая — то, насколько динамично развивается продукт, а вторая — то, как растут требования пользователя к продукту.

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