Из проджекта в продакты: как проджект-менеджеру сменить профессию и стать менеджером продукта
Профессии проджект- и продакт-менеджера во многом похожи, но перестроиться на новый уровень задач получается не у всех. Рассказываем, что пригодится проджекту, который хочет стать продактом, какие есть сложности и делимся мнениями экспертов, которые сами прошли этот путь.
Комментарий недоступен
Спасибо за классные вопросы, тут есть о чем поговорить!
Ответьте мне на такой вопрос по примеру вашей кофейни. Если продакт должен уметь делать прототипы для проверки своих гепотиз, то что из себя будет представлять прототип для кофеин с пандусами?
Я бы проверил гипотезу следующим способом:
Повесил листик А4 рядом с входом в кофейню на уровне глаз человека в коляске с текстом: для заказа кофе позвоните бариста по номеру +7-999-999-99-99 и он вынесет вам кофе и терминал для оплаты картой.
Что я получу в итоге эксперимента? Количество заказов, которое я не получил бы без этого листика и это та доп.выручка для кофейни, которая будет УТП сервиса и основой монетизации.
Кстати можно даже попробовать померять средний чек, частоту покупок и LTV, если вести базу звонков и вести лог: номер телефона / дата / сумма чека.
Что я не получу в итоге эксперимента? Данных о стоимости привлечения пользователей в сервис. Увы, потому что я буду использовать для эксперимента только естественный трафик.
Цена проверки гипотезы — листик бумаги и договоренность с кофейней. Второе, конечно, непростая задача, но кажется это тоже вполне проверка гипотезы сервиса, ведь без таких договоренностей сервис не запустить.
Верю, что есть и другие способы, я описал то, как это делал бы лично я.
Если менеджер не программист, то какое он ТЗ составит?
ТЗ всегда составляет исполнитель. То есть программист в данном случае. Продакт (я так понимаю в вопросе о нем) пишет список хотелок. После обсуждения с разработчиками он становится списком требований, и уже на основе этого пишется ТЗ.
Продакт говорит ЧТО ему нужно от программного продукта, он понимает конечный результат, который хочет получить, но не знает КАК его достичь. Разработчики же наоборот, понимают КАК, но не знают ЧТО. ТЗ кстати формализует ЧТО и описывает КАК.
П.с. Есть менеджер из вопроса был проджектом, то он должен координировать работу по выполнению и точно не должен писать ТЗ
Почему прожект анализирует потребности, и каким образом при отсутствии представления о потребностях продакт выводит гипотезы?
Ответ на вопрос Почему содержится во второй части вопроса — чтобы иметь представление о потребностях для формирования гипотез. При отсутствии данных о потребностях гипотезы будут из воздуха и смысла не имеют.
Часто бывает такое, что продакт может формировать гипотезы исходя из своих потребностей или представления о них. Это называется субъективное мнение и в этом случае продакт может угадать или не угадать. Супер-чуйка и удача, конечно, бывают, но исследования и цифры снижают риски принятия решений на основе мнения одного человека. Поэтому лучше все-таки изучать потребности сначала, иначе стартап или компания будет избавлять от боли, которой нет. Это, кстати, одна из основных причин краха стартапов.
Что такое - большая команда?Для меня этот параметр зависит от размера компании. Для компании из 3-х человек команда из 2-х уже большая. А для корпорации с 5000 человек команда 30 человек будет маленькой.
Назовите крупные компании делающие собственные продукты у которых так, как вы описали.
Я не понимаю, к чему именно относится вопрос( В статье больше про трансформацию опыта сотрудника, чем про разработку продуктов компаниями. В крупных компаниях много согласователей, бюрократии и регламентов, поэтому они и создают акселераторы внутри себя или покупают стартапы и растят внутри — Сбер, Яндекс, Mail, МТС, Газпром, РЖД.
Возможно я отвечу более конкретно, если вы уточните вопрос