Для того чтобы отпраздновать то, что рассылка Product for Engineers набрала 50000 подписчиков, мы решили поделиться пятьюдесятью советами, в которых собрано всё самое важное, что мы узнали о разработке успешных программных продуктов.

1

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

2

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

3

Создание замечательного продукта требует доверия. Недостаток доверия часто является одним из главнейших препятствий, с которыми сталкивается команда. Это, вполне вероятно, является результатом приёма на работу кого-то, кто находится на недостаточно высоком уровне, или результатом невозможности дать такому человеку адекватный отзыв, который поможет ему стать лучше.

4

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

5

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

6

Руководители должны разделять цели компании. Члены продуктовых команд (инженеры) должны определять то, что нужно создавать для того, чтобы достигать этих целей, и должны устанавливать собственные цели. И те и другие должны проверять уровень реального влияния на компанию того, что создают. Для проверок используются метрики и отзывы пользователей.

7

Продукт произрастает из профиля идеального клиента (ICP, Ideal Customer Profile). Те, для кого вы создаёте продукт — это самый важный фактор, помогающий разобраться с тем, что именно вам создавать. Точный ICP определит не только то, на каких пользователей вы ориентируетесь, но и каждый аспект продукта, и стратегию выхода на рынок.

8

Для составления ICP выдвиньте предположение и проверьте его. Задавайте вопросы при регистрации пользователей, сравнивайте уровни удержания пользователей, идентифицируйте самых активных пользователей, выполняйте опросы для нахождения индекса потребительской лояльности (NPS, Net Promoter Score). По мере того, как вы будете получать больше сведений (и уверенности в том, что делаете) — добавляйте в ICP новые детали.

9

Создайте принципы продукта. Вот наши: «предоставить все инструменты для оценки успеха, быть первыми, быть источником истинных данных о клиенте и продукте». Наличие таких принципов позволяет создать общий язык для обсуждения идей и принятия решений.

10

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

11

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

12

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

13

Иногда источником некоей проблемы является не продукт, а рынок. Например, когда основатель Monzo и партнёр YC Том Бломфилд разрабатывал систему разделения счетов для своих друзей из колледжа, ему посоветовали остановить разработку и попытаться привлечь новых пользователей. Когда он, после четырёх недель холодных звонков, привлёк одного нового пользователя, он понял, что пришло время менять направление и заниматься чем-то другим.

14

Если вы собираетесь менять направление — делайте это с размахом. Стюарт Баттерфилд превратил две компании, занимающиеся видеоиграми, в Flickr и Slack. Сооснователь LinkedIn Рид Хоффман говорит, что основатели стартапов могут менять направление, двигаясь от неудачи к успеху, но только в том случае, если они «безжалостно уничтожат» всё остальное в своём бизнесе. Если же, после перехода к чему-то новому, получилось что-то, похожее на старое — надо идти ещё дальше.

15

Вот что говорит Джейсон Фрайд из 37Signal: «Нельзя проверить идею. Её не существует. Надо что-то создать. Рынок это проверит».

16

Планы полезны, но не нужно жёстко им следовать. Хорошая работа не означает выполнение конкретного плана. Хорошая работа — это постоянное решение самых важных задач. Программистов надо оценивать по тому, что именно они выпускают, а не по тому, как часто они что-то релизят. Оценивать надо эффект от их работы, а не их «приверженность плану».

17

Ждать «ещё одну неделю» перед выпуском продукта — это, почти всегда, неудачная идея. Такой настрой, перенесённый на месяцы, означает сильную потерю динамики развития продукта. Чем скорее что-либо попадёт в руки пользователей — тем скорее вы узнаете о том, представляет ли это для них какую-то ценность, и о том, как сделать это лучше.

18

Снижайте объёмы задач, находящихся в процессе решения. PR должны быть такими, чтобы их можно было бы сделать за день. Начинайте день с выполнения код-ревью по запросам других сотрудников, когда угодно делайте слияния веток репозитория, делайте релизы под feature-флагом, тестируйте продукт в продакшне. Каждый из этих приёмов снижает объём дополнительных сведений, необходимых для выполнения работы.

19

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

20

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

21

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

22

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

23

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

24

У нас, в PostHog, лучший способ общения — это PR. В сравнении с сообщениями, или с системами отслеживания задач, они позволяют мгновенно превратить отзыв в нечто действенное, оказывающее влияние на продукт. Это согласуется с нашим стремлением к действию и помогает организовывать более компактные циклы обратной связи.

