Эволюция управления продуктом от стартапа до организации
Опубликовано: 2017-12-27Как масштабировать вертикаль управления продуктом в стартапе
В первые годы существования организации продуктовая команда будет в основном состоять из нескольких членов, столкнувшихся с трудностями, типичными для этапа запуска, но по мере роста организации размер команды и методы управления продуктом также должны будут масштабироваться, чтобы достичь роста, пропорционального что у организации.
Скорость имеет важное значение для стартапа и тем более, когда вы находитесь в фазе гипер-роста. По мере масштабирования бизнеса каждому менеджеру по продукту придется иметь дело с несколькими заинтересованными сторонами. Именно здесь ваши навыки управления конфликтами и ваша способность принимать трудные решения становятся критическими.
Такие решения будут включать компромиссы, и не все заинтересованные стороны могут быть удовлетворены, но как менеджер продукта вы должны внедрять изменения, которые считаете необходимыми в интересах бизнеса, и увеличивать скорость выполнения.
На этапе роста рекомендуется децентрализовать концепцию создания функций , разделив существующую команду на подгруппы , которые будут нести ответственность за продукт, с которым они связаны. Такой подход, безусловно, поможет ускорить принятие решений, устранить бюрократию и повысить подотчетность .
Когда есть несколько заинтересованных сторон, зависящих от команды продукта для достижения бизнес-результатов, становится неотъемлемым создание культуры прозрачности в отношении спецификаций, сроков, проблем, задержек и т. д. Это потребует инструмента, который может быть принят во всей организации, тем самым инициирование большого изменения среды запуска, где вся эта информация была ограничена общими дисками и групповыми обсуждениями, чтобы установить ожидания, которые видны всей организации.
Исходя из этого контекста, всю концепцию можно разбить на ключевые моменты, чтобы получить детальное представление о масштабировании вертикали управления продуктом в стартапе.
Принятие решения
Лучший способ сделать это — децентрализовать процесс, позволяя принимать решения внутри каждой группы разработчиков, принимая во внимание вклад или предложения заинтересованных сторон. Решать выпуски функций или работать в спринтах будет прерогативой конкретной команды.
Рекомендуется для вас:
Как Metaverse изменит индийскую автомобильную промышленность
Что означает положение о борьбе со спекуляцией для индийских стартапов?
Как стартапы Edtech помогают повысить квалификацию рабочей силы Индии и стать готовыми к будущему ...
Технологические акции нового века на этой неделе: проблемы Zomato продолжаются, EaseMyTrip публикует...
Индийские стартапы срезают путь в погоне за финансированием
Цифровая маркетинговая платформа Logicserve Bags Финансирование 80 CR INR, ребрендинг как LS Dig...
В то время как уровень автономии в принятии решений будет различаться в разных организациях, задачи, разбитые и распределенные таким образом, гарантируют выполнение каждой единицы работы. Кроме того, эта модель поможет сократить задержки, улучшить отчетность и помочь в управлении рабочей нагрузкой.
Одна вещь, которую должен обеспечить каждый менеджер по продукту при принятии решений, — это помнить о таких критических факторах, как соответствие требованиям, безопасность, средства защиты от мошенничества, доступ пользователей и т. д . и убедитесь, что нет личной информации, которая может быть использована не по назначению.
Часто менеджеры по продукту сталкиваются или обсуждают несколько функций, которые необходимо разработать для различных конечных пользователей продукта. Менеджеры по продуктам должны учитывать весь стек функций, принимая решение о том, что создавать с ограниченной пропускной способностью, доступной в каждом спринте. Матрица на основе баллов может быть одним из методов, который можно использовать для оценки при принятии решений. Каждая строка обозначает функцию, а столбец оценивается с помощью баллов:
- Техническая осуществимость
- Влияние на бизнес
- Время выпуска
- Опыт работы с клиентами
Функция с наибольшим весом может быть приоритетной, так как вы быстрее получите ощутимые результаты.
Дорожная карта
Для любого продукта считается хорошей практикой разработать дорожную карту для набора функций, которые необходимо создать, весь план должен быть установлен в течение 6-8 недель. В современном мире потребности быстро меняются, и истинная проверка валидации функции исходит из предоставленных данных.
На этапе роста управление продуктом должно основываться на отзывах или данных клиентов. Напротив, составление дорожных карт на этапе стартапа — это совершенно другой процесс, в котором решения принимаются на основе интуиции, которые могут быть или не быть эффективными.
Подумайте, какой минимально жизнеспособный продукт нужно запустить и соответственно вывести на рынок, чтобы конечный пользователь испытал продукт и заплатил за него. Например, можно решить запустить платформу электронной почты только для отправки и получения электронных писем, но клиент может оставить отзыв о том, что ему требуется возможность прикреплять документы, хранить контакты или даже организовывать электронные письма в разные папки.
Вот как продукты развиваются на основе отзывов, что в конечном итоге приводит к созданию комплексного набора продуктов.
Коммуникация
Стандартизированный процесс коммуникации, заблаговременно распространяемый на все внутренние и внешние заинтересованные стороны, обеспечивает дополнительную прозрачность операций. Хотя это может показаться бюрократическим, одно ключевое поведенческое изменение, которое может быть принято в переходный период, — это получение согласований на разных этапах перед выполнением. Примечания к выпуску, демонстрации / UAT, уведомления о запуске, обновления и т. д. станут критически важными для процесса аудита в будущем.
Принятие вышеперечисленных методов позволит вам выполнять операции быстрее, чем при обычном способе их выполнения. Масштабирование управления продуктом до организационного уровня никогда не бывает гладким, но систематическое следование простым практикам упрощает количество изменений, сопровождающих переход.