Posts tagged Продукт

В шкуре менеджера продукта – готовим бизнес кейс

0

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

Надо понимать что это работа больше предназначена для менеджера продукта (product manager). Но в наших краях (кроме телекомов и ряда банков) это еще редкая профессия. Посему нашему брату, менеджеру проекта, надо осваивать и смежные навыки с менеджером продукта. В частности подготовку бизнес кейса и составление документа маркетинговых требований. Речь, конечно же, не идет о том чтобы менеджер проекта стал оракулом маркетинга – но вот знать что спросить с маркетологов и продавцов надо. Надо знать что мы хотим получить бизнес кейс (business case / MRD – Marketing Requirements Document).

Для кого это документ:

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

Давайте разберемся что должно быть в документе:

  • Резюме для руководства – менее чем на страницу вывод из всего документа – предлагающего один или несколько вариантов решения, ключевые цифры и основания. Несколько вариантов решения полезно тогда когда руководство любит сделать свой вклад в решение – даже если правильный вариант очевиден.
  • Кто клиент продукта. Возможно будет несколько обособленных сегментов клиентов которые будут пользоваться вашим продуктом (услугой). Определить клиента не указав потребности – это значит говорить без каких либо оснований. Какие цели у клиентов? Какие проблемы они испытывали при использовании продуктов-заменителей или продуктов конкурентов? Где они в реальной жизни и когда нуждаются в продукте? Где они его приобретают?
  • Описание продукта – описание посредством пользовательских характеристик верхнего уровня.
  • Отличие продукта от конкурентов. В чем он уникален, кто ближайший конкурент, кто заменитель, в чем разница (конкурентное преимущество). Очень желательно проверить себя на то что мы не создаем еще один похожий на 100 уже существующих продуктов да еще не с самым лучшим соотношением цена-качество.
  • Риски, связанные с разработкой, производством и продажей продукта. Очень хорошо трезво взглянуть на рынок, оценить вероятность возможностей, ответные действия конкурентов и т.п.
  • Жизненный цикл продукта – когда выпускаем продукт, какие масштабы производства в какое время запланировано, в каких регионах. Сюда также полезно включить развитие характеристик продукта – создание новых версий и редакций продукта.
  • Анализ затрат и доходов
  • Соответствие стратегии, миссии и видения развития компании. Анализ соответствия по отдельным стратегиям – финансовой (можем ли мы обеспечить денежный поток необходимый для реализации проекта, достаточно ли у нас финансового запаса прочности), технологический (есть ли у нас необходимые инструменты и технологии, достаточно ли у нас опытных людей)

Больше промежуточных версий

0

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

Снижение качества продукта в проекте

0

Хотите снизить качество продукта в проекте?

  • Безбожно давите на сроки, поставьте их нереальными и прессуйте
  • Снижайте стоимость, давите поставщиков до истощения
  • Вовлекайте ваших сотрудников в 5 проектов одновременно
  • Не в коему случае не доверяйте людям в проекте
  • Увеличьте бюрократию в проекте
  • Людей их проекта рассадите в разных комнатах в пяти корпусах.
  • Писать требования? Зачем! Это бумагомарательство. И завтра все равно мы что-то переделаем. А принимать будем когда более-менее будет готово.
  • Ни в коем случае не тратьтесь на тестировщиков. Разве и так не понятно что это должно работать?

Кросс-пост.

Go to Top