25

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

26

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

27

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

28

Большинство людей не обладают навыками Стива Джобса. Нельзя сказать, что они, с самого начала, просто «знают» о том, что им надо создавать, или что они способны «заглянуть за горизонт». Они, вместо всего этого, выпускают новые релизы программ, передают их пользователям, улучшают программы на основе отзывов, а потом всё это повторяют. Чем быстрее они это делают — тем лучше будет выпускаемый ими продукт.

29

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

30

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

31

Для того, чтобы выжать всё возможное из интервью с пользователями, нужно знать о том, кто ваши пользователи (ICP), о том, как они работают с продуктом, о том, что ещё вы хотите создать. Всё это поможет сделать так, чтобы подобные интервью улучшали бы понимание того, что вам делать дальше. Иначе они могут вас отвлечь и запутать.

32

Среди всего того, что вы способны создать, именно те идеи, которые приходят вам через запросы в поддержку, можно назвать самыми «реальными». У конкретного пользователя есть конкретная проблема. Когда вы её решаете — вы улучшаете продукт, а другие изменения могут и не привести к его улучшению.

33

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

34

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

35

Использование собственного продукта (dogfooding) помогает компании быстрее выпускать новые версии, перехватывать проблемы до того, как они достигнут пользователей, глубоко понимать свой продукт и развивать участливое отношение к своим пользователям. Это, правда, не заменяет общения с пользователями, получения отзывов из внешнего мира и наблюдения за реальными метриками использования продукта.

36

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

37

Создатели замечательных продуктов всегда занимаются прототипированием и экспериментами. Это значит, что им должно быть удобно создавать MVP и PoC, выпускать «сырые» версии, получать отзывы и менять направление разработки в случае, когда то, что они сделали, не работает так, как ожидается. Это означает ещё и обладание всеми навыками, необходимыми для того, чтобы пройти путь от нуля до готового проекта, и разбираться во всём — от инфраструктуры до дизайна.

38

Для успешного выполнения A/B-теста нужна хорошая гипотеза, объясняющая то, что тестируют, и то, почему это тестируют. Сюда входит и контекст теста, и проверяемое изменение, и метрика, и ожидаемые результаты.

39

Выполняя эксперименты с какими-либо функциями продуктов, нужно знать о том, что эксперименты могут оказаться неудачными, что приведёт к удалению этих функций. Это означает, что такие функции нужно оформлять так, чтобы их легко можно было удалить (с помощью feature-флага). Кроме того, это означает возможность выпуска «достаточно хороших» версий в противовес отлично поддерживаемым и масштабируемым версиям продукта. После того, как окажется, что функция доказала свою эффективность, её можно улучшить.

40

Эксперименты с продуктом могут быть гораздо «тупее», чем можно себе представить. Например, вместо того, чтобы создавать полноценный функционал — попробуйте проверить востребованность новой функции без её разработки (fake door test). Смысл тут в том, что в продукт добавляют опции или кнопки, которые ничего не делают, и смотрят — будут ли пользователи с ними взаимодействовать.

41

Когда речь идёт об экспериментах с продуктом, неудача — это не конец света. В Google «неудачными» получаются 80-90% экспериментов. Можно подумать, что эксперименты — это пустая трата времени, но в масштабах крупной компании 10% успешных экспериментов могут с лихвой окупить все неудачи. Например, A/B-тест того, как Bing выводит заголовки, привёл к росту дохода на 12% (в то время — это более 100 миллионов долларов).

42

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

43

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

44

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

45

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

46

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

47

Для оценки соответствия продукта рынку проверьте, наблюдается ли экспоненциальный рост вовлечённости пользователей при росте пользовательской базы, и стабилизировался ли уровень удержания пользователей (выше 0%). После этого, проверьте, что уровень удержания ICP-пользователей выше, чем тех, которые не подпадают под профиль идеального клиента, и что ваши платные пользователи входят в состав ICP-пользователей.

48

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

49

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

50

Работайте над продуктом, который вас воодушевляет. Вот что написал об этом в своём руководстве по выяснению соответствия продукта рынку сооснователь PostHog Джеймс:

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

Текст Иана Ванагаса, который рад тому, что в этот раз никто не предложил прочитать 50000 адресов электронной почты.