Product manager – позиция неоднозначная. На постсоветском пространстве еще не сложилось полноценной культуры управления продуктом, хотя продуктовых компаний уже в общем-то немало. «Продактами» становятся бывшие бизнес-аналитики, проектные менеджеры, маркетологи и другие специалисты, каждый из которых по-своему подходит к своим новым задачам. Я хотел бы поделиться несколькими тезисами о работе с новыми фичами продукта, которые кажутся важными с моей колокольни.
Это тоже в своем роде управление продуктами, но речь пойдет о другом.
Едва ли хоть что-то из сказанного ниже может являться универсальным советом. Я в основном занимаюсь сервисами, с которыми практически не сталкивается пользователь, что накладывает своеобразный отпечаток на работу и те правила, которыми я руководствуюсь.
Если продукт, над которым вы работаете, не обладает сверхузкой спецификой, едва ли не каждый встречный сочтет своим долгом прислать вам feature request. Нужно уметь фильтровать их, особенно если ресурсы ограничены. Если дизайнер со слезами на глазах будет убеждать, что вашей системе обработки данных придет конец, если не привести интерфейс в соответствие с модными трендами, это не значит, что нужно бросать все и делать так, чтобы система напоминала последние изыскания сэра Джонатана Айва. Или наоборот: когда программист отстаивает точку зрения, что пользователю подсказки не нужны, т.к. «все и так очевидно», это не повод отказываться от тултипов. Вообще, многие не очень хорошие идеи вызваны профессиональной деформацией: UX готов заботиться о пользователе в ущерб бизнесу, разработчики предпочитают любому интерфейсу теплую ламповую командную строку, некоторых бизнес-ребят вообще ничего не волнует, кроме сроков и денег и т.п. На это все следует делать поправки.
Например, я фильтрую свежепридуманные фичи так:
Каждая новая фича должна работать или на цели (без этой функциональности сложно/невозможно добиться общих целей продукта), или на KPI (эта функциональность позволит улучшить существующие показатели). Это могут быть как связанные, так и ортогональные сущности.
Пример фичи, ориентированной на цели:
Если фича не соответствует ни тому, ни другому, с ней что-то не так. Задайте себе и тому, кто предложил эту фичу, простой вопрос «Зачем?». Довольно часто feature request приходит, «потому что это модно!». Задавая вопрос «зачем?», вы сможете отделить полезные идеи от малотолковых веяний моды. Не нужно бояться задавать тот же вопрос высокопоставленным боссам, которые могут на ходу бросать не в полной мере обдуманные мысли в расчете на то, что вы возьмете под козырек и немедленно приступите к исполнению.
Отдельно хочу заметить, что довод «Так уже сделали конкуренты!» не является достаточным, чтобы сломя голову браться за разработку. Довольно забавно смотреть, как тот или иной проект слепо копирует что-то вплоть до достаточно мелких деталей, не зная, что такая реализация была вызвана, например, локальными ограничениями используемого фреймворка.
Планируя фичу, крайне важно предусмотреть одну штуку, которую не увидит пользователь, но полезную для принятия продакт-менеджером правильных решений. Это всеобщее логирование. Речь не только и не столько технических логах (об этом все-таки должен заботиться техлид), а о бизнес-логике проекта.
Обязательно логируйте все, что не соответствует идеальному сценарию поведения пользователя. Если у вас вся информация о посещениях, не соответствующих этому сценарию, вы всегда сможете проанализировать, что идет не так, и на что пора обратить внимание. Запланированный сценарий может очень сильно отличаться от реального, и не имея полных логов, вы об этом не узнаете.
Продумайте, как вы проверите эффективность фичи. Возможно, для этого также понадобятся какие-то особенные логи. Отсутствие информации о работе новой функциональности — непозволительный промах продакт-менеджера. Позаботьтесь о том, чтобы логи были легкодоступны вам и тем, кто вместе с вами участвует в анализе проекта: в больших компаниях может случиться такое, что вам придется обойти пятерых человек из разных отделов, чтобы добраться до заветного знания.
Существует такой антипаттерн в продуктовом менеджменте: «Давайте сделаем классную фичу, а там посмотрим!». В таких случаях «…там посмотрим» зачастую приводит к «Ну, вроде все ок», чего явно недостаточно. Проблема особенно актуальна для KPI-ориентированных фичей.
До того, как фича разработана и появилась на продакшене, нужно определиться, как будет осуществляться эксперимент, какие данные будут использоваться и что будет критерием успешности/неуспешности. Не нужно изобретать велосипед, статистические науки давно подготовили для этого теоретическую базу, которую несложно соблюдать. Это касается и A/B тестов, которые являются одним из лучших способов тестирования полезности фичи, и любых других способов. Не подготовив заранее дизайн эксперимента, легко поддаться искушению и притянуть результат за уши.
Правильно спроектированный эксперимент убережет от неверных причинно-следственных связей. «После» != «вместо»; как бы не было приятно иногда связать рост пользователей с мудрым развитием продукта, возможно, это просто временная внешняя причина вроде сезонности. Например, повышенная активность пользователей может быть связана с погодными условиями, праздниками, недоступностью конкурентных проектов и т.п.
Для управления продуктом нет ничего важнее здравого смысла и системности. Каждое решение должно соответствовать генеральной линии развития, быть взвешенным и рассмотренным с разных сторон. Даже идеально реализованная и хорошая сама по себе идея необязательно полезна в контексте продукта.
Это тоже в своем роде управление продуктами, но речь пойдет о другом.
Disclaimer:
Едва ли хоть что-то из сказанного ниже может являться универсальным советом. Я в основном занимаюсь сервисами, с которыми практически не сталкивается пользователь, что накладывает своеобразный отпечаток на работу и те правила, которыми я руководствуюсь.
Feature request, хороший и плохой.
Если продукт, над которым вы работаете, не обладает сверхузкой спецификой, едва ли не каждый встречный сочтет своим долгом прислать вам feature request. Нужно уметь фильтровать их, особенно если ресурсы ограничены. Если дизайнер со слезами на глазах будет убеждать, что вашей системе обработки данных придет конец, если не привести интерфейс в соответствие с модными трендами, это не значит, что нужно бросать все и делать так, чтобы система напоминала последние изыскания сэра Джонатана Айва. Или наоборот: когда программист отстаивает точку зрения, что пользователю подсказки не нужны, т.к. «все и так очевидно», это не повод отказываться от тултипов. Вообще, многие не очень хорошие идеи вызваны профессиональной деформацией: UX готов заботиться о пользователе в ущерб бизнесу, разработчики предпочитают любому интерфейсу теплую ламповую командную строку, некоторых бизнес-ребят вообще ничего не волнует, кроме сроков и денег и т.п. На это все следует делать поправки.
Например, я фильтрую свежепридуманные фичи так:
- откровенно слабая или опасная идея, можно сразу отказаться;
- неочевидная фича, нужен дополнительный анализ;
- явно полезная фича, кладем в бэклог, выставляем приоритет.
Каждая новая фича должна работать или на цели (без этой функциональности сложно/невозможно добиться общих целей продукта), или на KPI (эта функциональность позволит улучшить существующие показатели). Это могут быть как связанные, так и ортогональные сущности.
Пример фичи, ориентированной на цели:
- портировать приложение на Windows Phone, чтобы оно присутствовало на всех мобильных платформах
- сделать блок «Лучшие статьи недели» персонализированным, чтобы увеличить количество просмотренных страниц на каждого пользователя
Если фича не соответствует ни тому, ни другому, с ней что-то не так. Задайте себе и тому, кто предложил эту фичу, простой вопрос «Зачем?». Довольно часто feature request приходит, «потому что это модно!». Задавая вопрос «зачем?», вы сможете отделить полезные идеи от малотолковых веяний моды. Не нужно бояться задавать тот же вопрос высокопоставленным боссам, которые могут на ходу бросать не в полной мере обдуманные мысли в расчете на то, что вы возьмете под козырек и немедленно приступите к исполнению.
Отдельно хочу заметить, что довод «Так уже сделали конкуренты!» не является достаточным, чтобы сломя голову браться за разработку. Довольно забавно смотреть, как тот или иной проект слепо копирует что-то вплоть до достаточно мелких деталей, не зная, что такая реализация была вызвана, например, локальными ограничениями используемого фреймворка.
Перед началом разработки
Планируя фичу, крайне важно предусмотреть одну штуку, которую не увидит пользователь, но полезную для принятия продакт-менеджером правильных решений. Это всеобщее логирование. Речь не только и не столько технических логах (об этом все-таки должен заботиться техлид), а о бизнес-логике проекта.
Обязательно логируйте все, что не соответствует идеальному сценарию поведения пользователя. Если у вас вся информация о посещениях, не соответствующих этому сценарию, вы всегда сможете проанализировать, что идет не так, и на что пора обратить внимание. Запланированный сценарий может очень сильно отличаться от реального, и не имея полных логов, вы об этом не узнаете.
Продумайте, как вы проверите эффективность фичи. Возможно, для этого также понадобятся какие-то особенные логи. Отсутствие информации о работе новой функциональности — непозволительный промах продакт-менеджера. Позаботьтесь о том, чтобы логи были легкодоступны вам и тем, кто вместе с вами участвует в анализе проекта: в больших компаниях может случиться такое, что вам придется обойти пятерых человек из разных отделов, чтобы добраться до заветного знания.
Проверка полезности
Существует такой антипаттерн в продуктовом менеджменте: «Давайте сделаем классную фичу, а там посмотрим!». В таких случаях «…там посмотрим» зачастую приводит к «Ну, вроде все ок», чего явно недостаточно. Проблема особенно актуальна для KPI-ориентированных фичей.
До того, как фича разработана и появилась на продакшене, нужно определиться, как будет осуществляться эксперимент, какие данные будут использоваться и что будет критерием успешности/неуспешности. Не нужно изобретать велосипед, статистические науки давно подготовили для этого теоретическую базу, которую несложно соблюдать. Это касается и A/B тестов, которые являются одним из лучших способов тестирования полезности фичи, и любых других способов. Не подготовив заранее дизайн эксперимента, легко поддаться искушению и притянуть результат за уши.
Правильно спроектированный эксперимент убережет от неверных причинно-следственных связей. «После» != «вместо»; как бы не было приятно иногда связать рост пользователей с мудрым развитием продукта, возможно, это просто временная внешняя причина вроде сезонности. Например, повышенная активность пользователей может быть связана с погодными условиями, праздниками, недоступностью конкурентных проектов и т.п.
Вместо заключения
Для управления продуктом нет ничего важнее здравого смысла и системности. Каждое решение должно соответствовать генеральной линии развития, быть взвешенным и рассмотренным с разных сторон. Даже идеально реализованная и хорошая сама по себе идея необязательно полезна в контексте продукта.
