Книга Как создать продукт, который полюбят - Скотт Херф

Где можно распознать возможность?

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

Нужно определить основную цель и дать пользователям то, что у вас есть сейчас. Почему бы не дать им больше? Если больше пользователей решат свою проблему, у продукта будет больше установок, мы больше заработаем, не правда ли? И какое решение этой проблемы предлагает команда в целом? Ни менеджер продукта, ни маркетологи — а вся команда? Определение проблемы — это задача всей компании, и к концу дня менеджер продукта, генеральный менеджер и СЕО должны сказать: «Думаю, это именно та важная проблема, которую мы собираемся решить».

Теперь время поработать продуктовой команде. «Каким может быть наилучшее решение создавшейся проблемы?» И все вместе они должны придумать решение. Когда я говорю об управлении продуктом, то часто использую одну фразу (у меня есть даже соответствующая запись в блоге)[201]. Это фраза — «Менеджер продукта должен помочь своей команде разработать лучший продукт для пользователей». Помочь команде, а не заставить ее.

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

Как вам удается сфокусировать внимание команды на нужных вещах?

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

Итак, что я делаю: мы знаем, что есть проблема, но мы не знаем точно, какова она и как ее решить. Я собираю команду на общий мозговой штурм с вопросом «Что нам делать?». На чем сконцентрироваться в первую очередь, чтобы увеличить активность пользователей? Как привлечь новых пользователей в нашу систему? У меня есть идеи, основанные на моем опыте, у других людей есть идеи, основанные на их мыслях. Мы всё обсуждаем и потом голосуем. Да, я доверяю команде проголосовать. И если команда проголосовала за какой-то вариант как наиболее подходящий для решения проблемы, я доверяю ее решению. В любом случае, этим людям придется воплощать его в жизнь. И мы будем делать это вместе.

Заметьте, не все могут быть согласны, но если каждый видит прозрачную процедуру голосования и обсуждения и если вы открыты и честны, то всегда можете сказать: «Окей, мы выбрали этот вариант все вместе. Мы же команда? Так давайте его придерживаться». Ваша работа — помогать команде делать именно те вещи, которые вы все вместе решили делать, и это уже своего рода соглашение. Так что я действительно думаю, что обсуждение и голосование очень важны.

Как вы управляете процессом создания продукта? Как определяете, что все идет по плану?

На самом деле мне кажется, что хорошие дизайнеры и хорошие инженеры должны чувствовать процесс, как это делаю я. Моя роль — быть лидером. В первую очередь, я фокусируюсь на истории. У продукта всегда должно быть название — даже у самой маленькой из разрабатываемых нами вещей всегда есть название. Каким бы оно ни было — «Электронное страховое письмо», «Поздравительное письмо» или «Новый пользовательский сценарий — 3». Иногда названия могут быть дурацкими, иногда — действительно цепляющими, вроде использованного нами в Twitter «Кого читать?» (в оригинале WTF — Who To Follow). Кстати, эта идея была предложена одним из наших пользователей. Мы всегда стараемся придумать название и вслед за ним — историю.

Иногда история записывается. На самом деле мне следует записывать истории чаще, но обычно это происходит спонтанно, вроде: «Эй! Это история того, зачем мы разрабатываем этот функционал, что мы ожидаем изменить в поведении пользователей и как это повлияет на них и на весь бизнес». И я рассказываю эту историю, чтобы понять, что разрабатываемый продукт ей соответствует. Иногда он ей не соответствует. Но стараться нужно всегда. Многие недооценивают важность правильной истории.

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

Что заставляет вас отступить и задуматься, не совершили ли вы ошибки?

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

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

Все дело в истории. Если вы придумали хорошую историю и все люди в компании понимают, почему она важна и так далее, тогда и выход на рынок будет легкой частью этой отличной истории. Если же история не проработана — тогда у вас проблемы[202].