Софья Федосеева
Ирина Яшина, управляющий портфелем фонда the Untitled ventures, в восьмом выпуске серии о построении стартапа рассказывает, как построить эффективный product management.
Как построить стартап по принципам стоиков. Часть 8: организовываем продакт-менеджмент
Ирина Яшина
Еще раз возвращаемся к фатальным ошибкам стартапов. Портал CB Insights самой главной неудачей назвал отсутствие запросов рынка на продукт стартапа (no market need).
И дело не в том, что с самого начала инициатива была надуманной (хотя такое тоже может быть). Вся суть в развитии: сначала идеи и целей, потом — MVP, а затем — уже работающего продукта. Иными словами, суть — в управлении продуктами, product management.
Важное замечание: эта статья максимально нейтральна к разным методологиям (популярным нынче agile, scrum, спринтам и прочим) и основана на собственном опыте познания, мнение может отличаться от вашего. Но вы можете попробовать это дома.
Что такое product management
Product management — это относительно новая система знаний, которая сочетает маркетинг, технологическую базу и теорию менеджмента и привносит свои подходы.
Не знаешь с чего начать? Только проверенные сервисы для стартапов в B2B-магазине Rusbase.
Адекватнее всего, с моей точки зрения, оценивать product management как «дочку» этих трех дисциплин, новое поколение — не научное-«тейлоровско-друкеровское», а прикладное постмодерновое.
Цель — построить наиболее эффективные и органические бизнес-процессы для решения болей клиентов через продукт и поддерживать процессы в хорошем состоянии.
Бизнес-процессы — это составная часть цикла product management. Цикл приблизительно можно разделить на этапы:
постановка целей;
выявление и проверка гипотез;
работа с усовершенствованием MVP проверенных и валидированных гипотез;
полноценное внедрение;
корректировка целей — постановка новых;
и дальше заново по пунктам.
Какие принципы должны учитываться на всех этапах?
-
Обязательное «раскапывание» болей клиента как основа для всего цикла.
Важность скорости и быстрой проработки гипотез.
Отсутствие «перфекционизма» при валидировании гипотез, готовность к отказу от них.
Постановка целей
И тут работает все: и SMART-принцип, и допущение «отказываться от целей из-за изменения контекста — это нормально»… Но я бы хотела более подробнее остановиться на «ребенке» KPI — OKR (Objectives and Key Results).
Разобраться, как это работает, мне помогла Наринэ Варданян, product manager сети клиник «Севергрупп Медицина». Эта компания — далеко не стартап, но продакт-команда внутри — быстро развивающееся направление с опорой на собственно разработанные технологические продукты.
Так вот, об OKR. Как следует из названия, есть две части: цели и ключевые результаты. Первый элемент может быть обязательным или «вдохновляющим».
Пример цели обязательной: уменьшить количество возвратов товаров на 25% в этом квартале.
Пример цели вдохновляющей: стать в этом году тем приложением, которым Леонардо Ди Каприо будет пользоваться каждый день и расскажет об этом хотя бы одному СМИ.
Второй элемент включает каскад показательных метрик. Как мы узнаем, что цель достигнута полностью или частично? Через три-пять ключевых результатов.
Например, получить более двух тысяч оценок 5.0 в App Store до 10 декабря или стать партнерами экологических организаций, где участвует Леонардо Ди Каприо.
Что при этом важно?
-
Все люди в компании видят цели друг друга.
Обратная связь (один на один с руководителем или тимлидом) происходит как можно чаще (оптимально — раз в неделю). Если есть препятствия сценарию А, то он оперативно меняется на А* или В.
Выявление и проверка гипотез
Вот тут начинается самое интересное: все agile, scrum и другие семейства обитают в основном здесь. Эти методологии нацелены на способы создания и развития идей, разделения команд. Этот момент я пропускаю, чтобы не задеть ничьи чувства.
Зато остановлюсь на рекомендациях для мягко работающего цикла product management «всех возрастов»:
-
раскопка гипотез благотворна на большой выборке — этому в значительной степени способствуют онлайн-инструменты (Google Forms, аналитика «Яндекс.Метрики» и Google Analytics, таргетинг);
по статистике, подтверждается только одна из десяти гипотез (10% конверсии — это нормально!);
лучше всего проверять минимум одну гипотезу в неделю (идеальный сценарий);
при этом в единый момент времени работать только над одной гипотезой (последовательный, не параллельный подход);
общий посыл — чем проще, тем лучше. На этом этапе главенствует регулярность, а не глубина или перфекционизм (чтобы не тратить все волевые ресурсы «в стол»).
Да, это идеальная картина, а как все выглядит на самом деле?
Я поговорила со стартапом стадии А Sizolution, который занимается определением оптимального размера одежды и обуви для онлайн-ритейлеров. Проект сейчас активно развивается на немецкоязычных рынках.
Сооснователь проекта Ваге Таамазян рассказал, как у них выстраивается управление продуктом — и, в частности, формирование гипотез и перевод их в реальные действия. Если вкратце, то:
-
источниками циклов становятся запросы клиентов (В2В) и собственный wish list, куда любой сотрудник может написать выведанные инсайты (и который подвергается инвентаризации примерно раз в пару месяцев).
Все процессы ведутся в Trello, на разных досках.
Каждый день все доски просматриваются (15-20 минут около экрана компьютера product manager).
Все продуктовые гипотезы выходят в отдельные проекты, циклы (например, введение продукта на измерение размера обуви) или в процессы (например, мониторинг точности алгоритмов).
Как только появился отдельный product manager, команда села и свели все продукты в единый приоритетный лист, а также приоритизировали все открытые инициативы.
И еще один кейс — стартап SegmentStream стадии А+, который занимается сквозной маркетинговой аналитикой для e-commerce. Проект прошел программу SAP Techstars в Берлине, а в 2020 году планирует активно развиваться на рынке Великобритании.
Сооснователь и Product Owner Олег Катрышев поделился тем, как выстроены процессы, связанные с управлением гипотезами.
-
Главное правило — не делать вещи, которые не нужны рынку. При появлении новой идеи гораздо выгоднее потратить две недели на общение с текущими и потенциальными клиентами, чем начать писать код. Лучше вообще никакой код не писать.
С другой стороны — важно не делать все, что от вас просит рынок. Иначе продукт может превратиться в агентство. На мой взгляд, лучшие продукты рождаются на пересечение самобытного видения команды и потребностей рынка.
Ритуалы. Так как календари у всех разрываются от встреч — очень сложно и эмоционально затратно каждый раз планировать синки команд продукта, разработки, продаж, поддержки. Лучше сразу запланировать на несколько месяцев вперед периодические встречи. У нас это — синк продуктовой команды со всеми другими командами, sprint-planning, product-demo.
Product-demo — полезная вещь. За один час в две недели вся компания понимает, что мы успели сделать за этот короткий срок, как этим пользоваться, продавать и какая потенциальная польза есть для клиентов.
Важная вещь, которую уяснили в ходе программы TechStars: продукт — это не просто набор фич, технических составляющих. Важно учитывать и аудиторию, цену, упаковку, документацию, расходы на будущую поддержку.
Отличия налицо, но основа одна и та же: скорость, регулярность, основа — запросы от клиентов и их потребности.
Работа с MVP и полноценное внедрение
На этих этапах много ситуативного, поэтому можно выделить только общие рекомендации:
-
если нужен pivot или любая коррекция на этом этапе, то это нормально. Главное — это решение и уточнение решения боли клиента;
уточнение решения может быть на узкой выборке, экстенсивный подход может или не дать ответов, или сделать это поверхностнее и менее доверительно;
здесь высокая скорость уже не так важна, можно добавить «щепотку» перфекционизма.
Большой бизнес vs стартап: есть ли разница?
Интересно было мнение обеих сторон. И вот что я услышала: большой бизнес не видит особой разницы, а вот стартапы не торопятся с суждениями. Основными отличиями становятся материальная мотивация и скорость. И эти пункты могут стать критическими в функционировании команды.
Однако и та, и другая стороны сталкивались с тем, что у каждого человека свое понимание product management. Поэтому сложно делать категоричные выводы, стоит смотреть на свою команду, контекст и динамику изменений самого продукта.
Фото в тексте и на обложке: Unsplash
Источник:
